On Dec 11, 2006, at 2:53 PM, Paul McMahan wrote:
For the tc6 integration I used "jee5" in the assembly ids because the
jetty assemblies in trunk already used it. I certainly don't mind if
anyone wants to change them.
Ya, I don't think they should have ever been changed to jee5... but
with all the jee5 madness these days its easy enough to understand
how it happened.
Anyways, its minor... just means that we have to keep svn mv'ing
things around as we follow suns ever changing marketing propaganda.
Same thing with jetty/tomcat integration... I don't think we want to
(or plan to) support more than one version of these per G server
release, so the version here in the assembly id just complicates
usage. Meaning when jetty7 is out, then not only do you have to
configure the assembly config with the new artifactId, you also have
to go configure everyone who is using that assembly to use the new
id, that rather negates some of the purpose of that id... its an
alias... saying give me the G server that has jetty.
I agree with you but I thought this was more or less hashed out last
week in this thread:
http://tinyurl.com/ynzhzb
The consensus appeared to me that the tomcat and jetty artifactIds
should include the version numbers so I made the change, although it
was with some trepidation because personally I prefer to keep version
numbers out of the artifactIds. At this point I think we are very
close to tagging 2.0-M1 but maybe there is still time to change it if
you feel strongly.
I'm talking about the g-m-p assembly id, which is a terse alias to an
assembly configuration. That has *nothing* to do with artifactId's
as that thread was talking about. Assembly id's are not artifactId's
and the fact that people having been changing the assembly ids based
on the discussion you note above is a mistake.
I'm not trying to point out any one in particular as making this
mistake, just that it was done and that it should be reverted for the
sake of the projects ongoing build configuration simplicity.
--jason
