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 that
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 one
should follow the Maven model. If you don't want versioning then you look for the artifactId and
type (if specified) and ignore versioning.
the default type is "jar" so the it could be left out of the above
dependency declaration.
-dain
