Seam 2.0.0.CR2: lib jars have lost their versions

[tynor]

First thing I note when trying to copy new jars to my project: most of the bundled jar files have changed names - what used to be foo-x.y.z.jar is now just foo.jar. CR1 is somewhat inconsistent - some jars had explicit version names, some didn't. CR2 does away with version numbers in jar names altogether. Boo!

I would strongly prefer that Seam adopt the "everything has a versioned name" convention to make it self documenting via "ls" what jar versions are being used. It is very tedious to have to peek inside each jar looking at MANIFEST.MF to find out what version of each third party library is in play...

Is it too late?

[pmuir]

I think everyone falls on one side of the argument or another here - I much prefer jars *without* version numbers ;)

It's too late for the 2.0.0 release, but there is still work to do in this area, and I will bear this request in mind.

[tynor]

Fair enough. But if Seam is going to take the no version naming convention, it ought to at the very least include a README.txt or VERSIONS.txt file that contains explicit version information for each bundled jar. (and of course, keep that file up to date as newer versions of any given jar are bundled)

(this relates to my JIRA from some time ago: http://jira.jboss.com/jira/browse/JBSEAM-1773)

[matt.drees]

I think /build/root.pom.xml ought to be enough for figuring out versions, so I don't think a VERSIONS.txt file is necessary.

I don't know whether I like version-labeled jars or not.
One thing I like about jars without version numbers is the fact that I can run a copy-lib command to copy seam's lib jars into mine, and outdated jars are just overwritten, instead of me having to manually delete them. This is more useful if you're running off cvs, I guess.

It'd be interesting if you could specify a build parameter that would give you version-labeled jars if you want them. Not as high a priority as many other FRs in jira, though, in my opinion.

[tynor]

I think /build/root.pom.xml ought to be enough for figuring out versions, so I don't think a VERSIONS.txt file is necessary.

Perhaps so. My experience on a previous project that used Maven's ant dependency management plugin (as seam-gen apparently does now), is that the explicit dependencies in the pom.xml only tell you so much -- the transitive dependencies that bring in jars indirectly can be difficult to predict. Fortunately, when using maven dependencies directly, the resulting jars have versioned names (:)), so one could always tell what version it ended up choosing.

I don't want this to turn into a religous argument - i just want an "easy" way to tell what version of any given jar Seam has decided to bundle for me -- so when I add a new jar that also depends on, say, commons-digester.jar, I can quickly tell if it is compatible with the one I've already got.

[pmuir]

So this raises a question on which feedback would be good:

Currently when we create the Seam distribution, we grab all the dependencies and shove them in all in lib/. This has a number of drawbacks

1) Not good for using inside examples (which will soon declare their dependencies through maven

2) Not good for the seam-gen if we decide to use more maven in it

3) Harder to do things like provide example only downloads or downloads without libraries

So, my proposal is that instead of providing a lib directory with loads of thirdparty libraries in it we provide an ant target [1] which will assemble a lib directory [2]. So after downloading the zip, you would run (for example):

ant assemble-libs

Drawback? A little more complex for those who just want to use plain ant.

What do you all think?

[1] If you download "seam-all.zip" you will still have all the required libraries on your machine inside the distribution, just in a mavenized structure. Otherwise this task would reach out to the net/your local maven cache to get the necessary jars.

[2] There could easily be alternative tasks to assemble the libraries with and without version suffixes.

[matt.drees]

I think that sounds like a great idea, though I don't think I understand the drawback you mention. If someone is using plain ant for their project, they can download the seam-all.zip which will have all the third-party libs, which is the same way it's been, right?

[pmuir]

Well rather than just having the lib directory there, you have to run an ant target to create it (the structure you would get in -all would be mavenized i.e. repository/org/drools/drools-core/4.0.1/drools-core-4.0.1.{jar,pom etc} and so no use to ant users).

[tynor]

Well rather than just having the lib directory there, you have to run an ant target to create it (the structure you would get in -all would be mavenized i.e. repository/org/drools/drools-core/4.0.1/drools-core-4.0.1.{jar,pom etc} and so no use to ant users).

That seems to be a very minor inconvenience - especially since it would be a one time thing.

I especially like your suggestion that one could easily produce either versioned or unversioned jar names. Sign me up!

[bsmithjj]

"tynor" wrote:

I think /build/root.pom.xml ought to be enough for figuring out versions, so I don't think a VERSIONS.txt file is necessary.

Perhaps so. My experience on a previous project that used Maven's ant dependency management plugin (as seam-gen apparently does now), is that the explicit dependencies in the pom.xml only tell you so much -- the transitive dependencies that bring in jars indirectly can be difficult to predict. Fortunately, when using maven dependencies directly, the resulting jars have versioned names (:)), so one could always tell what version it ended up choosing.

I don't want this to turn into a religous argument - i just want an "easy" way to tell what version of any given jar Seam has decided to bundle for me -- so when I add a new jar that also depends on, say, commons-digester.jar, I can quickly tell if it is compatible with the one I've already got.

We're a maven2 - seam shop - we use archetypes to start all our Seam projects. Who knows? now that maven2 is getting uptake on this project, maybe someday seam-gen functionality will be available as an archetype... Anyway, since I spend a fair amount of time making sure our internal repository has the right versions of jars and that our archetype poms are correct, I would like to second the request to have the version numbers left on the jar names. It just makes dependency mgmt / troubleshooting much easier (BTW - not all the jar versions are appended to the lib jars in the previous release(s) - is there any chance that things like JBoss jars could have the server-version number they represent appended? things like servlet-api, and jsf-api have the spec numbers appended? as well....).

One other thing- I can indeed review the pom.xml for version numbers, however, flipping between the pom and the file system to make the association is tedious and error prone - especially with many dependencies.

Thanks,
Brad Smith

[jbmadair]

I just figured I should throw in my two-cents that our project is also hurting from this change to not have the version number on the lib.

I know that lots of people say to just look at the maven descriptors, but trying very hard not to start a religious war, we don't do Maven any more in our projects, in our judgment it just wasted our time and couldn't be used in production environments anyway. (I'm appalled if anyone *does* use automated dependency downloads in production, so I'm hard-pressed to see us as unique.)

I'd understand a preference against version numbers being reasonable in a non-public project, but in this case, the framework is all about bringing many disparate libraries together into a useful whole, and so the rest of us really want to be able to eyeball the version numbers used.

In any case, we'll maintain the version numbers on our files if we have to, but it's just a lot harder for us to keep up if they are buried in a pom file somewhere.

Thanks for at least considering an adjustment back to what as far as I know is a fairly accepted convention.

[jbmadair]

One more argument in favor of version-named jars: We often find ourselves for a period of time with more than one version of a library so that our team can test the upgrade in phases. Even more helpful, it lets various users chime in before we make the change permanent in the .classpath and build.xmls.

For instance, the recent Richfaces release had problems with Seam, so the fact that we had multiple releases in the repository saved our butts without having to drag all the repository users through the muck because we hadn't made the change global for everyone in the .classpath and build.xml.

I realize we can do this without version-numbered jars, but this makes it a lot easier.