geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: We may need to rethink unversioned dependencies among server plans...
Date Thu, 20 Apr 2006 11:25:51 GMT
First, can you rev the version of the plugin so we can eliminate that
as a possible source of the problem?

Second, what happens when we go to upgrade j2ee-server from 1.1(.0) to
1.1.1 at runtime?  During that redeploy operation, both 1.1.0 and
1.1.1 will be present in the config store, and the configuration
manager has to re-resolve all the dependencies, and I don't think it's
workable to have an explicit version file at runtime (when who knows
which patches will be applied in which order).

I think we need to adopt a strategy of either favoring the newest
entry in the config store by date or favoring the highest version
number.  I think I'd prefer to give the newest entry precedence.  It
does mean that if you have 1.1.2 and later install 1.1.1 it will
downgrade, but that seems better to me than try to decide whether
1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain has a higher version


On 4/20/06, David Jencks <> wrote:
> On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote:
> > So I'm having a build problem.
> >
> > The root cause appears to be that my local Maven repo has both
> > 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts.  One of the server artifacts
> > (say, j2ee-system) has a dependency on another (say, rmi-naming), and
> > that dependency has no version.
> >
> > So when the packaging plugin packages j2ee-system, it asks the
> > repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT
> > instead of rmi-naming/1.1-SNAPSHOT
> >
> > I'm not sure what we can do about this.  I'll think about it a bit.
> hmm, this appears to be working ok on my machine, maybe I don't have
> enough 1.2 artifacts on it.
> The way it's supposed to work is that the artifact resolver has a map
> of explicit versions to use for unversioned artifacts.  This is
> currently etc/ for the packaging and
> assembly plugins.  You can have entries of the form groupid/
> artifactid//type=version or groupid///=version; the former are
> checked first.
> Since on my machine nothing was working when this file was missing/
> incorrect, and adding entries (such as for xmlparserapis) has fixed
> problems, I'm inclined to think it's working properly.  I did forget
> to bump the version number on the plugins, perhaps your problems are
> from an out of date plugin???
> thanks
> david jencks
> >
> > Thanks,
> >     Aaron

View raw message