geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: We may need to rethink unversioned dependencies among server plans...
Date Thu, 20 Apr 2006 16:57:40 GMT
I agree with Jencks that dates are too unpredictable.  If there are patches as you described
(1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain) those are not welformed so the results are

Aaron Mulder wrote:
> My problem with the "version with well-explained scheme" is that it
> basically means there can only be one source of updates.  I mean, it's
> probably OK if you figure you won't be able to apply a WAS CE patch to
> Geronimo or vice versa.  Are we sure we're not going to want to have
> test patches and stuff that we want people to install and try out
> before the official patch release?  Maybe they just need to have
> proper version numbers and the "official patch releases" will tend to
> skip numbers.  I guess that's worked well enoguh for the RPM distros.
> Dain, any thoughts on this?  I think you're the one working on the
> dependency resolving during upgrades at the moment.
> Thanks,
>     Aaron
> On 4/20/06, David Jencks <> wrote:
>>On Apr 20, 2006, at 4:25 AM, Aaron Mulder wrote:
>>>First, can you rev the version of the plugin so we can eliminate that
>>>as a possible source of the problem?
>>will do
>>>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 plan for the runtime server to not have an explicit versions file.
>>I think it should only be used to build a server in the maven repo.
>>>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
>>I prefer version numbers with a well-explained scheme.  Date is too
>>unpredictable IMO.
>>david jencks
>>>    Aaron
>>>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
>>>>>(say, j2ee-system) has a dependency on another (say, rmi-naming),
>>>>>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-
>>>>>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???
>>>>david jencks
>>>>>    Aaron

View raw message