On Jul 9, 2008, at 1:12 PM, Joe Bohn wrote:
Thanks for the post Lin. I was going to start a new thread for this
discussion.
I mentioned a third possibility in the Geronimo 2.1.2 plans
thread ... that is adding the artifact alias entries for 2.1 & 2.1.1
directly into the 2.1.2 server image as part of the release.
I guess each plugin can include aliases for previous versions of
itself and the jars it depends on. This might be better than the
compatibility plugin but might also turn into a maintenance nightmare.
I'm not exactly sure how I feel about this. It would solve the
problem and eliminate the need for a user to manually change the
entries or install a compatibility plugin. On the other hand it
seems a bit heavy-handed and will expose the user a long list of
alias entries if they need to manually change the file themselves.
I also wonder if there are any performance implications as the list
gets longer.
I'd say, no. Currently it's a hashmap lookup and should not be
noticeably affected by the size of the hashmap.
All in all, the alias approach will work in the short term but I
think it's just a band-aid fix. At some point it is going to cause
grief when things are not really compatible but the aliases allow a
user to install anyway. At some point we're going to have to invest
in a more complicated and complete plugin solution that address
compatibility more completely.
Maybe. Testing compatibility would be a nice thing to do but I have
essentially no idea how. Without testing I don't see the point in
making things more complicated and with it I don't see a problem with
the "lots of aliases" approach. Representing the aliases in property
files is not essential and if they start getting unwieldy we could
look for an alternate notation. On the other hand I don't expect
users to be messing with the artifact alias files by hand anyway: i'd
expect that normally they'd only be modified by installing more plugins.
thanks
david jencks
Joe
Lin Sun wrote:
Hi Joe/All,
Finally I was able to deploy the jaxws-calculator car file onto the
server, after adding a bunch of entries in the
artifact-aliases.properties file, which is essentially the same as
what your compatibility plugin does.
We'll have to quickly decide what to do with the compatability issue
otherwise none of our sample will be installable on 2.1.2 server.
One approach is to release the compatibility plugin you worked on.
Is this checked in?
Pros: we can have this quickly and get ready for the 2.1.2 release.
Cons: it is extra work for the user.
The other approach is to add the matching entries to the
artifact-aliases.properties and client_artifact-aliases.properties on
the fly. We'll have to determine how to add them, what to add to
different assemblies (can different assemblies have same entries if
the extra entries don't hurt anything), etc.
Pros: no extra work for the user, assuming the server can add the
common matching entries to different assembly on the fly.
Cons: Could take longer and is this appropriate for 2.1.2 given we'll
release it very soon?
Thanks, Lin
On Tue, Jul 8, 2008 at 2:51 PM, Joe Bohn <[EMAIL PROTECTED]>
wrote:
Lin Sun wrote:
Yes, I am able to move onto the next missing dependency module.
Thanks.
Is there a reason why we need both? I thought we just need one and
version can be omitted on the left side per
http://cwiki.apache.org/GMOxDOC21/how-to-upgrade-jars-and-swap-modules.html
What you need depends on the way the dependency itself is
specified. If it
is specified with the version such as 2.1 then you need the /2.1/
entry.
This is the case for the jsp sample. If it is called out without
a version
then you need the // entry. The doc you referenced calls the
former a
"fixed version".
IIRC the jsp sample had 2.1 in the jasper dependency ... but it
also had a
dependency on the tomcat/jetty car. The tomcat/jetty car has a
dependency
on jasper without the version. You might not need the // entry
but in
general it is usually best to provide both the versioned and non-
versioned
entries.
BTW, I was actually using a quick pass at a compatibility plugin I
had
created for that included all of the cars for the tomcat server
instance ...
so some other dependencies may have been resolved beyond jasper
(such as the
tomcat dependency).
Joe
Lin
On Tue, Jul 8, 2008 at 2:06 PM, Joe Bohn <[EMAIL PROTECTED]>
wrote:
Lin Sun wrote:
Hi Joe,
Is this scenario working for you after your fix? I updated the
artifact-aliases.properties file in var/config manually when
server is
shutdown -
org.apache.geronimo.configs/jasper//
car=org.apache.geronimo.configs/jasper/2.1.2-SNAPSHOT/car
You need one more additional entry ...
org.apache.geronimo.configs/jasper/2.1/
car=org.apache.geronimo.configs/jasper/2.1.2-SNAPSHOT/car
That worked for me.
Joe
However, I am still getting the "Missing dependency:
org.apache.geronimo.configs/jasper/2.1/car" error.
What am I missing? Thanks, Lin
On Thu, Jul 3, 2008 at 4:19 PM, Joe Bohn
<[EMAIL PROTECTED]> wrote:
Joe Bohn wrote:
Ok, I confirmed that DefaultArtifactResolver.queryArtifacts()
was not
including aliases for the query ... hence the problem. Thanks
to a
good
pointer from David Jencks I was able to easily add this into
the query.
I
created GERONIMO-4182 for this problem and checked in a fix for
2.1.2-SNAPSHOT and 2.2-SNAPSHOT.
Unfortunately, that means that we won't be able to use a version
compatibility plugin for anything prior to 2.1.2/2.2 ... so we
will
need
to
come up with another solution for samples or other plugins
created for
Geronimo 2.1 that we want to run on Geronimo 2.1.1.
Joe
Joe
thanks
david jencks
On Jul 2, 2008, at 8:46 AM, Joe Bohn wrote:
I attempted to create a version compatibility plugin such
that
plugins
with dependencies on 2.1 artifacts could attempt to be
installed in
a
2.2-SNAPSHOT server image (mapping 2.1 car artifacts to 2.2-
SNAPSHOT
car
artifacts). However, thus far I'm not having any success.
The plugin is fairly simple. Just a bunch of entries for
artifact
aliases and no other content:
<plugin-artifact>
...
<artifact-alias
key="org.apache.geronimo.configs/jasper//
car">org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car</
artifact-alias>
<artifact-alias
key="org.apache.geronimo.configs/jasper/2.1/
car">org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car</
artifact-alias>
...
I also verified that after installing the compatibility
plugin that
the
entries are added to the artifact-aliases.properties file in
var/config:
...
org.apache.geronimo.configs/jasper//
car=org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jasper/2.1/
car=org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car
...
Yet, even with these entries, I still get essentially the
same error
attempting to install samples created for 2.1 in a 2.2-
SNAPSHOT
server
as I
had without the artifact-alias entries. I showed the
jasper entries
above
because that is the missing dependency when I attempt to
install the
Tomcat
JSP example plugin created for 2.1 on 2.2-SNAPSHOT (see error
below).
I had
similar results on a 2.1.1 server when I attempted to use a
another
compatibility plugin mapping 2.1 cars to 2.1.1. Am I missing
something
obvious?
11:22:45,918 ERROR [PluginInstallerGBean] Unable to install
plugin
org
.apache
.geronimo.kernel.repository.MissingDependencyException:
Plugin
is not installable on Geronimo 2.2-SNAPSHOT
Missing dependency: org.apache.geronimo.configs/jasper/2.1/
car
at
org
.apache
.geronimo
.system
.plugin
.PluginInstallerGBean
.validatePlugin(PluginInstallerGBean.java:920)
at
org
.apache
.geronimo
.system
.plugin
.PluginInstallerGBean
.downloadArtifact(PluginInstallerGBean.java:1081)
...
Joe
