maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dion Gillard <dion.gill...@gmail.com>
Subject Re: Dependancies without repositories. Was: Re: Dependencies
Date Tue, 01 Jun 2004 13:45:24 GMT
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 <brill@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 <brill@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" <matth@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


Mime
View raw message