You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/04/05 04:35:48 UTC
Dependencies on jars in 1.1 and beyond
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
Re: Shared Libs
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Consider this:
I get my Geronimo environment set up perfectly -- security, database,
JMS, dependencies in the repo, etc. I deploy the empty shell of the
application I want to develop (myapp-1.0.ear).
Now I tell the rest of my team: Install Geronimo, go into the console
Import/Export screen, enter the URL for my machine, click the link to
install myapp-1.0.ear.
Everyone who does that gets the empty application, database pool,
security realm, JMS resources, dependencies in the repo, etc. and can
immediately start development on the application. Too bad it doesn't
check out the code for you too! :)
Thanks,
Aaron
On 4/5/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Aaron,
>
> For the use case of exporting the configuration how do you think folks would use that? At least
> based on my experience with WebSphere and the other AppServers I've often gotten questions from
> people who after using teh big AppServers are torn between the incremental benefit of going to the
> full product and leaving the simplicity of something like Tomcat. I think the shared lib will help
> to bridge that gap for many people. And for those who use it, they probably won't be concerned
> about exporting a configuration.
>
> Aaron Mulder wrote:
> > I'm not so keen on the shared libs, because then we don't know what
> > the dependencies are and it won't be easy to export a configuration
> > with all the necessary metadata. It might be possible to include a
> > flag in the deployment plan saying "enable shared libs" and then if
> > that's set we can refuse to export the configuration or set a special
> > flag saying that the configuration has unknown dependencies. But
> > needing to enable the shared libs would make them a little harder to
> > use. I'm not sure what to think.
> >
> > Thanks,
> > Aaron
> >
> > On 4/5/06, Dain Sundstrom <da...@iq80.com> wrote:
> >
> >>One new feature I'm working on for 1.1 is support for tomcat style
> >>shared libs. This creates a shared class loader visible to all j2ee
> >>applications which contains shared/lib/*.jar and shared/classes/ to
> >>the class loader.
> >>
> >>Will this address your issues?
> >>
> >>-dain
> >>
> >>On Apr 4, 2006, at 7:35 PM, 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
> >>
> >>
> >
> >
> >
>
Re: Shared Libs
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Aaron,
For the use case of exporting the configuration how do you think folks would use that? At least
based on my experience with WebSphere and the other AppServers I've often gotten questions from
people who after using teh big AppServers are torn between the incremental benefit of going to the
full product and leaving the simplicity of something like Tomcat. I think the shared lib will help
to bridge that gap for many people. And for those who use it, they probably won't be concerned
about exporting a configuration.
Aaron Mulder wrote:
> I'm not so keen on the shared libs, because then we don't know what
> the dependencies are and it won't be easy to export a configuration
> with all the necessary metadata. It might be possible to include a
> flag in the deployment plan saying "enable shared libs" and then if
> that's set we can refuse to export the configuration or set a special
> flag saying that the configuration has unknown dependencies. But
> needing to enable the shared libs would make them a little harder to
> use. I'm not sure what to think.
>
> Thanks,
> Aaron
>
> On 4/5/06, Dain Sundstrom <da...@iq80.com> wrote:
>
>>One new feature I'm working on for 1.1 is support for tomcat style
>>shared libs. This creates a shared class loader visible to all j2ee
>>applications which contains shared/lib/*.jar and shared/classes/ to
>>the class loader.
>>
>>Will this address your issues?
>>
>>-dain
>>
>>On Apr 4, 2006, at 7:35 PM, 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
>>
>>
>
>
>
Re: Shared Libs
Posted by Dain Sundstrom <da...@iq80.com>.
I'm not keen on the shared libs concept either, but people are
familar with the feature from Tomcat.
I think we would get tons of emails from confused users if this
feature is not on by default. When it comes to exporting
configurations, we could warn users that the application can see
shared libraries and they will have to install they by hand on the
target server. Alternatively, we could allow the user to select the
shared libs to include in the export, and then we we do an import ask
the user if they want the jars added to the shared libs, or kept
private.
I think we should start with the first option as it is the easiest
and hopefully someone will implement the second.
-dain
On Apr 5, 2006, at 12:05 PM, Aaron Mulder wrote:
> I'm not so keen on the shared libs, because then we don't know what
> the dependencies are and it won't be easy to export a configuration
> with all the necessary metadata. It might be possible to include a
> flag in the deployment plan saying "enable shared libs" and then if
> that's set we can refuse to export the configuration or set a special
> flag saying that the configuration has unknown dependencies. But
> needing to enable the shared libs would make them a little harder to
> use. I'm not sure what to think.
>
> Thanks,
> Aaron
>
> On 4/5/06, Dain Sundstrom <da...@iq80.com> wrote:
>> One new feature I'm working on for 1.1 is support for tomcat style
>> shared libs. This creates a shared class loader visible to all j2ee
>> applications which contains shared/lib/*.jar and shared/classes/ to
>> the class loader.
>>
>> Will this address your issues?
>>
>> -dain
>>
>> On Apr 4, 2006, at 7:35 PM, 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
>>
>>
Re: Shared Libs
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'm not so keen on the shared libs, because then we don't know what
the dependencies are and it won't be easy to export a configuration
with all the necessary metadata. It might be possible to include a
flag in the deployment plan saying "enable shared libs" and then if
that's set we can refuse to export the configuration or set a special
flag saying that the configuration has unknown dependencies. But
needing to enable the shared libs would make them a little harder to
use. I'm not sure what to think.
Thanks,
Aaron
On 4/5/06, Dain Sundstrom <da...@iq80.com> wrote:
> One new feature I'm working on for 1.1 is support for tomcat style
> shared libs. This creates a shared class loader visible to all j2ee
> applications which contains shared/lib/*.jar and shared/classes/ to
> the class loader.
>
> Will this address your issues?
>
> -dain
>
> On Apr 4, 2006, at 7:35 PM, 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
>
>
Re: Shared Libs
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 5, 2006, at 12:55 PM, Joe Bohn wrote:
> I think the shared libraries may solve this issue for a lot of people.
>
> Do you have some more thoughts on how this capability may be made
> available to users? Looking at what was checked in already it
> seems that the user would have to create an array of the libDirs in
> code via some home-grown mechanism and then invoke your class to
> update the classpath. Do you already have plans for an easier way
> to expose this to the users (perhaps via some server configuration
> or some new elements on the deployment plans to add new shared
> libraries)?
The code is not finished :) Is that is will work exactly like
tomcat. The code I checked is a GBean service that will be in a
standard configuration installed into the server. As we deploy j2ee
applications they why have a dependency on this configuration. When
the gbean in this configuration is started it will add the classes
and libraries to the class loader. This will happen automatically
without any user interaction.
-dain
Re: Shared Libs
Posted by Joe Bohn <jo...@earthlink.net>.
I think the shared libraries may solve this issue for a lot of people.
Do you have some more thoughts on how this capability may be made
available to users? Looking at what was checked in already it seems
that the user would have to create an array of the libDirs in code via
some home-grown mechanism and then invoke your class to update the
classpath. Do you already have plans for an easier way to expose this
to the users (perhaps via some server configuration or some new elements
on the deployment plans to add new shared libraries)?
Joe
Dain Sundstrom wrote:
> One new feature I'm working on for 1.1 is support for tomcat style
> shared libs. This creates a shared class loader visible to all j2ee
> applications which contains shared/lib/*.jar and shared/classes/ to the
> class loader.
>
> Will this address your issues?
>
> -dain
>
> On Apr 4, 2006, at 7:35 PM, 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
Shared Libs
Posted by Dain Sundstrom <da...@iq80.com>.
One new feature I'm working on for 1.1 is support for tomcat style
shared libs. This creates a shared class loader visible to all j2ee
applications which contains shared/lib/*.jar and shared/classes/ to
the class loader.
Will this address your issues?
-dain
On Apr 4, 2006, at 7:35 PM, 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
Re: Dependencies on jars in 1.1 and beyond
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I concur.
We need consider how much Maven we are imposing on our users.
anita kulshreshtha wrote:
>
> --- Matt Hogstrom <ma...@hogstrom.org> wrote:
>
>
>>Why do we have to force users to version things? I think we need to
>>assume that perhaps not
>>everyone will like our model. I'd prefer to let them choose rather
>>than be dogmatic about
>>versioning. Just because we like Maven and what it does for use
>>doesn't mean we need to impose it
>>on the user as well.
>>
>>Just my 2c.
>
>
> Even if we do not want to impose on the user, we need to find a
> place to put them in m2 repo. G can convert them to 0-NOVERSION or
> something similar transparently.
>
> Thanks
> Anita
>
>>
>>
>>Jason Dillon wrote:
>>
>>>Why do we need unversioned jars?
>>>
>>>Couldn't we just provide a command line repository tool to help
>>
>>users install jars into the repository with proper names and
>>versions?
>>
>>>or if you like automate the execution of that tool, with a drop
>>
>>folder, where jars would be "deployed" into the repository
>>automatically? Under the covers it would just use the command line
>>repository tool.
>>
>>>--jason
>>>
>>>
>>>-----Original Message-----
>>>From: Dain Sundstrom <da...@iq80.com>
>>>Date: Wed, 5 Apr 2006 11:32:19
>>>To:dev@geronimo.apache.org
>>>Subject: Re: Dependencies on jars in 1.1 and beyond
>>>
>>>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
>>>
>>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
Re: Dependencies on jars in 1.1 and beyond
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Matt Hogstrom <ma...@hogstrom.org> wrote:
> Why do we have to force users to version things? I think we need to
> assume that perhaps not
> everyone will like our model. I'd prefer to let them choose rather
> than be dogmatic about
> versioning. Just because we like Maven and what it does for use
> doesn't mean we need to impose it
> on the user as well.
>
> Just my 2c.
Even if we do not want to impose on the user, we need to find a
place to put them in m2 repo. G can convert them to 0-NOVERSION or
something similar transparently.
Thanks
Anita
>
>
>
> Jason Dillon wrote:
> > Why do we need unversioned jars?
> >
> > Couldn't we just provide a command line repository tool to help
> users install jars into the repository with proper names and
> versions?
> >
> > or if you like automate the execution of that tool, with a drop
> folder, where jars would be "deployed" into the repository
> automatically? Under the covers it would just use the command line
> repository tool.
> >
> > --jason
> >
> >
> > -----Original Message-----
> > From: Dain Sundstrom <da...@iq80.com>
> > Date: Wed, 5 Apr 2006 11:32:19
> > To:dev@geronimo.apache.org
> > Subject: Re: Dependencies on jars in 1.1 and beyond
> >
> > 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
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Dependencies on jars in 1.1 and beyond
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Why do we have to force users to version things? I think we need to assume that perhaps not
everyone will like our model. I'd prefer to let them choose rather than be dogmatic about
versioning. Just because we like Maven and what it does for use doesn't mean we need to impose it
on the user as well.
Just my 2c.
Jason Dillon wrote:
> Why do we need unversioned jars?
>
> Couldn't we just provide a command line repository tool to help users install jars into the repository with proper names and versions?
>
> or if you like automate the execution of that tool, with a drop folder, where jars would be "deployed" into the repository automatically? Under the covers it would just use the command line repository tool.
>
> --jason
>
>
> -----Original Message-----
> From: Dain Sundstrom <da...@iq80.com>
> Date: Wed, 5 Apr 2006 11:32:19
> To:dev@geronimo.apache.org
> Subject: Re: Dependencies on jars in 1.1 and beyond
>
> 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
>
>
Re: Dependencies on jars in 1.1 and beyond
Posted by Jason Dillon <ja...@planet57.com>.
Why do we need unversioned jars?
Couldn't we just provide a command line repository tool to help users install jars into the repository with proper names and versions?
or if you like automate the execution of that tool, with a drop folder, where jars would be "deployed" into the repository automatically? Under the covers it would just use the command line repository tool.
--jason
-----Original Message-----
From: Dain Sundstrom <da...@iq80.com>
Date: Wed, 5 Apr 2006 11:32:19
To:dev@geronimo.apache.org
Subject: Re: Dependencies on jars in 1.1 and beyond
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
Re: Dependencies on jars in 1.1 and beyond
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
>
>
>
>
Re: Dependencies on jars in 1.1 and beyond
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Dependencies on jars in 1.1 and beyond
Posted by Joe Bohn <jo...@earthlink.net>.
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
Re: Dependencies on jars in 1.1 and beyond
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Dependencies on jars in 1.1 and beyond
Posted by Joe Bohn <jo...@earthlink.net>.
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
Re: Dependencies on jars in 1.1 and beyond
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
>