geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: We may need to rethink unversioned dependencies among server plans...
Date Thu, 20 Apr 2006 15:52:38 GMT
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 <david_jencks@yahoo.com> 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
> > number.
>
> I prefer version numbers with a well-explained scheme.  Date is too
> unpredictable IMO.
>
> thanks
> david jencks
>
> >
> > Thanks,
> >     Aaron
> >
> > On 4/20/06, David Jencks <david_jencks@yahoo.com> 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/explicit_versions.properties 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
> >>
> >>
>
>

Mime
View raw message