persistence@glassfish.java.net

Re: Please review: changes to push new versions to maven repository

From: Wayne Fay <waynefay_at_gmail.com>
Date: Thu, 15 Feb 2007 23:34:30 -0600

A few comments...

1. Once you've published files into your Maven repo, you should
*never* change them. This is a big deal as Maven never checks for
updates to artifacts except for Snapshots. If you start changing your
published artifacts, you can run into situations where half your users
have version 35 (with an error) and the other half have version 35
(with the error fixed). Maven will not know about the updated file, so
all your users will have to dig into their repositories and delete the
files manually, etc which is a nightmare.

2. Given #1 above, if you find a problem in a released file, rather
than replacing the bad file with an updated correct file, you should
just bump the version (ie 1.2.1 becomes 1.2.1.1) and push out a new
release. This applies to poms (with missing or incorrect depdencies
etc) and jars (compiled code, sources, and javadocs).

3. Also given #1 above, you should not "manually relocate" your old
files. Instead, leave them where they are, and just start publishing
the new files under the new groupId. You will want to send some
notifications out so people know about the location of your new
artifacts, of course.

Is there any interest in perhaps adopting the Maven2 layout for your
Java.net repo, in combination with some Apache rewriting to support
your existing Maven1 users, similar to what Maven is doing with their
own repositories? I don't have the complete technical details right
now but this configuration allows them to deploy artifacts to only one
repo (with support for the advanced M2 repo layout/configuration) but
continue to make artifacts available to both groups of users. Just
thought I'd throw that out since we're talking about M1 and M2...
Perhaps its a better question for Kohsuke or someone else?

Thanks.
Wayne

On 2/15/07, Marina Vatkina <Marina.Vatkina_at_sun.com> wrote:
> Wayne,
>
> We are using maven 1, so your pom solution won't work, and it seems that the old
> files must be manually relocated after I create a new groupId. Or am I missing
> something?
>
> thanks,
> -marina
>
> Wayne Fay wrote:
> > Thought I'd also send this link with more information on relocation of
> > artifacts:
> > http://maven.apache.org/guides/mini/guide-relocation.html
> >
> > Wayne
> >
> > On 2/15/07, Wayne Fay <waynefay_at_gmail.com> wrote:
> >
> >> Please be sure to file a relocation pom when you move these artifacts.
> >>
> >> Here's an example:
> >> http://repo1.maven.org/maven2/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
> >>
> >> Thanks.
> >> Wayne
> >>
> >> On 2/15/07, Tom Ware <tom.ware_at_oracle.com> wrote:
> >> > Marina,
> >> >
> >> > Please use "toplink.essentials" as the group id for both the
> >> > toplink-essentials and the toplink-essentials-agent artifacts.
> >> >
> >> > -Tom
> >> >
> >> > Wonseok Kim wrote:
> >> >
> >> > > I checked in the fix.
> >> > > https://glassfish.dev.java.net/issues/show_bug.cgi?id=2405
> >> > > https://glassfish.dev.java.net/issues/show_bug.cgi?id=2409
> >> > >
> >> > > This will be reflected from the next build(b37).
> >> > > I hope Marina to address the maven issues - groupId issue and when to
> >> > > start publishing promoted builds.
> >> > >
> >> > > Also, we need to notify developers and users about the versioning
> >> > > change and the agent integration.
> >> > > I have a plan to post a blog entry for this after b37.
> >> > >
> >> > > Cheers,
> >> > > -Wonseok
> >> > >
> >>
>