geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Dependencies on jars in 1.1 and beyond
Date Wed, 05 Apr 2006 22:07:35 GMT

Dain Sundstrom wrote:
> On Apr 5, 2006, at 12:45 PM, Joe Bohn wrote:
>> 1) where do we put the jars physically?
>> - I'm not sure I follow the need to add the jars to the root of the  
>> repo.  My assumption was that we would continue to follow the  
>> groupID/jar organization.  Since the groupID doesn't actually get  
>> included in the physical file name, I don't think there is a  problem 
>> from a user perspective if we stick to the group/jars  structure (if 
>> maven can handle jars under a group that aren't  versioned .... not 
>> sure if this is case or not).  Since my main  concern was to avoid the 
>> need to rename the jars I don't think the  group is a big deal.
> In branch 1.1 we have switched to the m2 repository layout which has  
> the following format:
> com/mycompaony/artifactId/version/artifactId-version.type
> The code is only going to match properly formatted jars.  In addition  
> as we move on to using real maven to manage the repo, every jar  should 
> have a checksum file and a pom.
> So, I don't think we should be encouraging users to put their jars  into 
> the repo by hand because they are likely to get it wrong, which  is why 
> I suggest we just create a dumping ground for the jars.  Also,  users 
> will hate creating all the directories :)
>> 2) How do we treat these jars in the server?
>> - Within the server I think it's fair to treat these jars as if  they 
>> were maven version 0.0.0-0.  In this case the non-maven  version jar 
>> would be used in the case that the dependency omits the  version and 
>> there is no maven version of the jar available.  In  fact, I think 
>> this is good because it gives users a way to  gradually move from the 
>> non-maven version jars to the maven  convention gradually as they 
>> upgrade each jar.  Without changing  any dependencies they will 
>> automatically pick up the newer  version.   Of course, that assumes 
>> that the jar didn't already  follow a non-maven version scheme (such 
>> as _1_1_0) in which case  they may have to change the artifact portion 
>> of their dependencies  as they convert to maven versions.
> Again, I'm not sure that is a scenario we need to support.  I think  in 
> most cases where people are using unversioned jars, I would assume  that 
> they will just pack them in their WEB-INF/lib directory, so we  are 
> talking about a rare use case (BTW I may be missing some obvious  set of 
> users).  Anyway, if a user decides to switch to a fully  versioned jar 
> then they will have to rewrite the dependency tag to  include the groupId.

I would think based on Aaron's observations in another thread on sharedLibs that there may
be a set 
of customers that simply want to include a set of common jars in their server for download
follows the flat model.

>> 3) How do we specify dependencies on non-versioned jars?
>> - Even though I like the approach presented in the previous  question 
>> is still makes it does take away some control from the  user.  With 
>> maven versions a user a choose to either ignore the  version or use a 
>> specific version.  However, with this approach  there is no way to use 
>> a specific non-versioned jar if there is a  newer versioned one 
>> available.  One way to solve this odd case  would be to have a keyword 
>> value for the version field such as  "null" which would mean that the 
>> dependency can only be fulfilled  by a the non-maven versioned jar.  
>> If no such jar exists we could  then look use the latest maven version 
>> available.  However, if it's  useful to use a lower maven versioned 
>> jar then I think it would  also be useful to use a lower non-maven 
>> versioned jar.
> I was thinking of something like this:
> <dependency>
>   <artifactId>mattsjar-1.0.jar</artifactId>
> </dependency>
> or
> <dependency>
>   <artifactId>mattsjar-1.0</artifactId>
>   <type>jar</type>
> </dependency>

I think the question is whether we force users into versioning.  If you use versioning then
should follow the Maven model.  If you don't want versioning then you look for the artifactId
type (if specified) and ignore versioning.

> the default type is "jar" so the it could be left out of the above  
> dependency declaration.
> -dain

View raw message