Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=CVu/imA/gQN1L9Zu9UiO6UQ8Q2wO+UxOYpcM6JJHVWMtHgQbwPzLtijVtrxGizyn;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <48765D19.2070707@earthlink.net>
Date: Thu, 10 Jul 2008 15:03:53 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: version compatibility plugin?
References: <486BA2DC.4080205@earthlink.net>
	 <059F2165-0B08-4453-9680-BD43FD662B09@yahoo.com>
	 <486BE628.5040809@earthlink.net>
 <486D346A.4020504@earthlink.net>	 <add18bc80807081056w471ab059k89eadf0f5cbb1bde@mail.gmail.com>
	 <4873AC9E.8040601@earthlink.net>
	 <add18bc80807081136s59aff727vfb74d86100a532d2@mail.gmail.com>
	 <4873B71C.1020601@earthlink.net>
 <add18bc80807091248y42b51132qde155baa5df3f322@mail.gmail.com>
 <48751BA1.2080606@earthlink.net>
 <2F4342B6-61BB-4CEF-A794-CBA5D49BB787@yahoo.com>
In-Reply-To: <2F4342B6-61BB-4CEF-A794-CBA5D49BB787@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David,

I started another thread to discuss specifically what we should do with 
samples for 2.1/2.1.1/2.1.2+.  I think there are some unique issues 
regarding compatibility because of the alias resolution issue.  More 
comments below.

David Jencks wrote:
> 
> 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.

This is probably more manageable than directly adding the entries to the 
server files .. but I agree that it might get unmanageable.

> 
> 
>>  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.

makes sense.

>>
>>
>> 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.

I agree that any compatibility solution would require good test 
scenarios and testsuite additions.  It's probably impossible to cover 
every scenario and it won't be easy.  However, we already have some 
real-life scenarios with Directory, samples, server-repo, etc...  I'm 
sure we'll get more as more more plugins are released (roller, life-ray, 
daytraders, etc...).  The alias trick will work in the short term - 
especially since these plugins won't be changing much.  However, I 
wonder what will happen when as Geronimo changes underneath them either 
directly or by changing G dependencies.

In short, I think the alias entries can work in the short term (even if 
they are high maintenance).  I'm just a bit overwhelmed trying to 
understand how compatible things really are between Geronimo releases 
(even minor releases).  I'll experiment some with adding the alias 
entries directly to the plugins - that's a good idea.


> 
> 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 <joe.bohn@earthlink.net> 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 <joe.bohn@earthlink.net> 
>>>>> 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 <joe.bohn@earthlink.net> 
>>>>>>> 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
>>>>
>>
> 
>