geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: We may need to rethink unversioned dependencies among server plans...
Date Thu, 20 Apr 2006 15:23:47 GMT

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