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/06/01 14:47:07 UTC
Re: Dependancies without repositories. Was: Re: Dependencies
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 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