db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: ArtifactId of jdo projects
Date Wed, 06 Apr 2005 08:44:59 GMT
Hi Brian,

> 
> 
> Craig Russell wrote:
> 
>> Hi Michael,
>>
>> On Apr 5, 2005, at 12:47 PM, Michael Bouschen wrote:
>>
>>> Hi,
>>>
>>> today the jdo project api11 and api20 use the same artifactId 
>>> 'jdo-api', but different version numbers (1.1 vs. 2.0).  I think both 
>>> projects should not share the same artifactId. They implement the JDO 
>>> API as defined in different specs: JDO1 (JSR-12) and JDO2 (JSR-243), 
>>> so they should coexists. I propose to change the artifactId to 
>>> jdo1-api and jdo2-api and do a similar change for ri11, tck11 and tck20.
>>
>>
>>
>> Sounds good.
> 
> 
> +1.  Just ran into this myself.

I have checked in the artifactId changes.

> 
>>>
>>> Another question: the maven doc for the currentVersion project 
>>> descriptor element says: "The current version of the project. This 
>>> should end in -SNAPSHOT until the release of that version is made.". 
>>> I propose to add the '-SNAPSHOT' in the project.xml of the jdo projects.
>>
>>
>>
>> If this is really what other projects do, I'd agree. Do any of you on 
>> this alias have experience with other projects using the -SNAPSHOT 
>> suffix? I assume that this means that the name of the jar is for 
>> example jdo2-api-2.0-SNAPSHOT until we release.
> 
> 
> There's a lot of dragons lurking in this area.  One of the ones that I
> have had a lot of problems with are projects that include the -SNAPSHOT
> suffix in the <version/>.  I would advocate that this is the wrong way
> to do it because it breaks all the snapshot and release tools that are
> built into maven itself.
> 
> Dentaku, XDoclet2, Mule, and all my internal projects use the
> jar:install-snapshot goal as the default goal, which automatically adds
> the suffix.  What's nice is that 'jar:snapshot-deploy' (for those with
> correct privs) will push the jar from your repo to the correct staging
> area for pushing to Ibiblio, without per-user files that need to be
> modified in the RCS areas.  There are similar goals for released version
> pushes.
> 
> When used like this, there is no version number in the SNAPSHOT name,
> i.e. 'jdo2-api-SNAPSHOT.jar'.  I agree that this is the correct
> behavior, since developers who want to be on the bleeding edge and
> always get the latest should not have to change the name of their
> dependencies if there are releases on projects (thus changing the
> version numbers).

Thanks for the info! I agree with what you explained about using 
SNAPSHOT in the version number. I left currentVersion as it was before: 
1.1 and 2.0.

Regards Michael

> 
>>
>> Does release mean an alpha or beta? So when we decide that the api is 
>> ready for external use (I actually think we've made that decision 
>> already) that we would name it jdo2-api-2.0-ALPHA1, or less loudly, 
>> jdo2-api-2.0-alpha1.
> 
> 
> Might want to look through the jars on Ibiblio for this one, most people
> just use (for instance) jdo2-api-2.0a1.
> 
> Is there a definitive release nomenclature on this project yet?  Any
> links if so?
> 
> :b
> 
>>
>> Craig
>>
>>>
>>> What do you think?
>>>
>>> Regards Michael
>>>
>>> -- 
>>> Michael Bouschen        Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de    http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33        Buelowstr. 66           
>>> Fax.:++49/30/2175 2012        D-10783 Berlin          
>>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
> 
> 


-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin			

Mime
View raw message