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
