db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@inamo.no>
Subject Re: Uploading a bundle to ibiblio
Date Fri, 05 Aug 2005 21:08:12 GMT
On Fri, Aug 05, 2005 at 01:54:15PM -0700, Craig Russell wrote:
>    Hi Trygve,
>    On Aug 5, 2005, at 11:50 AM, Trygve Laugstøl wrote:
> 
>      On Fri, Aug 05, 2005 at 11:37:25AM -0700, Craig Russell wrote:
> 
>           Hi Brian,
>           How about the artifact apache-jdo-incubating, and the current jar
>        and pom
>           scheme:
>           jars/jdo2-query-SNAPSHOT.jar
>           jars/jdo2-query-20050805.150654.jar
>           poms/jdo2-query-SNAPSHOT.pom
>           poms/jdo2-query-20050805.150654.pom
>           And so forth for the 10 projects. It seems that we want to keep the
>           current sub-project names (we finally like them I think) and if we
>        need to
>           add "incubating" to the name, fine by me.
>           The sub-projects already include the jdo1 or jdo2 as part of the
>        name,
>           which is important. And having the version number SNAPSHOT is good.
>           Craig
> 
>      I was wondering why you need to include the version in the artifact id?
>      This will become a annoyance in the future with Maven 2 and the other
>      tool
>      that has support for transitive dependencies[1].  In Maven 2 you can
>      have
>      a dependency on artifact A and Maven will look at A's POM and figure out
>      that A depends on X and Y and include those for you.
> 
>    This sounds like a fine feature and I don't see the issue with JDO1 and
>    JDO2. A project will choose which jar to build against and maven will do
>    the right thing.
> 
>      Now this become a issue as you can't have both JDO 1 and JDO 2 in your
>      class path at the same time
> 
>    This is true because of intrinsic differences between the two jars. An
>    application built against JDO 1 will need the JDO 1 jar files, and won't
>    work with JDO 2. We have implemented source compatibility but binary
>    compatibility turned out to be not practical. So once you choose JDO 2,
>    you need to depend on the JDO 2 jar and the JDO 1 jar is worthless.

Ok, sorry, I was assuming that they where going to be binary compatible.

I'm just wondering why was it hard to be binary compatible? As far as I
can tall all changes are binary compatible, but of course I don't have the
full overview.

> 
>      because if A depends on "jdo1" and B depend on
>      "jdo2" I will end up with both of them in my class path. If they both
>      had
>      the artifact id "jdo" Maven's versioning mediation will take care of
>      selecting one or the other based on the current strategy (the strategy
>      by
>      default is to pick the version specified 'neareast' the currently
>      building
>      project).
> 
>    I'm not sure whether this is an issue based on the discussion above. Any
>    project will be using either JDO 1 or JDO 2 and there's no decision for
>    maven to make. And all projects that share a class path have to choose the
>    same one.

Yes it was. Thanks for your clarifications and for getting the JDO
snapshots to the repository will for sure make my life better.

--
Trygve

Mime
View raw message