Upgrading to Seam 2.x? Read some hard lessons learned.

[rstevens]

Read the Seam 2.0 Migration Guide found in seam2migration.txt in the Seam folder.

Use the latest version of Eclipse IDE for Java EE Developers. Start over using JBoss Tools. Use seam-gen to recreate your new skeleton code, use JBoss tools, and their new directory structure, and merge your code into the files you create using their tools.

I'm considering tossing Maven. It is transitive dependency hell. For most projects, all the JAR files I need will come with the new setup and I can upgrade JBoss Tools and get the new versions later.

I'm sure I'll get disputations about this but consider how much money you or your future team members may lose configuring and reconfiguring.

When I fight Seam configuration I think it should be called Stitches and Band Aides. When I realized how much effort is going into making this a pleasant environment, I wonder why they don't rename it Seamless (meaning you're dealing with a variety of tools and JARS all made by different vendors and you want the Seam team to figure how to make it all work for you, which I hope will continue to be one of their most important goals).

Robert

[rstevens]

We started fresh and ported to the new 2.0.1.GA environment in just one day with JBoss Tools and their pre-configured JAR files after spending two painful weeks trying to upgrade our old application manually.

After using seam-gen to set up our original project, we did not use it again, nor did we use the JBoss Tools wizards.

Some of the irritating problems we experienced before starting over were:

1. Trying to get Maven to work correctly.

2. Maven was deploying two or more versions of several JARs into our WAR file--one with version numbers and one without.

3. Two unwanted JSF JARS, and one Log4j always being copied to the WAR file for JBoss 4.2.2. We had to delete these after deploying before we could run the server.

4. Configuration file nightmare: When we upgraded, we let seam-gen generate our new configuration files and never looked at the old ones again.

5. We loaded up the new and old project into Eclipse and used the TortoiseSVN Export to copy and paste over files and folders so we wouldn't copy the old SVN files.

In case anyone else is struggling, I strongly recommend you start over with a clean environment. It was difficult to commit to doing, but without question it was the right thing to do for us.

[bsmithjj.bradley.1.smith.gmail.com]

I wouldn't toss maven; I just wouldn't use any poms supplied with any framework including Seam.  Our approach to dealing with Maven is to maintain our own Seam archetypes.  The poms for the archetypes, once debugged, are easily consumed by all.  I've griped before in the old Seam forum about how transitive dependencies are bad.  In nearly every case where I've used transitive dependencies, I've had to spend considerable time unraveling the mess created by an unexpected / un-intuitive import.

[rstevens]

We've seen decades of transitive dependency problems in computer science. Windows' solution was COM but it relied on developers ensuring that new versions included backwards compatible interfaces.

It was very difficult to get our pom.xml to do what we wanted it to do. We looked at the example in the Seam documentation (35.2. Dependency Management using Maven), Michael Yuan's example, the example in the jboss-seam-2.0.1.GA docs, jboss-seam-2.0.1.GA\build\core.pom.xm, jboss-seam-2.0.1.GA\build\root.pom.xml and the pom.xml files with the examples.

I agree--it is difficult to know the transitive problem doesn't go away but for now, we can focus on our development instead of our JAR file nightmare, configuration files, and crashes.

[pmuir]

IMO Maven's dependency management is ok (probably Ivy's is better, but less used) but it's build system is a nightmare (e.g. it only recently seems possible to order the classpath). Transitive dependencies are hard I agree, and the tooling in Maven is only slowly getting better (mvn dependency:tree helps a lot).

[pmuir]

But for me, when you throw away transitive dependencies in Maven, you might as well throw it all away as it's about the only reason to use it.

[bsmithjj.bradley.1.smith.gmail.com]

But for me, when you throw away transitive dependencies in Maven, you might as well throw it all away as it's about the only reason to use it.

It depends ...  For us, we have dozens of projects internally; thus, having a unified structure for project layout (the maven-2 src structure), dependency resolution, and for project assembly is a big labor saver.  Only maven has been able to deliver that for us.  Ant, while fast and feature (task) rich, invariably assumes a lot about or requires custom finagling on the project assembler's machine in order to work.  Take seam-gen for example, that requires some tweaking out-of-the-box (./seam setup) in order to work (because it's based on Ant).

So if I tended to work on a small number of projects, then Ant might be sufficient.  Caveat - I love Maven's ability to resolve dependencies via http;  to my knowledge, that's not possible in Ant.  And so for me, that's the nail-in-the-coffin for Ant.  Unfortunately, the transitive-dependency-resolution capability of Maven brings its own perils and hence this discussion.  ;-)

Brad

[marx3]

I would like to mavenize my Seam project, because I like Maven. Hovewer it's rather hard way to do it and there is almost no working examples to start with (something like seam-genned application which works and builds properly so it's easy to build on top of it).

[svadu]

Pete Muir wrote on Feb 18, 2008 05:53 PM:


IMO Maven's dependency management is ok (probably Ivy's is better, but less used) but it's build system is a nightmare (e.g. it only recently seems possible to order the classpath). Transitive dependencies are hard I agree, and the tooling in Maven is only slowly getting better (mvn dependency:tree helps a lot).

Actually the build system is quite OK. Surely it's not as flexible as ant but it serves the need of 80% projects which is quite good achievement I should note.

The nightmare that you might be referring may actually be a single bug (which is resolved for 2.0.9) and I must admit with quite a lot of impact, but let's not forget - projects like jboss embedded are also quite not an average project :). I am not sure what else you may mean by the nightmare.

It may seam to be a nightmare if you just switch from ant to maven, but ant and maven require different ways of thinking and especially organizing software projects. And to be honest (and I have lots of experience with ant) I like the way of thinking for maven project much better. This is of course my personal opinion and I am sure many (who are still) ant folks wont agree with me.

Let's not forget that Seam is designed as an ant-based project and it may be too late to make it as easy to work with maven as it now works with ant without major rework. And I am not sure if it ever will (and whether it needs to) happen.

And I agree with Pete here, transitive dependencies may be hard but they can also be a no-brainer if you organize them right (use corporate/parent pom's, dependencyManagement and optional dependencies).

Btw, I was surprised how well spring uses optional dependencies (Seam is more complex project so it wont be as easy that's for sure).

[pmuir]

Siarhei Dudzin wrote on Feb 23, 2008 08:18 PM:


Actually the build system is quite OK. Surely it's not as flexible as ant but it serves the need of 80% projects which is quite good achievement I should note.

The nightmare that you might be referring may actually be a single bug (which is resolved for 2.0.9) and I must admit with quite a lot of impact, but let's not forget - projects like jboss embedded are also quite not an average project :). I am not sure what else you may mean by the nightmare.

I dislike somewhat the restrictive layout. But maybe I could get used to that. It also seems a lot slower than ant. The lack of documentation makes life hard, as do the flaky plugins (surefire is the big one, which is now fixed) and the need to call out to ant to do complex stuff because of this.

Let's not forget that Seam is designed as an ant-based project and it may be too late to make it as easy to work with maven as it now works with ant without major rework. And I am not sure if it ever will (and whether it needs to) happen.

Yup, would need some reorganisation. But I need to be convinced that Maven is less flaky before it gets my vote. And I'm still not sure exactly how we would do some things quite so neatly.

Btw, I was surprised how well spring uses optional dependencies (Seam is more complex project so it wont be as easy that's for sure).

I tried hard to get it right for Seam, so any specific feedback on what you would like improved? :-)

[svadu]

Pete Muir wrote on Feb 25, 2008 11:49 PM:

Siarhei Dudzin wrote on Feb 23, 2008 08:18 PM:


Actually the build system is quite OK. Surely it's not as flexible as ant but it serves the need of 80% projects which is quite good achievement I should note.

The nightmare that you might be referring may actually be a single bug (which is resolved for 2.0.9) and I must admit with quite a lot of impact, but let's not forget - projects like jboss embedded are also quite not an average project :). I am not sure what else you may mean by the nightmare.

I dislike somewhat the restrictive layout. But maybe I could get used to that. It also seems a lot slower than ant. The lack of documentation makes life hard, as do the flaky plugins (surefire is the big one, which is now fixed) and the need to call out to ant to do complex stuff because of this.

Well it actually may be seen as restrictive (oh yes, I remember pains I had when switching from 'procedural' ant to 'OO'-ed maven) - that's one point of view.

The longer I work with maven the more I incline to a different point of view - that it requires a better (yes better!) project organization. The 'better' project organization might even be more complex but it will be very structural and consistent (and may even influence the architecture of a project and in most cases in a better way), but this complexity will be hidden behind convention over configuration, because this is exactly what maven does (and so do Seam and RoR don't they?).

As for being slower... well if you just take a timer and compare an ant script and a maven script which build the same project, yes - maven may come last. But if you take, for example, what maven does (remember all the build phases that are being executed) and an ant script which is not just created to 'build' but to fire up all those build phases (resource filtering, generating sources, actually building, testing, etc, etc...) - I wouldn't be so sure about the big performance difference (I never had a privilege of entertaining myself with such measurements so I won't be saying what and how much is faster :) ).

Let's not forget - most ant script are built for specific targets - that's why they are faster (btw Maven 1 was based on ant, which was dropped in version 2.x also because of performance reasons). So yes, a more generic solution (maven) is often slower than a 'fine tuned', specialized one (ant).

Documentation - yes there is that. But once you know how to read the automatically generated spec's it's getting somewhat easier. But I am not denying that the documentation problem doesn't exist.

As for plugins, well... show me a flawless software with a at least a bit of complexity... :) Since it's also community based - everyone is welcome to contribute! (sounds familiar? :) )

Let's not forget that Seam is designed as an ant-based project and it may be too late to make it as easy to work with maven as it now works with ant without major rework. And I am not sure if it ever will (and whether it needs to) happen.

Yup, would need some reorganisation. But I need to be convinced that Maven is less flaky before it gets my vote. And I'm still not sure exactly how we would do some things quite so neatly.

For a such complex project as Seam it actually become just enough 'less flaky' starting from 2.1 or even quite possibly from 2.0.9 (the coming release). Where classpath ordering problems are resolved, since JBoss Embedded is quite a 'sensitive beast' :)

Btw, I was surprised how well spring uses optional dependencies (Seam is more complex project so it wont be as easy that's for sure).

I tried hard to get it right for Seam, so any specific feedback on what you would like improved? :-)

Well, it's hard to tell since it's much easier to criticize someones work than to actually introduce a better solution (and btw big congratz on the work you've done so far!). But here are a few things to think about... For example, right now even if you build for JBoss 4.2.2 (which is as far as I understand Seam 2.0.1 primarily targeted for or tested against) you still need to do quite some dependency management (absence of seam-gen equivalent for maven of course shows).

I think the repository should have either minimalistic set of mandatory dependencies by using optional ones (I must admit I do see a lot of optional dependencies already in 2.0.1 so there is quite a lot of improvement there) or especially tuned for JBoss 4.2.2 (less preferred probably).

So, ideally, you wouldn't want to be constantly busy with excluding transitional dependencies. And since I started using maven from Seam 2.0.0 (and simply changed version and resolved few simple dependency issues when switched to 2.0.1) I might stand corrected on this one...

Probably the ultimate goal would be to have a set of build profiles (like you can build current examples for various platforms) OR/AND a maven plugin which would do the same what seam-gen now does.

Sorry for such long monologue, but the discussion seems to be quite constructive so I gave it a go :)

[keithnaas]

In the last few months we switched to maven as well.  There were some growing pains, but it has been pleasant enough. 

In fact, we have a Flex/Seam project that uses maven as well as Spring projects, archetypes, etc.

The big thing I like from an enterprise perspective is that we can enforce standard behaviors in a super pom.  We use our super pom to define standard plugin configuration, default dependency versions and exclusions, and enforce the use of plugin versions that actually work.  Each project then simply has to define a small amount of stuff to get stared. Since the super pom defines dependency versions and exclusions, one simply needs to write the dependencies groupId and artifactId (everything can still be overridden too). 

<rant>
My biggest gripe isn't necessarily maven, its how some OSS has taken the lazy route when defining their dependencies.  For instance, commons-logging brings in log4j, avalon, and javax.servlet.  Why do I need these when I want to use commons-logging?  Aren't they optional?
<rant/>

I really hope that all of the IDEs - Eclipse in particular - support Maven OOTB.  While the maven-eclipse-plugin is nice, it doesn't treat projects the same way as the maven-war-plugin or the maven-ear-plugin (yes, bugs have been filed for this)

Also, it plays really well with Hudson. 

[keithnaas]

Wish I could edit my last post...hehe

The other smooth thing is that I finally have a standard way to release, branch, tag, etc., with very little work.  Want to release the code base for a project that has 8 different poms, go to the parent project, type in mvn release:prepare, answer a few questions, look at the results and when i'm happy enter mvn release:perform.  Simple, reliable, consistent.