commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: VOTE: Migrate commons-fileupload to Maven 2
Date Sat, 02 Sep 2006 15:43:42 GMT
On 9/1/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 9/1/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> >

> > <snip>
> > We also need to definitively settle the artifact naming conventions
> > and think carefully about the impact of relocating the fileupload jar.
>
>
>
> I *think* the following strategy will deal with this situation ... and
> should generic to all the commons packages:
>
> * If version x.y.z of Commons package "foo" is published as Maven artifact
>   "commons-foo:commons-foo:x.y.z", publish an *additional* copy of that
>   same version under "org.apache.commons.foo:commons-foo:x.y.z".

Just copying would make the metadata inconsistent, I assume, so I
guess what we would need to do for *released* artifacts would be to
copy the release tag to a new branch, create/edit a pom resolving  to
org.apache.commons.foo:commons-foo:x.y.z, tag this (and the copied
release branch) and then publish.  That way the new version has a
reproducible build.  Before doing this, though, we need to tag and
release the commons parent pom.  There may also be config changes
required to get the previous release branch to build correctly under
m2.

Since to use the relocated jar, users are going to have to change
their dependency specs anyway, I am thinking now that it might be
better to increment the version number by a minor increment in the
process.  It's probably also a good idea to push an rc out and vote
before final publication as well.  So I guess what I am suggesting is
that as part of the m2 migration, we get the most recent release
re-released with a minor increment and whatever config changes are
required to get things to work under m2.  Then back port the config
changes to trunk and continue in m2.

Ugh.  This now looks like too much work, so maybe its better to just
wait for the next release or figure out how to deploy the artifacts
with incorrect or munged metadata.  I don't like the latter so much,
because of the build reproducibility issue.

For snapshots, i.e. n-SNAPSHOT versions, I think it is probably OK to
just post a notice here and to commons-user and move - i.e., stop
publishing the snaps in the "old" location and start publishing them
in the new one.
>
> * For all future versions, use only the"org.apache.commons" group id.
>
> That way, we won't disrupt current Maven-based users of the current
> versions, and we also don't have to wait until each individual package revs
> to publish versions under the new id.  Users who are updating their projects
> to depend on a new version number can easily update the group id at the same
> time.
>
> Does that make any sense?
>
Yes, could be I am making more of this than it is.

Let's at least all agree now that moving forward we publish under the
group id "org.apache.commons."

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message