geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Dependencies on jars in 1.1 and beyond
Date Wed, 05 Apr 2006 18:32:19 GMT
Do we need to support this scenario?  It seems far fetched to have  
both a mattsjar.jar and a mattsjar-1.0.jar available.

As for unversioned jars, I think we need to decide how we want to  
handle these in the repository.  I see two issues that we need to  
address: where do we put the jars physically in the server, and how  
to we treat these jars in the server?

For the first, I was thinking we could just let users dump  
unversioned jars in the root of the repository dir.  The the server  
would treat them as belonging to the unspecified (default) group and  
have a version of 0.0.0-0.  I don't think having extra jars in the  
root of the repo will hurt the maven code, but we do have some weird  
side effects of the making the jar version 0.0.0-0.  What if the user  
puts the mattsjar-1.0.jar in the root directory?  It will have name  
"mattsjar-1.0" and version "0.0.0-0".  We could decide to attempt to  
parse the version out of the jar, but that will not work reliably as  
people put jars in with poorly formed names like mattsjar1.0.jar or  
mattsjar-jdk-1.4.jar.

How do you think we should handle this?

-dain

On Apr 5, 2006, at 6:06 AM, Joe Bohn wrote:

> Yes, I agree that the assumption would be a non-versioned jar would  
> be considered version 0.0.   But I haven't thought of a way yet to  
> support both versioned and unversioned jars when calling out the  
> dependency without a schema change.
>
> For example, suppose the repo contains both mattsjar.jar and  
> mattsjar-1.0.jar.  If I want the latest version of a jar in  
> Geronimo 1.1 I just omit the version number from the dependency.   
> No version number = the latest version number.  So, that means that  
> we can't use the lack of a version number to mean we have a  
> dependency on the unversioned jar. Short of a change in the schema,  
> I'm not sure how to support both versioned and unversioned jars  
> with an optional version element.
>
> I hate to open this issue up again now .... but I think we need to  
> consider this if we want to support unversioned jars (which I think  
> would make the life a bit easier for our users).
>
> Joe
>
>
> Matt Hogstrom wrote:
>> I think an implicit Version of 0.0 might be reasonable for jars  
>> that do not follow Maven conventions.  Personally I think forcing  
>> everyone to rename their jars is a bit intrusive as not everyone  
>> would want / need to do this.
>> How about this:
>> mattsjar.jar would be implicitly mattsjar-0.0.jar without the  
>> usewr having to change a thing.
>> Thoughts?
>> Matt
>> Joe Bohn wrote:
>>>
>>> I have a situation where I need to make several web modules  
>>> dependent upon a large number of jars.  I'd like to add the jars  
>>> to the Geronimo repo and add the dependencies into the plans for  
>>> the web modules. However, most of the jars don't follow the maven  
>>> naming convention because the names don't include a version (and  
>>> I'd rather not rename all the jars).
>>>
>>> I know that there are changes being included in 1.1 to make the  
>>> version in a reference optional.  However, I doubt that it is  
>>> possible to reference a jar in the repo that doesn't contain any  
>>> version.  Just thought I should ask in case it really is  
>>> possible.  I could see where this might be something users would  
>>> like when they have picked up jars from various places which may  
>>> or may not contain a version in the jar name.
>>>
>>> If it *is* possible to have a non-versioned jar in the repo ...  
>>> how do we differentiate in geronimo 1.1 between a dependency on a  
>>> non-versioned jar versus a dependency on the latest version of a  
>>> jar (in case both are present).
>>>
>>> Thanks for the help,
>>> Joe
>>>
>
> -- 
> Joe Bohn
> joe.bohn at earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he  
> cannot lose."   -- Jim Elliot


Mime
View raw message