I can't claim that the scenario will be very common. However, for
completeness, it seems like we need to address the possibility if we
support unversioned jars. Actually, to be clear, I think we need to
speak in terms of a "maven version" versus a "non-maven version". My
real concern is that we shouldn't force users to conform to the maven
version convention if they already have jars that they are using which
either don't include a version at all or don't conform to the maven syntax.
In addition to the 2 issues you mentioned I was trying to get at a 3rd
issue:
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.
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.
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 hope that last point is clear even if we decide that it isn't a
scenario we choose to support.
Joe
Dain Sundstrom wrote:
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
--
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
