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
