Hello,

If you want to ensure that no other jar's get included in your
application withour going to the internal QA process I would suggest
installing a local repository manager  (Archiva or Artifactory). That
way you can configure the repository manager to never connect to a
central repository and have the internal QA process deploy approved 3rd
party jars in to local repository.
You don't really need a big big of jars for that.
Besides that: This way our internal application(s) do not have to depend
on one big bag of jars and all your internal modules can specify their
own dependencies. 

If you do want to use the bigbagofjars, then I would suggest to use the
solution being described bu Wayne Fay and Dirm Olmes, which can help
reduce the amount of work needed to configure your projects and can be
implemented along side the solution described above.


Every time the internal QA process approved a new 3rd party library they
can deploy it in the internal repository and release an new version of
the bigbarofjars, which has the new 3rd-party-library as a dependency.

Just my though... 

HTH.

With kind regards,
  Marco Beelen


 

-----Original Message-----
From: Brown, Carlton [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 26, 2008 5:19 PM
To: Maven Users List
Subject: RE: Best practice to represent an arbitrary collection of jars
as a single dependency?

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]

**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**********************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to