You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Bouschen <mb...@spree.de> on 2005/04/05 21:47:06 UTC
ArtifactId of jdo projects
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.
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.
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
Re: ArtifactId of jdo projects
Posted by Craig Russell <Cr...@Sun.COM>.
Hi,
I guess this discussion is about publishing on ibiblio. We need to have
distinctive jar file names that folks can use to figure out what to
get. And there is not necessarily a 1-1 correspondence between what we
build in Apache JDO and what binaries show up on ibiblio.
1. Is it agreed that ibiblio need not have a source distribution? I
think if anyone needs the sources then they can download them directly
from the svn repo on Apache.
So we have to come up with packaging that makes sense. And it isn't
obvious to me that we want a jar file for each project in JDO. For
example, we probably want to split out the current ri11 into a few
projects when we migrate the code to 20, because we can use different
pieces in different areas. Does this mean that each subproject would
get its own jar on ibiblio? One example of this is the model which we
expect can be used in a UI without needing the enhancer, runtime,
fostore, or even the jdo.jar. This probably deserves its own jar file.
But we have a number of utility classes that the other subprojects all
need, and I don't think we should create a jdo2-utility-2.0-a1 just for
10 classes.
2. I agree that we should include "apache-jdo" when it's the apache
implementation not the api or tck that we're distributing. So it's a
matter of where we put the "apache-jdo" in the name. In the case of the
model, perhaps something like "apache-jdo1-model-2.0-a1.jar" where the
artifact-id is "apache-jdo1", the version is "2.0" and the vehicle is
"-a1". And "apache-jdo2-fostore-a1.jar".
We need to decide on the names for the non-implementation jar file
names as well. A side note: we should be careful not to call these
"official JDO TCK" and "official JDO API". The "official" distribution
can only come from the JCP web site where they can make sure that
people click the license that carries some real restrictions. What
we're building in Apache is fed into the JCP process but it's not a
substitute for it.
3. For the binary distribution of the 2.0 TCK, how about
"jdo2-tck-a1.jar" that doesn't reflect the Apache heritage. And
"jdo2-api-a1.jar" for the specification api.
Craig
On Apr 14, 2005, at 11:34 AM, Brian Topping wrote:
> Indeed, I think I said "implementation".
>
> :b
>
> Andy Jefferson wrote:
>
>> On Thursday 14 Apr 2005 19:09, Brian Topping wrote:
>>
>>> I'm also a bit concerned about the groupId WRT to it's name in the
>>> listing for ibiblio. I believe 'jdo' is a bit too generic, and does
>>> nothing to distinguish the apache JDO from other implementations as
>>> it
>>> should.
>>>
>>> I would suggest 'apache-jdo' at the very minimum for this. Any
>>> objections or better suggestions?
>>>
>>
>> Depends which project's groupId you're referring to here. Apache JDO
>> encompasses many things. The "jdo.jar" is a generic interface (under
>> "api20"). It should be under "jdo" IMHO. It isn't an implementation.
>> It's the definitive interface for that technology
>>
>>
>>
>>
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!
Re: ArtifactId of jdo projects
Posted by Brian Topping <to...@codehaus.org>.
Indeed, I think I said "implementation".
:b
Andy Jefferson wrote:
>On Thursday 14 Apr 2005 19:09, Brian Topping wrote:
>
>
>>I'm also a bit concerned about the groupId WRT to it's name in the
>>listing for ibiblio. I believe 'jdo' is a bit too generic, and does
>>nothing to distinguish the apache JDO from other implementations as it
>>should.
>>
>>I would suggest 'apache-jdo' at the very minimum for this. Any
>>objections or better suggestions?
>>
>>
>
>Depends which project's groupId you're referring to here. Apache JDO
>encompasses many things. The "jdo.jar" is a generic interface (under
>"api20"). It should be under "jdo" IMHO. It isn't an implementation. It's the
>definitive interface for that technology
>
>
>
>
Re: ArtifactId of jdo projects
Posted by Andy Jefferson <an...@jpox.org>.
On Thursday 14 Apr 2005 19:09, Brian Topping wrote:
> I'm also a bit concerned about the groupId WRT to it's name in the
> listing for ibiblio. I believe 'jdo' is a bit too generic, and does
> nothing to distinguish the apache JDO from other implementations as it
> should.
>
> I would suggest 'apache-jdo' at the very minimum for this. Any
> objections or better suggestions?
Depends which project's groupId you're referring to here. Apache JDO
encompasses many things. The "jdo.jar" is a generic interface (under
"api20"). It should be under "jdo" IMHO. It isn't an implementation. It's the
definitive interface for that technology
--
Andy
Java Persistent Objects JDO - JPOX
Re: ArtifactId of jdo projects
Posted by Brian Topping <to...@codehaus.org>.
I'm also a bit concerned about the groupId WRT to it's name in the
listing for ibiblio. I believe 'jdo' is a bit too generic, and does
nothing to distinguish the apache JDO from other implementations as it
should.
I would suggest 'apache-jdo' at the very minimum for this. Any
objections or better suggestions?
:b
Michael Bouschen wrote:
> Hi Geir,
>
> you are right, the name of the jar file is not a problem. I ran into
> the problem when using the maven multi project plugin. It
> automatically finds api11, but ignores api20 since both use the same
> artifactId. I think api20 is not just the successor of api11. Both
> projects should coexists.
>
> Regards Michael
>
>>
>> On Apr 5, 2005, at 3: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.
>>
>>
>>
>> I don't understand the problem.
>>
>> you'd have
>>
>> jdo-api-1.1.jar
>>
>> and
>>
>> jdo-api-2.0.jar
>>
>> Aren't these pretty clear and distinct?
>>
>> geir
>>
>>
>>>
>>> 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.
>>>
>>> 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
>>>
>
>
Re: ArtifactId of jdo projects
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Geir,
I don't think we have a kludge, but have a clean way to separate two
entities. Maven is not part of the problem.
We have two separate specifications that have their own independent
existence in the JCP: JSR 12 and JSR 243. There will be a maintenance
release of JDO 1 once the work in Apache is complete, and users will be
able to download the unofficial jars from Apache once this happens.
Craig
On Apr 18, 2005, at 11:16 AM, Geir Magnusson Jr wrote:
> Sorry - disappeared for a while.
>
> So this whole naming kludge is because of maven?
>
> geir
>
> On Apr 6, 2005, at 6:05 AM, Michael Bouschen wrote:
>
>> Hi Geir,
>>
>> you are right, the name of the jar file is not a problem. I ran into
>> the problem when using the maven multi project plugin. It
>> automatically finds api11, but ignores api20 since both use the same
>> artifactId. I think api20 is not just the successor of api11. Both
>> projects should coexists.
>>
>> Regards Michael
>>
>>> On Apr 5, 2005, at 3: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.
>>> I don't understand the problem.
>>> you'd have
>>> jdo-api-1.1.jar
>>> and
>>> jdo-api-2.0.jar
>>> Aren't these pretty clear and distinct?
>>> geir
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>
>>
>> --
>> 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
>>
>>
> --
> Geir Magnusson Jr +1-203-665-6437
> geir@gluecode.com
>
>
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!
Re: ArtifactId of jdo projects
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Sorry - disappeared for a while.
So this whole naming kludge is because of maven?
geir
On Apr 6, 2005, at 6:05 AM, Michael Bouschen wrote:
> Hi Geir,
>
> you are right, the name of the jar file is not a problem. I ran into
> the problem when using the maven multi project plugin. It
> automatically finds api11, but ignores api20 since both use the same
> artifactId. I think api20 is not just the successor of api11. Both
> projects should coexists.
>
> Regards Michael
>
>> On Apr 5, 2005, at 3: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.
>> I don't understand the problem.
>> you'd have
>> jdo-api-1.1.jar
>> and
>> jdo-api-2.0.jar
>> Aren't these pretty clear and distinct?
>> geir
>>>
>>> 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.
>>>
>>> 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
>>>
>
>
> --
> 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
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: ArtifactId of jdo projects
Posted by Michael Bouschen <mb...@spree.de>.
Hi Geir,
you are right, the name of the jar file is not a problem. I ran into the
problem when using the maven multi project plugin. It automatically
finds api11, but ignores api20 since both use the same artifactId. I
think api20 is not just the successor of api11. Both projects should
coexists.
Regards Michael
>
> On Apr 5, 2005, at 3: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.
>
>
> I don't understand the problem.
>
> you'd have
>
> jdo-api-1.1.jar
>
> and
>
> jdo-api-2.0.jar
>
> Aren't these pretty clear and distinct?
>
> geir
>
>
>>
>> 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.
>>
>> 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
>>
>>
--
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
Re: ArtifactId of jdo projects
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Apr 5, 2005, at 3: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.
I don't understand the problem.
you'd have
jdo-api-1.1.jar
and
jdo-api-2.0.jar
Aren't these pretty clear and distinct?
geir
>
> 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.
>
> 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
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: ArtifactId of jdo projects
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Brian,
On Apr 5, 2005, at 6:11 PM, Brian Topping wrote:
>
>
> 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.
>
>>>
>>> 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).
I think I understand this, and agree. I'm keen on having the discussion
on binary releases now that we are at a point in both projects where a
release makes sense.
I think the api11 is ready today for alpha; ri11 is ready if we can
skip upgrading the enhancer to handle J5 classes; tck11 is ready today.
I think api20 is ready today for a SNAPSHOT; might need a vote whether
it's ready for an alpha. I don't think tck20 is ready for alpha; does
it need anything special for a snapshot?
Craig
>
>>
>> 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!
>
>
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!
Re: ArtifactId of jdo projects
Posted by Michael Bouschen <mb...@spree.de>.
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
Re: ArtifactId of jdo projects
Posted by Brian Topping <to...@codehaus.org>.
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.
>>
>> 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).
>
> 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!
Re: ArtifactId of jdo projects
Posted by Craig Russell <Cr...@Sun.COM>.
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.
>
> 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.
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.
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!
Re: ArtifactId of jdo projects
Posted by Michelle Caisse <Mi...@Sun.COM>.
Sounds good to me. Welcome back!
-- Michelle
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.
>
> 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.
>
> What do you think?
>
> Regards Michael
>