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 <[EMAIL PROTECTED]> 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
>
> [EMAIL PROTECTED] wrote:
>
> >We just use a corporate repo for things like javamail, jms and commercial
> >stuff.
> >--
> >dIon Gillard, Multitask Consulting
> >
> >
> >
> >Brill Pappin <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
