I agree with Jencks that dates are too unpredictable. If there are patches as you described below
(1.1.1-patch-aaron-5 or 1.1.1-2345-fix-by-dain) those are not welformed so the results are undefined.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
