Instructions: http://maven.apache.org/reference/r...ory-upload.html

basically for each artifact:
cd module-name && maven create-upload-bundle

which will create a bundle in the target dir, put the created bundle
jars somewhere that the ibiblio/maven folks can access them and
create a JIRA issue via the link at the page above to post them to
ibiblio. Voila!

-Brian

[ Post a follow-up to this message ]

I have been informed that we need to clearly mark the artifact as
incubating as well, so we may need to change artifact id to somthing
like jdo2-incubating

Also, we *may* be able to just use the repo on cvs.apache.org.

Let me ask on general@incubator before anyone posts anything to ibiblio.

-Brian

On Aug 5, 2005, at 1:39 PM, Brian McCallister wrote:

> Instructions: http://maven.apache.org/reference/r...ory-upload.html
>
> basically for each artifact:
> cd module-name && maven create-upload-bundle
>
> which will create a bundle in the target dir, put the created
> bundle jars somewhere that the ibiblio/maven folks can access them
> and create a JIRA issue via the link at the page above to post them
> to ibiblio. Voila!
>
> -Brian
>
>
>
>
>
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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 p
om
>    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 hav
e
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.

Now this become a issue as you can't have both JDO 1 and JDO 2 in your
class path at the same time 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).

[snip]

[1]: http://maven.apache.org/maven2/depe...-mechanism.html

--
Trygve

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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 ja
r
>        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 keept
he
>           current sub-project names (we finally like them I think) and ifw
e
>        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 go
od.
>           Craig
> 
>      I was wondering why you need to include the version in the artifact i
d?
>      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 figureo
ut
>      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 d
o
>    the right thing.
> 
>      Now this become a issue as you can't have both JDO 1 and JDO 2 in you
r
>      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 strateg
y
>      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. An
y
>    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 chooset
he
>    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

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]