You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Brill Pappin <br...@stabilia.com> on 2004/05/10 17:01:08 UTC
Dependancies without repositories. Was: Re: Dependencies
Aside: For any Maven developers paying attention here... this is
something that needs some special attention as its messy as hell and is
a (very) common problem.
What I would suggest is a standard dir in the project itself (like src
or target) which is the projects "private" repository... this dir would
have the same structure as the public repository and be included
automatically in dependency checks if it exists. Such a modification
would solve this problem once and for all. umm... don't forget to
document it...
============================
Now back to our regularly scheduled reply:
Ahh, you mean for dependencies that are not included on ibiblio (or some
other repository)...
I do a special setup for that stuff.
create dir src/libs
add the jars to that dir, and include a version.
add the dependency as normal to the project.xml file.
add a line in the project.properties for the override.
add a goal in the maven.xml that adds the jar to your local repository
from the src/libs dir.
I usually have to do this with Sun libs that can't be normally
distributed, but I've also done it with libs that have no repository
location.
Example:
The following example ensures that the javamail api which has no
repository can be found by the project.
Unfortunately not all plugins respect the jar override properties so the
goal has to be included to copy the jar into the proper repository
location. Note that this is a lot of extra work to add your libs, bit I
find its worth the effort to have a clean dependency list and a "compile
anywhere" source tree.
FYI: I've used a couple of things that might not be obvious to someone
new to Maven, such as the preGoal which in this case will execute before
the java:compile goal does. You can specify a preGoal for any goal.
in project.xml
--------------------------------
<dependency>
<groupId>java</groupId>
<artifactId>javamail</artifactId>
<version>1.3.1</version>
<type>jar</type>
<properties>
<war.bundle>true</war.bundle>
</properties>
</dependency>
in project.properties
--------------------------------*
maven.jar.override=on
maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
*
in maven.xml
--------------------------------
<preGoal name="java:compile">
<attainGoal name="copy-private-jars" />
</preGoal>
<goal name="copy-private-jars">
<mkdir dir="${maven.repo.local}/java/jars" />
<copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
toDir="${maven.repo.local}/java/jars"/>
</goal>
- Brill Pappin
Bill Madison wrote:
>Thanks Matt,
>
>Isnt there a lib or something where I can point to,
>instead of putting each and every jar as a dpendency,
>thats a lot of cut and paste work and also most of the
>thirdparty jars dont come with a version and as I see
>the version is a requiredd element. Theres got to be a
>better and easier way of doing this.
>
>The problem in my case is that we have 2 development
>teams, and they put their jars in the IDE build path
>and when it comes to integration/build I have to start
>figuring out the version for each jar and start
>putting them in the project.xml which is kind of
>cumbersome. So trying to see if there is a better way
>f doing this. Please let me know if you have a
>solution for this.
>
>Thanks
>
>--- "matthew.hawthorne" <ma...@apache.org> wrote:
>
>
>>Bill Madison wrote:
>>
>>
>>>I am a newbie to Maven. And my question is, if my
>>>project needs some 30 thirdparty jars, for each of
>>>them do I need to put a <dependency> element in
>>>
>>>
>>the
>>
>>
>>>project.xml? Please let me know.
>>>
>>>
>>Yes.
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail:
>>users-unsubscribe@maven.apache.org
>>For additional commands, e-mail:
>>users-help@maven.apache.org
>>
>>
>>
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Photos: High-quality 4x6 digital prints for 25¢
>http://photos.yahoo.com/ph/print_splash
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependancies without repositories. Was: Re: Dependencies
Posted by "J. Matthew Pryor" <jm...@yahoo.com>.
Snooping recently in the pico/nano codebase I saw a line like the following
maven.repo.remote = http://www.ibiblio.org/maven, http://dist.codehaus.org,
file:${basedir}/lib
I didn't try it yet myself but is that valid?
Matthew
> -----Original Message-----
> From: Brill Pappin [mailto:brill@stabilia.com]
> Sent: Tuesday, May 11, 2004 1:01 AM
> To: Maven Users List
> Subject: Dependancies without repositories. Was: Re: Dependencies
>
> Aside: For any Maven developers paying attention here... this
> is something that needs some special attention as its messy
> as hell and is a (very) common problem.
>
> What I would suggest is a standard dir in the project itself
> (like src or target) which is the projects "private"
> repository... this dir would have the same structure as the
> public repository and be included automatically in dependency
> checks if it exists. Such a modification would solve this
> problem once and for all. umm... don't forget to document it...
>
> ============================
> Now back to our regularly scheduled reply:
>
> Ahh, you mean for dependencies that are not included on
> ibiblio (or some other repository)...
>
> I do a special setup for that stuff.
>
> create dir src/libs
> add the jars to that dir, and include a version.
> add the dependency as normal to the project.xml file.
> add a line in the project.properties for the override.
> add a goal in the maven.xml that adds the jar to your local
> repository from the src/libs dir.
>
>
> I usually have to do this with Sun libs that can't be normally
> distributed, but I've also done it with libs that have no repository
> location.
>
> Example:
>
> The following example ensures that the javamail api which has no
> repository can be found by the project.
> Unfortunately not all plugins respect the jar override
> properties so the
> goal has to be included to copy the jar into the proper repository
> location. Note that this is a lot of extra work to add your
> libs, bit I
> find its worth the effort to have a clean dependency list and
> a "compile
> anywhere" source tree.
> FYI: I've used a couple of things that might not be obvious
> to someone
> new to Maven, such as the preGoal which in this case will
> execute before
> the java:compile goal does. You can specify a preGoal for any goal.
>
> in project.xml
> --------------------------------
> <dependency>
> <groupId>java</groupId>
> <artifactId>javamail</artifactId>
> <version>1.3.1</version>
> <type>jar</type>
> <properties>
> <war.bundle>true</war.bundle>
> </properties>
> </dependency>
>
> in project.properties
> --------------------------------*
> maven.jar.override=on
> maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
> *
> in maven.xml
> --------------------------------
> <preGoal name="java:compile">
> <attainGoal name="copy-private-jars" />
> </preGoal>
>
> <goal name="copy-private-jars">
> <mkdir dir="${maven.repo.local}/java/jars" />
> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
> toDir="${maven.repo.local}/java/jars"/>
> </goal>
>
>
> - Brill Pappin
>
>
> Bill Madison wrote:
>
> >Thanks Matt,
> >
> >Isnt there a lib or something where I can point to,
> >instead of putting each and every jar as a dpendency,
> >thats a lot of cut and paste work and also most of the
> >thirdparty jars dont come with a version and as I see
> >the version is a requiredd element. Theres got to be a
> >better and easier way of doing this.
> >
> >The problem in my case is that we have 2 development
> >teams, and they put their jars in the IDE build path
> >and when it comes to integration/build I have to start
> >figuring out the version for each jar and start
> >putting them in the project.xml which is kind of
> >cumbersome. So trying to see if there is a better way
> >f doing this. Please let me know if you have a
> >solution for this.
> >
> >Thanks
> >
> >--- "matthew.hawthorne" <ma...@apache.org> wrote:
> >
> >
> >>Bill Madison wrote:
> >>
> >>
> >>>I am a newbie to Maven. And my question is, if my
> >>>project needs some 30 thirdparty jars, for each of
> >>>them do I need to put a <dependency> element in
> >>>
> >>>
> >>the
> >>
> >>
> >>>project.xml? Please let me know.
> >>>
> >>>
> >>Yes.
> >>
> >>
> >>
> >>
> >---------------------------------------------------------------------
> >
> >
> >>To unsubscribe, e-mail:
> >>users-unsubscribe@maven.apache.org
> >>For additional commands, e-mail:
> >>users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! Photos: High-quality 4x6 digital prints for 25¢
> >http://photos.yahoo.com/ph/print_splash
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependancies without repositories. Was: Re: Dependencies
Posted by Chuck Daniels <cj...@yahoo.com>.
Brill,
That brings up an interesting point. What you have done with your maven.xml
to handle dependencies indicates that maven.xml is executed prior to the
check for the existence of the dependencies listed in project.xml. Is this
true?
Cheers,
Chuck
> -----Original Message-----
> From: Brill Pappin [mailto:brill@stabilia.com]
> Sent: Tuesday, June 01, 2004 1:54 PM
> To: Maven Users List
> Subject: Re: Dependancies without repositories. Was: Re: Dependencies
>
>
> Actually I always do that, however the properties are not respected by
> all other plugins.
> I've found that more is required (see maven.xml in old reply below)...
> it's a little cumbersome, but works like a charm once set up.
>
> - Brill Pappin
>
> Dion Gillard wrote:
>
> >Why not just use jar overrides in the project.properties and point all
> >the overrides at ${basedir}/lib?
> >
> >[...]
> >
> >>>>Example:
> >>>>
> >>>>The following example ensures that the javamail api which has no
> >>>>repository can be found by the project.
> >>>>Unfortunately not all plugins respect the jar override
> properties so the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>>goal has to be included to copy the jar into the proper repository
> >>>>location. Note that this is a lot of extra work to add your
> libs, bit I
> >>>>find its worth the effort to have a clean dependency list and
> a "compile
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>anywhere" source tree.
> >>>>FYI: I've used a couple of things that might not be obvious to someone
> >>>>new to Maven, such as the preGoal which in this case will
> execute before
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>the java:compile goal does. You can specify a preGoal for any goal.
> >>>>
> >>>>in project.xml
> >>>>--------------------------------
> >>>><dependency>
> >>>> <groupId>java</groupId>
> >>>> <artifactId>javamail</artifactId>
> >>>> <version>1.3.1</version>
> >>>> <type>jar</type>
> >>>> <properties>
> >>>> <war.bundle>true</war.bundle>
> >>>> </properties>
> >>>></dependency>
> >>>>
> >>>>in project.properties
> >>>>--------------------------------*
> >>>>maven.jar.override=on
> >>>>maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
> >>>>*
> >>>>in maven.xml
> >>>>--------------------------------
> >>>><preGoal name="java:compile">
> >>>> <attainGoal name="copy-private-jars" />
> >>>></preGoal>
> >>>>
> >>>><goal name="copy-private-jars">
> >>>> <mkdir dir="${maven.repo.local}/java/jars" />
> >>>> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
> >>>>toDir="${maven.repo.local}/java/jars"/>
> >>>></goal>
> >>>>
> >>>>
> >>>>- Brill Pappin
> >>>>
> >>>>
> >>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by Brill Pappin <br...@stabilia.com>.
Actually I always do that, however the properties are not respected by
all other plugins.
I've found that more is required (see maven.xml in old reply below)...
it's a little cumbersome, but works like a charm once set up.
- Brill Pappin
Dion Gillard wrote:
>Why not just use jar overrides in the project.properties and point all
>the overrides at ${basedir}/lib?
>
>[...]
>
>>>>Example:
>>>>
>>>>The following example ensures that the javamail api which has no
>>>>repository can be found by the project.
>>>>Unfortunately not all plugins respect the jar override properties so the
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>>goal has to be included to copy the jar into the proper repository
>>>>location. Note that this is a lot of extra work to add your libs, bit I
>>>>find its worth the effort to have a clean dependency list and a "compile
>>>>
>>>>
>>>>
>>>>
>>>>anywhere" source tree.
>>>>FYI: I've used a couple of things that might not be obvious to someone
>>>>new to Maven, such as the preGoal which in this case will execute before
>>>>
>>>>
>>>>
>>>>
>>>>the java:compile goal does. You can specify a preGoal for any goal.
>>>>
>>>>in project.xml
>>>>--------------------------------
>>>><dependency>
>>>> <groupId>java</groupId>
>>>> <artifactId>javamail</artifactId>
>>>> <version>1.3.1</version>
>>>> <type>jar</type>
>>>> <properties>
>>>> <war.bundle>true</war.bundle>
>>>> </properties>
>>>></dependency>
>>>>
>>>>in project.properties
>>>>--------------------------------*
>>>>maven.jar.override=on
>>>>maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
>>>>*
>>>>in maven.xml
>>>>--------------------------------
>>>><preGoal name="java:compile">
>>>> <attainGoal name="copy-private-jars" />
>>>></preGoal>
>>>>
>>>><goal name="copy-private-jars">
>>>> <mkdir dir="${maven.repo.local}/java/jars" />
>>>> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
>>>>toDir="${maven.repo.local}/java/jars"/>
>>>></goal>
>>>>
>>>>
>>>>- Brill Pappin
>>>>
>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by Dion Gillard <di...@gmail.com>.
Why not just use jar overrides in the project.properties and point all
the overrides at ${basedir}/lib?
On Tue, 01 Jun 2004 08:47:07 -0400, Brill Pappin <br...@stabilia.com> wrote:
>
> Using a localized remote repo is *not* an option for us here. I'm
> fighting other parts of the team to use maven as it is, and having a
> dependency on a remote machine that is a point-of-failure is not an option.
>
> Other problems include security when a project must be built off-site by
> a developer working from home, or a contractor... no access; the
> repository must not be exposed (we did for a while, and promptly got
> hacked).
>
> The only option that will be satisfactory to the dinosaurs here is that
> any library not in the public repository goes with the project.... and
> no, I don't like it but thats what I have to work with :)
>
> It might help if Maven was better at using secure protocols, but I've
> had nothing but pain setting that up!
>
> The key is that it must not have too much in the way of "special" setup
> on a particular box or it simply will not be used.
>
> - Brill Pappin
>
> dion_gillard@multitask.com.au wrote:
>
> >We just use a corporate repo for things like javamail, jms and commercial
> >stuff.
> >--
> >dIon Gillard, Multitask Consulting
> >
> >
> >
> >Brill Pappin <br...@stabilia.com> wrote on 11/05/2004 01:01:08 AM:
> >
> >
> >
> >>Aside: For any Maven developers paying attention here... this is
> >>something that needs some special attention as its messy as hell and is
> >>a (very) common problem.
> >>
> >>What I would suggest is a standard dir in the project itself (like src
> >>or target) which is the projects "private" repository... this dir would
> >>have the same structure as the public repository and be included
> >>automatically in dependency checks if it exists. Such a modification
> >>would solve this problem once and for all. umm... don't forget to
> >>document it...
> >>
> >>============================
> >>Now back to our regularly scheduled reply:
> >>
> >>Ahh, you mean for dependencies that are not included on ibiblio (or some
> >>
> >>
> >
> >
> >
> >>other repository)...
> >>
> >>I do a special setup for that stuff.
> >>
> >>create dir src/libs
> >>add the jars to that dir, and include a version.
> >>add the dependency as normal to the project.xml file.
> >>add a line in the project.properties for the override.
> >>add a goal in the maven.xml that adds the jar to your local repository
> >>from the src/libs dir.
> >>
> >>
> >>I usually have to do this with Sun libs that can't be normally
> >>distributed, but I've also done it with libs that have no repository
> >>location.
> >>
> >>Example:
> >>
> >>The following example ensures that the javamail api which has no
> >>repository can be found by the project.
> >>Unfortunately not all plugins respect the jar override properties so the
> >>
> >>
> >
> >
> >
> >>goal has to be included to copy the jar into the proper repository
> >>location. Note that this is a lot of extra work to add your libs, bit I
> >>find its worth the effort to have a clean dependency list and a "compile
> >>
> >>
> >
> >
> >
> >>anywhere" source tree.
> >>FYI: I've used a couple of things that might not be obvious to someone
> >>new to Maven, such as the preGoal which in this case will execute before
> >>
> >>
> >
> >
> >
> >>the java:compile goal does. You can specify a preGoal for any goal.
> >>
> >>in project.xml
> >>--------------------------------
> >><dependency>
> >> <groupId>java</groupId>
> >> <artifactId>javamail</artifactId>
> >> <version>1.3.1</version>
> >> <type>jar</type>
> >> <properties>
> >> <war.bundle>true</war.bundle>
> >> </properties>
> >></dependency>
> >>
> >>in project.properties
> >>--------------------------------*
> >>maven.jar.override=on
> >>maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
> >>*
> >>in maven.xml
> >>--------------------------------
> >><preGoal name="java:compile">
> >> <attainGoal name="copy-private-jars" />
> >></preGoal>
> >>
> >><goal name="copy-private-jars">
> >> <mkdir dir="${maven.repo.local}/java/jars" />
> >> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
> >>toDir="${maven.repo.local}/java/jars"/>
> >></goal>
> >>
> >>
> >>- Brill Pappin
> >>
> >>
> >>Bill Madison wrote:
> >>
> >>
> >>
> >>>Thanks Matt,
> >>>
> >>>Isnt there a lib or something where I can point to,
> >>>instead of putting each and every jar as a dpendency,
> >>>thats a lot of cut and paste work and also most of the
> >>>thirdparty jars dont come with a version and as I see
> >>>the version is a requiredd element. Theres got to be a
> >>>better and easier way of doing this.
> >>>
> >>>The problem in my case is that we have 2 development
> >>>teams, and they put their jars in the IDE build path
> >>>and when it comes to integration/build I have to start
> >>>figuring out the version for each jar and start
> >>>putting them in the project.xml which is kind of
> >>>cumbersome. So trying to see if there is a better way
> >>>f doing this. Please let me know if you have a
> >>>solution for this.
> >>>
> >>>Thanks
> >>>
> >>>--- "matthew.hawthorne" <ma...@apache.org> wrote:
> >>>
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by Brill Pappin <br...@stabilia.com>.
Michal Maczka wrote:
> Brill Pappin wrote:
>
>> Using a localized remote repo is *not* an option for us here. I'm
>> fighting other parts of the team to use maven as it is, and having a
>> dependency on a remote machine that is a point-of-failure is not an
>> option.
>>
>> Other problems include security when a project must be built off-site
>> by a developer working from home, or a contractor... no access; the
>> repository must not be exposed (we did for a while, and promptly got
>> hacked).
>>
>
> You mean the situation when devloper is not able to connect to your
> servers from home?
> How can he/she use things like CVS then? And then how sources of the
> project will appear on his disk?
> You can use the same channel for transfering required artifacts into
> your local repository.
>
Yes, that is a good example, and we have more levels of security here
than simply ssh, including rotating tokens which Maven *can't* know about.
Also "automatic" is a dirty word around here and no "automatic" cvs
access is permitted in any build or deployment script.
>> The only option that will be satisfactory to the dinosaurs here is
>> that any library not in the public repository goes with the
>> project.... and no, I don't like it but thats what I have to work
>> with :)
>>
>
> This already is supported. If you really have to you can just put
> your jars to CVS and make a checkout from there.
> Then you have to define remote repository which is
> using file:// protocol. You can even checkout such liblaries
> directly into your local repository. In other case maven
> willl just copy them to local repository.
That might be a possible solution, although the goal was to be able to
bundle up a snapshot, send it out to a contractor and get it back all
without anyone having to change the build script or have access to our
private codebase.
- Brill Pappin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by Michal Maczka <mm...@interia.pl>.
Brill Pappin wrote:
> Using a localized remote repo is *not* an option for us here. I'm
> fighting other parts of the team to use maven as it is, and having a
> dependency on a remote machine that is a point-of-failure is not an
> option.
>
> Other problems include security when a project must be built off-site
> by a developer working from home, or a contractor... no access; the
> repository must not be exposed (we did for a while, and promptly got
> hacked).
>
You mean the situation when devloper is not able to connect to your
servers from home?
How can he/she use things like CVS then? And then how sources of the
project will appear on his disk?
You can use the same channel for transfering required artifacts into
your local repository.
> The only option that will be satisfactory to the dinosaurs here is
> that any library not in the public repository goes with the
> project.... and no, I don't like it but thats what I have to work with :)
>
This already is supported. If you really have to you can just put your
jars to CVS and make a checkout from there.
Then you have to define remote repository which is
using file:// protocol. You can even checkout such liblaries directly
into your local repository. In other case maven
willl just copy them to local repository.
> It might help if Maven was better at using secure protocols, but I've
> had nothing but pain setting that up!
>
It is planned. Support for ssh and https is already implemented and
will be enabled shorty after maven 1.0 is released
> The key is that it must not have too much in the way of "special"
> setup on a particular box or it simply will not be us
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by Brill Pappin <br...@stabilia.com>.
Using a localized remote repo is *not* an option for us here. I'm
fighting other parts of the team to use maven as it is, and having a
dependency on a remote machine that is a point-of-failure is not an option.
Other problems include security when a project must be built off-site by
a developer working from home, or a contractor... no access; the
repository must not be exposed (we did for a while, and promptly got
hacked).
The only option that will be satisfactory to the dinosaurs here is that
any library not in the public repository goes with the project.... and
no, I don't like it but thats what I have to work with :)
It might help if Maven was better at using secure protocols, but I've
had nothing but pain setting that up!
The key is that it must not have too much in the way of "special" setup
on a particular box or it simply will not be used.
- Brill Pappin
dion_gillard@multitask.com.au wrote:
>We just use a corporate repo for things like javamail, jms and commercial
>stuff.
>--
>dIon Gillard, Multitask Consulting
>
>
>
>Brill Pappin <br...@stabilia.com> wrote on 11/05/2004 01:01:08 AM:
>
>
>
>>Aside: For any Maven developers paying attention here... this is
>>something that needs some special attention as its messy as hell and is
>>a (very) common problem.
>>
>>What I would suggest is a standard dir in the project itself (like src
>>or target) which is the projects "private" repository... this dir would
>>have the same structure as the public repository and be included
>>automatically in dependency checks if it exists. Such a modification
>>would solve this problem once and for all. umm... don't forget to
>>document it...
>>
>>============================
>>Now back to our regularly scheduled reply:
>>
>>Ahh, you mean for dependencies that are not included on ibiblio (or some
>>
>>
>
>
>
>>other repository)...
>>
>>I do a special setup for that stuff.
>>
>>create dir src/libs
>>add the jars to that dir, and include a version.
>>add the dependency as normal to the project.xml file.
>>add a line in the project.properties for the override.
>>add a goal in the maven.xml that adds the jar to your local repository
>>from the src/libs dir.
>>
>>
>>I usually have to do this with Sun libs that can't be normally
>>distributed, but I've also done it with libs that have no repository
>>location.
>>
>>Example:
>>
>>The following example ensures that the javamail api which has no
>>repository can be found by the project.
>>Unfortunately not all plugins respect the jar override properties so the
>>
>>
>
>
>
>>goal has to be included to copy the jar into the proper repository
>>location. Note that this is a lot of extra work to add your libs, bit I
>>find its worth the effort to have a clean dependency list and a "compile
>>
>>
>
>
>
>>anywhere" source tree.
>>FYI: I've used a couple of things that might not be obvious to someone
>>new to Maven, such as the preGoal which in this case will execute before
>>
>>
>
>
>
>>the java:compile goal does. You can specify a preGoal for any goal.
>>
>>in project.xml
>>--------------------------------
>><dependency>
>> <groupId>java</groupId>
>> <artifactId>javamail</artifactId>
>> <version>1.3.1</version>
>> <type>jar</type>
>> <properties>
>> <war.bundle>true</war.bundle>
>> </properties>
>></dependency>
>>
>>in project.properties
>>--------------------------------*
>>maven.jar.override=on
>>maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
>>*
>>in maven.xml
>>--------------------------------
>><preGoal name="java:compile">
>> <attainGoal name="copy-private-jars" />
>></preGoal>
>>
>><goal name="copy-private-jars">
>> <mkdir dir="${maven.repo.local}/java/jars" />
>> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
>>toDir="${maven.repo.local}/java/jars"/>
>></goal>
>>
>>
>>- Brill Pappin
>>
>>
>>Bill Madison wrote:
>>
>>
>>
>>>Thanks Matt,
>>>
>>>Isnt there a lib or something where I can point to,
>>>instead of putting each and every jar as a dpendency,
>>>thats a lot of cut and paste work and also most of the
>>>thirdparty jars dont come with a version and as I see
>>>the version is a requiredd element. Theres got to be a
>>>better and easier way of doing this.
>>>
>>>The problem in my case is that we have 2 development
>>>teams, and they put their jars in the IDE build path
>>>and when it comes to integration/build I have to start
>>>figuring out the version for each jar and start
>>>putting them in the project.xml which is kind of
>>>cumbersome. So trying to see if there is a better way
>>>f doing this. Please let me know if you have a
>>>solution for this.
>>>
>>>Thanks
>>>
>>>--- "matthew.hawthorne" <ma...@apache.org> wrote:
>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependancies without repositories. Was: Re: Dependencies
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
I've also set up my own repository to share libraries not available in
ibiblio, in order not to add them to CVS or to the source distribution.
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
> -----Mensaje original-----
> De: dion_gillard@multitask.com.au
> [mailto:dion_gillard@multitask.com.au]
> Enviado el: martes, 11 de mayo de 2004 2:49
> Para: Maven Users List
> Asunto: Re: Dependancies without repositories. Was: Re: Dependencies
>
> We just use a corporate repo for things like javamail, jms
> and commercial stuff.
> --
> dIon Gillard, Multitask Consulting
>
>
>
> Brill Pappin <br...@stabilia.com> wrote on 11/05/2004 01:01:08 AM:
>
> > Aside: For any Maven developers paying attention here... this is
> > something that needs some special attention as its messy as
> hell and is
> > a (very) common problem.
> >
> > What I would suggest is a standard dir in the project
> itself (like src
> > or target) which is the projects "private" repository...
> this dir would
> > have the same structure as the public repository and be included
> > automatically in dependency checks if it exists. Such a
> modification
> > would solve this problem once and for all. umm... don't forget to
> > document it...
> >
> > ============================
> > Now back to our regularly scheduled reply:
> >
> > Ahh, you mean for dependencies that are not included on
> ibiblio (or some
>
> > other repository)...
> >
> > I do a special setup for that stuff.
> >
> > create dir src/libs
> > add the jars to that dir, and include a version.
> > add the dependency as normal to the project.xml file.
> > add a line in the project.properties for the override.
> > add a goal in the maven.xml that adds the jar to your local
> repository
> > from the src/libs dir.
> >
> >
> > I usually have to do this with Sun libs that can't be normally
> > distributed, but I've also done it with libs that have no
> repository
> > location.
> >
> > Example:
> >
> > The following example ensures that the javamail api which has no
> > repository can be found by the project.
> > Unfortunately not all plugins respect the jar override
> properties so the
>
> > goal has to be included to copy the jar into the proper repository
> > location. Note that this is a lot of extra work to add your
> libs, bit I
> > find its worth the effort to have a clean dependency list
> and a "compile
>
> > anywhere" source tree.
> > FYI: I've used a couple of things that might not be obvious
> to someone
> > new to Maven, such as the preGoal which in this case will
> execute before
>
> > the java:compile goal does. You can specify a preGoal for any goal.
> >
> > in project.xml
> > --------------------------------
> > <dependency>
> > <groupId>java</groupId>
> > <artifactId>javamail</artifactId>
> > <version>1.3.1</version>
> > <type>jar</type>
> > <properties>
> > <war.bundle>true</war.bundle>
> > </properties>
> > </dependency>
> >
> > in project.properties
> > --------------------------------*
> > maven.jar.override=on
> > maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
> > *
> > in maven.xml
> > --------------------------------
> > <preGoal name="java:compile">
> > <attainGoal name="copy-private-jars" />
> > </preGoal>
> >
> > <goal name="copy-private-jars">
> > <mkdir dir="${maven.repo.local}/java/jars" />
> > <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
> > toDir="${maven.repo.local}/java/jars"/>
> > </goal>
> >
> >
> > - Brill Pappin
> >
> >
> > Bill Madison wrote:
> >
> > >Thanks Matt,
> > >
> > >Isnt there a lib or something where I can point to,
> > >instead of putting each and every jar as a dpendency,
> > >thats a lot of cut and paste work and also most of the
> > >thirdparty jars dont come with a version and as I see
> > >the version is a requiredd element. Theres got to be a
> > >better and easier way of doing this.
> > >
> > >The problem in my case is that we have 2 development
> > >teams, and they put their jars in the IDE build path
> > >and when it comes to integration/build I have to start
> > >figuring out the version for each jar and start
> > >putting them in the project.xml which is kind of
> > >cumbersome. So trying to see if there is a better way
> > >f doing this. Please let me know if you have a
> > >solution for this.
> > >
> > >Thanks
> > >
> > >--- "matthew.hawthorne" <ma...@apache.org> wrote:
> > >
> > >
> > >>Bill Madison wrote:
> > >>
> > >>
> > >>>I am a newbie to Maven. And my question is, if my
> > >>>project needs some 30 thirdparty jars, for each of
> > >>>them do I need to put a <dependency> element in
> > >>>
> > >>>
> > >>the
> > >>
> > >>
> > >>>project.xml? Please let me know.
> > >>>
> > >>>
> > >>Yes.
> > >>
> > >>
> > >>
> > >>
> >
> >---------------------------------------------------------------------
> > >
> > >
> > >>To unsubscribe, e-mail:
> > >>users-unsubscribe@maven.apache.org
> > >>For additional commands, e-mail:
> > >>users-help@maven.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >__________________________________
> > >Do you Yahoo!?
> > >Yahoo! Photos: High-quality 4x6 digital prints for 25¢
> > >http://photos.yahoo.com/ph/print_splash
> > >
> >
> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependancies without repositories. Was: Re: Dependencies
Posted by di...@multitask.com.au.
We just use a corporate repo for things like javamail, jms and commercial
stuff.
--
dIon Gillard, Multitask Consulting
Brill Pappin <br...@stabilia.com> wrote on 11/05/2004 01:01:08 AM:
> Aside: For any Maven developers paying attention here... this is
> something that needs some special attention as its messy as hell and is
> a (very) common problem.
>
> What I would suggest is a standard dir in the project itself (like src
> or target) which is the projects "private" repository... this dir would
> have the same structure as the public repository and be included
> automatically in dependency checks if it exists. Such a modification
> would solve this problem once and for all. umm... don't forget to
> document it...
>
> ============================
> Now back to our regularly scheduled reply:
>
> Ahh, you mean for dependencies that are not included on ibiblio (or some
> other repository)...
>
> I do a special setup for that stuff.
>
> create dir src/libs
> add the jars to that dir, and include a version.
> add the dependency as normal to the project.xml file.
> add a line in the project.properties for the override.
> add a goal in the maven.xml that adds the jar to your local repository
> from the src/libs dir.
>
>
> I usually have to do this with Sun libs that can't be normally
> distributed, but I've also done it with libs that have no repository
> location.
>
> Example:
>
> The following example ensures that the javamail api which has no
> repository can be found by the project.
> Unfortunately not all plugins respect the jar override properties so the
> goal has to be included to copy the jar into the proper repository
> location. Note that this is a lot of extra work to add your libs, bit I
> find its worth the effort to have a clean dependency list and a "compile
> anywhere" source tree.
> FYI: I've used a couple of things that might not be obvious to someone
> new to Maven, such as the preGoal which in this case will execute before
> the java:compile goal does. You can specify a preGoal for any goal.
>
> in project.xml
> --------------------------------
> <dependency>
> <groupId>java</groupId>
> <artifactId>javamail</artifactId>
> <version>1.3.1</version>
> <type>jar</type>
> <properties>
> <war.bundle>true</war.bundle>
> </properties>
> </dependency>
>
> in project.properties
> --------------------------------*
> maven.jar.override=on
> maven.jar.javamail=${basedir}/src/libs/javamail-1.3.1.jar
> *
> in maven.xml
> --------------------------------
> <preGoal name="java:compile">
> <attainGoal name="copy-private-jars" />
> </preGoal>
>
> <goal name="copy-private-jars">
> <mkdir dir="${maven.repo.local}/java/jars" />
> <copy file="${maven.src.dir}/libs/javamail-1.3.1.jar"
> toDir="${maven.repo.local}/java/jars"/>
> </goal>
>
>
> - Brill Pappin
>
>
> Bill Madison wrote:
>
> >Thanks Matt,
> >
> >Isnt there a lib or something where I can point to,
> >instead of putting each and every jar as a dpendency,
> >thats a lot of cut and paste work and also most of the
> >thirdparty jars dont come with a version and as I see
> >the version is a requiredd element. Theres got to be a
> >better and easier way of doing this.
> >
> >The problem in my case is that we have 2 development
> >teams, and they put their jars in the IDE build path
> >and when it comes to integration/build I have to start
> >figuring out the version for each jar and start
> >putting them in the project.xml which is kind of
> >cumbersome. So trying to see if there is a better way
> >f doing this. Please let me know if you have a
> >solution for this.
> >
> >Thanks
> >
> >--- "matthew.hawthorne" <ma...@apache.org> wrote:
> >
> >
> >>Bill Madison wrote:
> >>
> >>
> >>>I am a newbie to Maven. And my question is, if my
> >>>project needs some 30 thirdparty jars, for each of
> >>>them do I need to put a <dependency> element in
> >>>
> >>>
> >>the
> >>
> >>
> >>>project.xml? Please let me know.
> >>>
> >>>
> >>Yes.
> >>
> >>
> >>
> >>
> >---------------------------------------------------------------------
> >
> >
> >>To unsubscribe, e-mail:
> >>users-unsubscribe@maven.apache.org
> >>For additional commands, e-mail:
> >>users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! Photos: High-quality 4x6 digital prints for 25¢
> >http://photos.yahoo.com/ph/print_splash
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org