Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of jason.dillon@gmail.com
 designates 64.233.166.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=cRPoeTB0mkRYcoFyStZ6rSuQynZ49h/d5qHglGjHMo8mDKyeuSznxZFl4gbFkUVSDjHnUkxCh6CPYQJ+3QRRxbEBgkK0XlpIoQKQ38PybnYCe3Sbwb82lIgUO+Ep36Bum0taLqHDzeNhLYkP4mNggghijF1NxBtvmncvEqyzeqA=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <7CFA00A0-1E14-434D-8AEA-AA6F6EC8F25A@yahoo.com>
References: <6B45DA13-914E-4465-8C49-89672419883C@planet57.com>
 <7CFA00A0-1E14-434D-8AEA-AA6F6EC8F25A@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7EF6A1C4-1309-4F07-A6A6-3835B2B21FA1@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
Date: Thu, 29 Mar 2007 12:03:12 -0700
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

> This is not our version, its the version of the spec.

Its still a version number in an artifactId... regardless of who's  
version it is.

The problem with this is that when you go to change versions you have  
to go update a bunch of poms to fix their artifactId instead of  
simply updating one dependency in a dependencyManagement section.

Because we put version numbers in artifactIds we've given ourselves a  
lot more maintenance work when it comes time to rev specs and because  
of this we have made it far to easy to missing them and get modules  
out of sync.


> IIRC we had a big discussion about the best spec naming convention  
> and decided this was it.

So because of that its not something that can be changed?  I really  
disagree with this practice.  It really only make *more* maintenance  
work and increases the chances of something getting out of sync.  Its  
far to easy to end up with several different versions of the same  
spec in a project because the normal maven version resolution can't  
figure out which one to use because of the version information  
encoded in artifact ids.


> Despite our best intentions, we often end up releasing corrections  
> to spec jars we've published.  Can you suggest a different naming  
> convention that will clearly and unambiguously show both the spec  
> version and the geronimo version of a spec jar?  Or do you think  
> one of these is unnecessary?

I think that all relevant information can be encoded in the artifacts  
version.  And I think that the geronimo version is mostly irrelevant,  
its basically a revision of the sun version, so I would just put a  
counter on the end of the sun version:

   <specVersion>-<geroniomRev>

   1.0-1

This helps do away with inconsistencies which we have now, with  
picking 1.1 or 2.0 or 1.0m2 or whatever... just keep incrementing the  
revision when there are changes.

Some real examples:

<current> ---> <suggest> (w/o version in artifactId):
geronimo-j2ee-management_1.1_spec-1.0-M1.jar -> geronimo-j2ee- 
management-spec-1.1-1.jar
geronimo-j2ee-management_1.0_spec-1.0.jar -> geronimo-j2ee-management- 
spec-1.0-1.jar
geronimo-j2ee-management_1.0_spec-1.0.1.jar -> geronimo-j2ee- 
management-spec-1.0-2.jar
geronimo-j2ee-management_1.0_spec-1.1.jar -> geronimo-j2ee-management- 
spec-1.0-3.jar

> As you can probably tell, I think this is a very good practice.  I  
> hate it when someone says they depend on "servlet.jar" and I have  
> to open the spec jar up and try to figure out if whoever generated  
> it bothered to include any information at all about which spec  
> version they implemented.

Well, lucky for you w/maven the version information is encoded in the  
jar file names by default.  So its quite easy to just use the  
"version" of an artifact to contain all of the versioning details and  
you will end up with an artifact with that information in the filename.

--jason