GWT Validation 2.1 released and gearing up for 2.2

So, the promised 05/14 release of gwt-validation 2.1 came and went and I simply forgot.  I published it on 05/15 so at least I didn't forget by too much.  What I really did wrong was forget to tell anyone.

You can see in our issue tracker a list of issues that were closed as part of 2.1.  The focus in 2.1 was mainly on defects found in 2.0 and improving usability.  Very little work was done on improving the compatibility with the JSR-303 TCK.  We'll get to that later.

So, all hail release 2.1!  (Release 2.1 has also been published to Maven Central.  For more details, see here.)

Now, we're going to be moving towards Milestone 2.2, and that means addressing the issues with the TCK.  I've already outlined each of the areas in which gwt-validation fails against the TCK in the project's issue tracker.  You can find these issues here.  What remains is to try and find volunteers for the various issues.

So, with that focus, I'd like to set up a sprint schedule and start getting these issues assigned to people and just get the ball moving in that direction.

For more updates on Milestone 2.2 please follow the discussion on our google groups page.

Thank you for following.

Release: gwt-validation 2.1 snapshot released!

I just wanted to let everyone out there in JSR-303 land know that we're not dead.  I work full-time, most weeks, as a Java consultant and don't always have time to get to this pet project.

However I wanted to let people know that we're on the road to 2.1 and that there have been some exciting changes.

First and foremost, the Java/reflective JSR-303 validation implementation no longer requires that Reflections do its scanning magic.  This is a huge improvement and will let us go forward into containerized environments that were previously closed off.  This includes some versions of Tomcat, JBoss, and Google's own App Engine.

Secondly, serialization has been addressed.  It has a long way to go but the basic serialization support is in there.  It mainly only works from server -> client however.  A lot of the things that GWT does to optimize serialization actively hinder this effort.  The steps made for 2.1 are just one of many that will need to be complete for this to be a fully working feature.

As a minor change, the project has been slightly rearranged.  There is now a parent pom, a core (gwt-validation), the compatibility tests, and the sample.  Most importantly to most people the gwt-validation-sample has been updated to work fully with Maven and should be much more straightforward to examine and run.

Finally, some work has been done on allowing the user to specify model classes.  This is not yet implemented as of r324 (the newest SVN revision as of this writing) but it is probably the last feature that will make it into version 2.1.  After that, we're just going to be looking at, maybe, a month of stabilization.

Actually, I'll go ahead and say it, we'll be releasing gwt-validation 2.1 on May 14th.  We're trying to get better at release engineering and time lines so we'll also be addressing that in future postings and discussions as well.

Thanks for sticking with the project, however small, over the years.  (Years, really?)

Happy validating.

Release: gwt-validation 2.0 released!

As of this morning gwt-validation was set up in Maven Central and the 2.0 release is available.  No more having to manually include the project!

Hopefully future releases will slim down the required library set and make it a little easier to work with for end users.  This is our goal.

Thanks for following along and using gwt-validation.

Cheers!

License change for gwt-validation

A commenter pointed out in a previous post that the LGPL was incompatible with their needs.  This is counter to the goals of the gwt-validation project.  We want as many users as we can get.

We've switched over to the Apache License v2.0 which is a much more permissive license.  This is despite the fact that we were using the v2.1 of the LGPL.  It was difficult to for users to notice that small detail.

So, now gwt-validation will support a wider range of users!

Go forth and validate.

Release: gwt-validation 2.0 SNAPSHOT

Release 2.0 of gwt-valdiation is in central snapshot repository.  I'm going to let some testing happen and then prepare and promote 2.0 final.

It's also available for download here: http://code.google.com/p/gwt-validation/downloads/list

We're looking forward to some good feedback.

On gwt-validation, 2.0, and milestones

I've been working on the gwt-validation project for several years now.  I've not been a very good open source project leader at all.  I've been closed, uncommunicative, and passive.

Worst of all, I've not been providing direction.  I'm going to be changing all of that.

Where does this leave us?  Well, for starters, I've got an announcement to make.  The gwt-validation project is going to version 2.0 "soon."  This means that it will be available on the project page and in Maven Central as well.  That's right!  I said Maven Central.

I'm also going to be creating tasks for the 2.2 milestone.  The 2.1 milestone will be given over to fixing issues in the 2.0 milestone.  I'm looking forward to having people contribute on the 2.1 and 2.2 milestones.  I want to see that pom.xml file explode with people.

In addition to these things I'm going to update this blog with information on how gwt-validation works and what I've learned while making it.  Hopefully with a view towards improving the GWT community as a whole.

Stay tuned.

Dramatis Personæ

I had a thought the other day about how people in groups tend to give in to a sort of social entropy, or drama, the longer and closer the association. This is especially dangerous in long term software engineering projects. One only has to look at the open source community to see how fractious and petty people can become when they have nothing better to do.

Before I expand on that thought I want to back up and talk about the reason that this topic came to mind. A few days ago I was talking to a friend of mine and he said his parents were leaving their church. Now, I guess this is no big deal to some but I happen to know that they had been members of that congregation for over thirty years. Let that sink in. What, you may ask, were they willing to end that relationship over? It wasn't dogma, or attendance, or really anything related to the practice of religion. It was things like donations, appropriations, clubs, and extra-curricular activities.

So we have groups of people who are aligned in ideology and purpose who get so bogged down in the details of their interpersonal associations that they cannot continue.

Now, does that sound like a project you've worked on?

So, as I was saying, sometimes people have nothing better to do. It might be more accurate to say that they have exhausted their productive tasks and have decided to either be "productive" on behalf of others or to "help" others do the right thing. This invariably leads to a lot of hurt feelings and squished toes. Other times it's an expression of "my way or the highway" or a battle over a perceived resource.

These internecine conflicts have got to go.

I've worked on one project where there were eight (or so) women working for one older, very polite, gentleman. He was one of the most henpecked men I've ever met. It seemed like every single person on his team could claim top priority at any given moment. They were all fighting for a shared resource, his attention and time. This led to constant squabbling in the office and a drastic reduction in productivity. I think the most telling thing about this situation is that it occurred near the end of a project when most of the goals were complete and people were running out of things to do. When you get down to brass tacks and try and finish something off is where things really start to go awry. As the expression goes: "the devil is in the details."

I worked on another project that had a high turnover rate (something like one person a month with a team of 20 people on a two year project) and it had nothing to do with the project itself. The project was well funded, reasonably well managed, effective, and was on a product that helped people go to school. The problem was interpersonal relationships and tons of mistrust. Every day the sky was falling. Why? Because, that's why. This kind of systematic behavior eventually caused me to look elsewhere myself.

I guess what I'm driving at is that even well managed, well paying, effective, efficient, and otherwise wonderful projects can fail based on the personal relationships of the stakeholders. This is true even when each and every single stakeholder is personally aligned with the goals of the project. Perhaps it's even more likely in that situation because people feel like they have more at stake. Too often in this industry we forget the human factors that drive our business. Careful tending and leadership of your team can help prevent these issues.

Bottom line: we're not robots even though we sometimes play them at work.