I had to resolve a similar issue when trying to compile RAD projects
with Maven. RAD comes with WebSphere runtime JARs in a specific
directory (which would be provided on the WebSphere server). By default,
RAD uses those runtime libraries without the need to specify the
dependency in the .classpath explicitly (RAD defines the concept of a
container for that purpose).
To be able to build the RAD project with Maven, I uploaded all of the
runtime JARs as artifacts in my repository, and created a
"dependency-only" pom project that has all those dependencies.
Then, to build the project with Maven, I simply have to add a dependency
on that pom project, and set it as provided scope to emulate in Maven
the RAD build environment.
Once the project compiles ok, running "mvn dependency:analyze" helps
trimming down those provided dependencies to only the ones that are
actually needed.
Uploading all jars from a directory to the repository is actually a very
easily scriptable task with a decent shell, if you are installing the
JARs with the same groupId and version for all of them.
For example (untested, but you get the idea):
for lib in *.jar; do
artifact=`basename $lib .jar`
mvn install:install-file \
-DgroupId=com.somecorp -Dversion=6.3.9 \
-DartifactId=$artifact \
-Dpackaging=jar -Dfile=$lib
echo "\<dependency\>
\<artifactId\>$artifact\</artifactId\>
\<groupId\>com.somecorp\</groupId\>
\<version\>6.3.9\</version\>
\</dependency\>" >> somecorp-meta.pom
done
Just edit somecorp-meta.pom after that to add header and footer and
install it with install:install-file also.
I hope this helps.
-Olivier
On Tue, 2008-02-26 at 12:41 -0600, Wayne Fay wrote:
> This simply is not a feature that currently exists in Maven, and for a
> lot of reasons, I don't see it being a feature that will be
> implemented any time soon.
>
> Your best bet is the "list all artifacts as dependencies in a pom, and
> depend on it" option that I suggested earlier. This in combination
> with Archiva, Artifactory, Proximity etc would be the "right" solution
> in my book.
>
> But, I don't think your projects actually need all 50 of those
> artifacts. So the best solution is to specify the proper dependencies
> explicitly in each project, and use a shared parent with a
> dependencyManagement section that helps you manage versions of
> artifacts.
>
> Wayne
>
> On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote:
> > I want to take a single directory of ~50 jars and specify that as a
> > single dependency.
> >
> > I'm explicitly trying to avoid specifying them as 50 separate
> > dependencies in a pom file, or breaking them out in 50 different module
> > subdirectories under an internal Archiva repository. It sounded to me
> > as if this is what you were suggesting, quite a bit of work.
> >
> > Perhaps I'm not wording the question correctly, as it seems like this
> > would be a very common situation.
> >
> > > -----Original Message-----
> > > From: Wayne Fay [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, February 26, 2008 11:49 AM
> > > To: Maven Users List
> > > Subject: Re: Best practice to represent an arbitrary collection of
> > jars as
> > > a single dependency?
> > >
> > > I guess we don't understand what you want/need, as it sounds a lot
> > > like what we're suggesting. You can manage the artifacts themselves by
> > > using Archiva etc rather than asking Maven to download direct from the
> > > Internet.
> > >
> > > An alternative is to unzip each jar into a shared directory and then
> > > re-jar all of it. But I don't know if that would actually work due to
> > > log4j.xml collisions etc.
> > >
> > > Wayne
> > >
> > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote:
> > > > These approaches both involve resolving each jar as an individual
> > > > separate dependency, a large amount of manual effort for a couple of
> > > > reasons. I'd have to specify 50 new dependencies in the POM, and
> > then
> > > > I'd have to stage these artifacts separately in our internal
> > repository.
> > > > This jar collection is certified by our internal QA process,
> > although
> > > > some of them are probably sitting out on Maven central, we're not
> > just
> > > > going to take whatever comes off a public repository without
> > certifying
> > > > it first.
> > > >
> > > > So basically what I'm needing to do is specify a single dependency
> > that
> > > > is composed of 50-something arbitrary jars. I was able to do this
> > in
> > > > Ivy, I figured Maven would likewise have a way to accomplish this
> > > > result.
> > > >
> > > > > -----Original Message-----
> > > > > From: Wayne Fay [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, February 26, 2008 10:27 AM
> > > > > To: Maven Users List
> > > > > Subject: Re: Best practice to represent an arbitrary collection of
> > > > jars as
> > > > > a single dependency?
> > > > >
> > > > > Just make a project with type pom and specify these dependencies.
> > > > > Then, depend on this project in your other projects, and it will
> > bring
> > > > > in those dependencies transitively.
> > > > >
> > > > > If you're certain about those versions, you can lock them down
> > with
> > > > > <version>[1.2.3]</version>.
> > > > >
> > > > > Wayne
> > > > >
> > > > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote:
> > > > > > Hi all, newb question here...
> > > > > >
> > > > > > Somewhere long ago, an internal dev project started depending on
> > > > > > foo-corp/lib/**/* of a 3rd-party framework, which ends up being
> > a
> > > > random
> > > > > > collection of 50 jars or so. What's the Maven best practice for
> > > > > > representing a "big bag o' jars" as a single dependency?
> > > > > >
> > > > > > I know it would be ideal to resolve our dependency graph with
> > > > greater
> > > > > > granularity, but until someone has copious free time to do that,
> > > > we'd
> > > > > > need a simple interim solution to move us forward on the Maven
> > > > track.
> > > > > >
> > > > > > Just to make it clear, the repository dir would look something
> > like:
> > > > > > /foo-corp/bigbagofjars/5.7/
> > > > > >
> > > > > > And it would contain a random selection of goodies such as:
> > > > > > apache-commons-codec_1.3.jar
> > > > > > apache-commons-discovery_1.1.jar
> > > > > > apache-commons-logging_1.1.jar
> > > > > > axis-jaxrpc_1.1.jar
> > > > > > axis-saaj_1.1.jar
> > > > > > axis-wsdl4j_1.1.jar
> > > > > > axis_1.1.jar
> > > > > > bsh_1.3.0.jar
> > > > > > jdom_b8.jar
> > > > > > junit_3.8.1.jar
> > > > > > ldapjdk_5.2.jar
> > > > > > log4j_1.2.8.jar
> > > > > > oracle_9.2.0.5.jar
> > > > > > xalan_2.6.0.jar
> > > > > > xerces-xml-apis_2.6.2.jar
> > > > > > xerces_2.6.2.jar
> > > > > > xpp3_min-1.1.3.4.I.jar
> > > > > > xstream-1.1.3.jar
> > > > > >
> > > > > > If I'm missing some obvious best practice, please feel free to
> > point
> > > > it
> > > > > > out, this is just the best I've been able to come up with so
> > far.
> > > > > >
> > > > > > Thanks in advance...
> > > > > >
> > > > > > -----------------------------------------
> > > > > > ====================================================
> > > > > > This message contains PRIVILEGED and CONFIDENTIAL
> > > > > > information that is intended only for use by the
> > > > > > named recipient. If you are not the named recipient,
> > > > > > any disclosure, dissemination, or action based on
> > > > > > the contents of this message is prohibited. In such
> > > > > > case please notify us and destroy and delete all
> > > > > > copies of this transmission. Thank you.
> > > > > > ====================================================
> > > > > >
> > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > 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]
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > 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]
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
