geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: svn commit: r485477 - /geronimo/server/trunk/pom.xml
Date Mon, 11 Dec 2006 23:11:09 GMT
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


Mime
View raw message