You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@coredevelopers.net> on 2003/08/16 13:36:00 UTC
[build] Dependency management
I would like to change the build system to provide better dependency
management, specifically so that all modules which depend on something
use the same version of that dependency.
Currently with the modular build, there is no easy way to load global
properties such that they are available for use inside of project.xml.
If this was the case we could use properties to handle dependency
versioning. If project.xml was a Jelly script (as the Maven user-guide
suggests it is), then we could use Jelly to handle including dependency
information, which IMO is the best option... but short-term until Maven
has better support we should implement something which does not require
a modification to Maven code.
James and I have talked about this some, and have came up with some
ideas. Some which require modifications to Maven have been
communicated back to the Maven Users list, but I do not know how soon
or even if those changes will make it in to Maven any time soon.
James suggested creating a meta module which had all of the
dependencies for the entire project and then as a default target would
re-install those dependencies with a special version token (similar to
SNAPSHOT). Basically if a module depends on mx4j-jmx-SNAPSHOT.jar,
this meta module would depend on:
<dependency>
<groupId>mx4j</groupId>
<artifactId>mx4j-jmx</artifactId>
<version>SNAPSHOT</version>
<url>http://mx4j.sourceforge.net</url>
</dependency>
And such it would check for a newer version when executed. The meta
module would then re-install the dependency with a version like
CURRENT, possibly into a seperate group, like geronimo-dependency, to
keep the hack localized to Geronimo until Maven can handle this problem
nativly.
A regular module which depens on mx4j-jmx would depend on:
<dependency>
<groupId>geronimo-dependency</groupId>
<artifactId>mx4j-jmx</artifactId>
<version>CURRENT</version>
</dependency>
I like this idea as a short-term solution because it will fit our needs
and it will also speed things up a tad as modules which depend on a
SNAPSHOT will not attempt to download a new artifact which may have
already been checked for a newer version by a previous module.
The downside is that the dependency meta module will need to be
depended upon by all other modules and it will have to be executed
before modules will function outside of the reactor. I do not think
this is a big deal as there are already such problems when trying to
perform a clean build when dependencies have not been fully resolved.
Comments? Suggestions?
--jason
Re: [build] Dependency management
Posted by Jason Dillon <ja...@coredevelopers.net>.
>> The problem with this approach is that all modules now have extra
>> bits on their class-path, which is not desired.
>
> huh? If it is a common dep, it should be there, if its not, it should
> not be? Does not compute?
If a project has 10 modules, 3 of which depend on commons-logging it is
still a common dependency for the project but should not be forced to
be a dependency of the other 7 modules in the project.
>> Also, I have tried using SNAPSHOT for intra-project depends, but
>> Maven still tries to download newer versions from the remote repo
>> which is silly and just slows things down.
>
> http://maven.apache.org/reference/user-guide.html#Building%20Offline
>
> you can use the '-o' switch with maven to make it not connect at all.
Yes I understand this, but it is stupid for Maven to even try since
these are locally installed artifacts, which is why we have not been
using SNAPSHOT but instead use DEV.
--jason
Re: [build] Dependency management
Posted by Leo Simons <le...@apache.org>.
Jason Dillon wrote:
>> Write a base project.xml containing the common deps (like
>> commons-logging) and
>> other common info, write a base maven.xml that fires up a reactor
>> that calls the
>> 'jar:install-snapshot' goal, and life will be much easier already.
>> Declare all
>> intra-project dependencies as SNAPSHOT to make sure you always get
>> the latest
>> generated jar.
>
> The problem with this approach is that all modules now have extra bits
> on their class-path, which is not desired.
huh? If it is a common dep, it should be there, if its not, it should
not be? Does not compute?
> Also, I have tried using SNAPSHOT for intra-project depends, but Maven
> still tries to download newer versions from the remote repo which is
> silly and just slows things down.
http://maven.apache.org/reference/user-guide.html#Building%20Offline
you can use the '-o' switch with maven to make it not connect at all.
cheers!
- Leo
Re: [build] Dependency management
Posted by Stephen McConnell <mc...@apache.org>.
Jason Dillon wrote:
>> Which is what you want if you have on-the-bleeding-edge dependencies.
>
>
> Not all dependencies have SNAPSHOT releases.
That's understood. Just keep in mind that if you have jar files that
are being updated frequently, you really should be marking them up as
snapshots, otherwise you will end up inconsitencies in the builds as
soon as you start breaking the system into manageble chunks. My
experience has been that its much easier to put in place SNAPSHOT at the
beginning.
Stephen.
>
>
> --jason
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
Re: [build] Dependency management
Posted by Jason Dillon <ja...@coredevelopers.net>.
> Which is what you want if you have on-the-bleeding-edge dependencies.
Not all dependencies have SNAPSHOT releases.
--jason
Re: [build] Dependency management
Posted by Stephen McConnell <mc...@apache.org>.
Jason Dillon wrote:
>> Write a base project.xml containing the common deps (like
>> commons-logging) and
>> other common info, write a base maven.xml that fires up a reactor
>> that calls the
>> 'jar:install-snapshot' goal, and life will be much easier already.
>> Declare all
>> intra-project dependencies as SNAPSHOT to make sure you always get
>> the latest
>> generated jar.
>
>
> The problem with this approach is that all modules now have extra bits
> on their class-path, which is not desired.
Dependencies should not go into a root defintion - you keep those in the
concrete project descriptors. The value of the root defintion is for
things like generic information (orgnaization, committers, etc.).
> Also, I have tried using SNAPSHOT for intra-project depends, but Maven
> still tries to download newer versions from the remote repo which is
> silly and just slows things down.
Which is what you want if you have on-the-bleeding-edge dependencies.
Stephen.
>
> --jason
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
Re: [build] Dependency management
Posted by Bill de hÓra <bi...@dehora.net>.
Siva wrote:
> I keep a build.properties inside incubator-geronimo which specifies this
> property.
>
> When i go online using my slowwwww dialup connection,i set it to true,rest
> of the time false :)
I added a localmaven script to my path that calls maven with that flag:
#!/bin/sh
maven -Dmaven.mode.online=false
saves you having to change a file. Damn, I need ADSL.
Bill de hÓra
Re: [build] Dependency management
Posted by Siva <si...@sivasundaram.com>.
I keep a build.properties inside incubator-geronimo which specifies this
property.
When i go online using my slowwwww dialup connection,i set it to true,rest
of the time false :)
Siva
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 16, 2003 8:54 PM
Subject: Re: [build] Dependency management
Re: [build] Dependency management
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Sat, 16 Aug 2003, Siva wrote:
> Did u try with by setting maven.mode.online=false?
Nope -- where do I set that?
Thanks,
Aaron
Re: [build] Dependency management
Posted by Siva <si...@sivasundaram.com>.
Did u try with by setting maven.mode.online=false?
Siva
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 16, 2003 8:50 PM
Subject: Re: [build] Dependency management
> On Sat, 16 Aug 2003, Jason Dillon wrote:
> > The problem with this approach is that all modules now have extra bits
> > on their class-path, which is not desired.
> >
> > Also, I have tried using SNAPSHOT for intra-project depends, but Maven
> > still tries to download newer versions from the remote repo which is
> > silly and just slows things down.
>
> AFAICT, it also prevents you from building if you're on a
> disconnected laptop. If there was a way to avoid all unnecessary
> downloads, or continue peacefully with the current version if the download
> server is not available, it would be great.
>
> Aaron
>
[PATCH][activation] placeholders for missing classes
Posted by Maas van den Berg <em...@dds.nl>.
- Added missing methods to DataHolder
- Added placeholders for missing classes
- Cleanroom, Copyright ASF assignable, etc
Maas
Re: [build] Dependency management
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Thanks all!
Aaron
On Sat, 16 Aug 2003, Daniel S. Haischt wrote:
> from the maven user guide:
>
> -------8<------------8<-------8<-----------8<-------
> If you find you need to build your projects offline
> you can either use the offline switch on the CLI:
>
> maven -o jar:jar
>
> Or you can set maven.mode.online to false in a
> property file .
>
> maven.repo.remote.enabled=false
> ------->8------------>8------->8----------->8-------
>
> see -> http://maven.apache.org/reference/user-guide.html
On Sat, 16 Aug 2003, Alan Cabrera wrote:
> Project.properties file in the root directory.
On Sat, 16 Aug 2003, Siva wrote:
> I keep a build.properties inside incubator-geronimo which specifies this
> property.
>
> When i go online using my slowwwww dialup connection,i set it to
> true,rest of the time false :)
Re: [build] Dependency management
Posted by "Daniel S. Haischt" <me...@daniel.stefan.haischt.name>.
from the maven user guide:
-------8<------------8<-------8<-----------8<-------
If you find you need to build your projects offline
you can either use the offline switch on the CLI:
maven -o jar:jar
Or you can set maven.mode.online to false in a
property file .
maven.repo.remote.enabled=false
------->8------------>8------->8----------->8-------
see -> http://maven.apache.org/reference/user-guide.html
regards
daniel s. haischt
--
Aaron Mulder wrote:
> On Sat, 16 Aug 2003, Jason Dillon wrote:
>
>>The problem with this approach is that all modules now have extra bits
>>on their class-path, which is not desired.
>>
>>Also, I have tried using SNAPSHOT for intra-project depends, but Maven
>>still tries to download newer versions from the remote repo which is
>>silly and just slows things down.
>
>
> AFAICT, it also prevents you from building if you're on a
> disconnected laptop. If there was a way to avoid all unnecessary
> downloads, or continue peacefully with the current version if the download
> server is not available, it would be great.
>
> Aaron
>
Re: [build] Dependency management
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Sat, 16 Aug 2003, Jason Dillon wrote:
> The problem with this approach is that all modules now have extra bits
> on their class-path, which is not desired.
>
> Also, I have tried using SNAPSHOT for intra-project depends, but Maven
> still tries to download newer versions from the remote repo which is
> silly and just slows things down.
AFAICT, it also prevents you from building if you're on a
disconnected laptop. If there was a way to avoid all unnecessary
downloads, or continue peacefully with the current version if the download
server is not available, it would be great.
Aaron
Re: [build] Dependency management
Posted by Jason Dillon <ja...@coredevelopers.net>.
> Write a base project.xml containing the common deps (like
> commons-logging) and
> other common info, write a base maven.xml that fires up a reactor that
> calls the
> 'jar:install-snapshot' goal, and life will be much easier already.
> Declare all
> intra-project dependencies as SNAPSHOT to make sure you always get the
> latest
> generated jar.
The problem with this approach is that all modules now have extra bits
on their class-path, which is not desired.
Also, I have tried using SNAPSHOT for intra-project depends, but Maven
still tries to download newer versions from the remote repo which is
silly and just slows things down.
--jason
Re: [build] Dependency management
Posted by Leo Simons <le...@apache.org>.
Jason Dillon wrote:
> Comments? Suggestions?
combining project.xml and maven.xml (maven.xml is your jelly script)
inheritance
with SNAPSHOT dependencies and the 'jar:install-snapshot' goal works
wonders.
Write a base project.xml containing the common deps (like
commons-logging) and
other common info, write a base maven.xml that fires up a reactor that
calls the
'jar:install-snapshot' goal, and life will be much easier already.
Declare all
intra-project dependencies as SNAPSHOT to make sure you always get the
latest
generated jar.
You can see a setup like this in action in the avalon-components cvs
module and
inside avalon-sandbox/merlin as well. I'm sure Steve (who set that up)
borrowed
ideas from other projects that work like this :D
hope that helps,
- Leo Simons