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 20:11:35 GMT
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.

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

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

-dain


Mime
View raw message