You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Brown, Carlton" <Ca...@compucredit.com> on 2008/02/26 16:12:06 UTC
Best practice to represent an arbitrary collection of jars as a single dependency?
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by Wayne Fay <wa...@gmail.com>.
I'm honestly unsure as to which solution is "right" and "as above", it
just got confusing for me.
I believe version ranges in dependencyManagement is the "right"
solution in these cases. Also it is important that your developers
keep consistent APIs across say 1.2.x series and bump versions to
1.3.x or even 2.0.x when APIs change in small/large ways.
I am very happy to be proven wrong or be introduced to a better "best" practice.
Wayne
On 2/26/08, Michael McCallum <gh...@apache.org> wrote:
> On Wed, 27 Feb 2008 07:41:16 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.
> Is this the best bet or the one below?
>
> >
> > 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.
> do you really find that this helps? consider this very contrived but
> representative of more complex scenerios example P == parent, A == artifact,
> W == webapp or other assembly
>
> P2 :: A1
> P1 :: A2
> P2 :: A3
> P2 :: W1
>
> A2 -> A1
> A3 -> A2
>
> W1 -> A3, A2
>
> If P2 is has a "significant" change in verssion how do you know that you have
> an inconsistent build when you build W1? If you use the "right" solution -
> as above - then you can actually get the ability with version ranges to have
> maven error when trying to build W1 if A2 and A3 are inconsistence in their
> resolution tree and potentially class incompatible.
>
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> 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: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by Michael McCallum <gh...@apache.org>.
On Wed, 27 Feb 2008 07:41:16 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.
Is this the best bet or the one below?
>
> 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.
do you really find that this helps? consider this very contrived but
representative of more complex scenerios example P == parent, A == artifact,
W == webapp or other assembly
P2 :: A1
P1 :: A2
P2 :: A3
P2 :: W1
A2 -> A1
A3 -> A2
W1 -> A3, A2
If P2 is has a "significant" change in verssion how do you know that you have
an inconsistent build when you build W1? If you use the "right" solution -
as above - then you can actually get the ability with version ranges to have
maven error when trying to build W1 if A2 and A3 are inconsistence in their
resolution tree and potentially class incompatible.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Best practice to represent an arbitrary collection of jars asa
single dependency?
Posted by Olivier Dehon <od...@gmail.com>.
I use the same version across the board which reflects the version
(including patchlevel) of the WebSphere distribution. I do not want to
have to figure out which JARs have been updated for each corrective
package I receive, so I blindly load them all from the distribution
every time.
In my experience, vendors are not always very disciplined about
including a proper manifest in their JARs that reflects the version
number, so when I want to specify a version, I often resort to using the
max date of the files timestamps in the jar, in the YYYYMMDD form.
As per the dotted notation, it applies only to groupId, not artifactId.
if your artifact is abc.def.ghi, in group com.somecorp, version 1.0, the
jar in the repo will be at com/somecorp/abc.def.ghi/1.0/abc.def.ghi.jar
I hope this helps.
-Olivier
On Wed, 2008-02-27 at 11:39 -0500, Brown, Carlton wrote:
> Yes, we have a similar problem, not RAD but something like it. Your
> solution below is more or less what I figure I'll have to do. It's a
> variation on the other solutions mentioned, but it helps clear things up
> for me.
>
> So if I'm reading below correctly, you're essentially ignoring the real
> version of the artifact and mapping them all as version 6.3.9 (which is
> presumably the version of RAD you're using)?
>
> If the virtual POM specifies a master version of (for example 6.3.9), I
> guess one could install all the individual jars with their actual
> version numbers (derived from the jar filename or manifest). It's just
> a small additional effort if I've decided to throw in the towel and
> script a mass install.
>
> Question: I notice that using dotted notation in groupId expands to a
> directory structure during installation or deployment. Does this
> behavior also hold for artifactId?
>
> -----Original Message-----
> From: Olivier Dehon [mailto:odndev@gmail.com]
> Sent: Tuesday, February 26, 2008 9:48 PM
> To: Maven Users List
> Subject: Re: Best practice to represent an arbitrary collection of jars
> asa single dependency?
>
> 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > > 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > > > > 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 <Ca...@compucredit.com>
> 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: 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
> > > > >
> > > > >
> > > > >
> > > --------------------------------------------------------------------
> > > -
> > > > > 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
> > >
> > >
> > > --------------------------------------------------------------------
> > > - 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
> >
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Best practice to represent an arbitrary collection of jars asa single dependency?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
Yes, we have a similar problem, not RAD but something like it. Your
solution below is more or less what I figure I'll have to do. It's a
variation on the other solutions mentioned, but it helps clear things up
for me.
So if I'm reading below correctly, you're essentially ignoring the real
version of the artifact and mapping them all as version 6.3.9 (which is
presumably the version of RAD you're using)?
If the virtual POM specifies a master version of (for example 6.3.9), I
guess one could install all the individual jars with their actual
version numbers (derived from the jar filename or manifest). It's just
a small additional effort if I've decided to throw in the towel and
script a mass install.
Question: I notice that using dotted notation in groupId expands to a
directory structure during installation or deployment. Does this
behavior also hold for artifactId?
-----Original Message-----
From: Olivier Dehon [mailto:odndev@gmail.com]
Sent: Tuesday, February 26, 2008 9:48 PM
To: Maven Users List
Subject: Re: Best practice to represent an arbitrary collection of jars
asa single dependency?
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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > > > 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 <Ca...@compucredit.com>
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: 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
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > -
> > > > 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
> >
> >
> > --------------------------------------------------------------------
> > - 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
>
---------------------------------------------------------------------
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: Best practice to represent an arbitrary collection of jars as
a single dependency?
Posted by Olivier Dehon <od...@gmail.com>.
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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > > > 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 <Ca...@compucredit.com> 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: 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
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by Wayne Fay <wa...@gmail.com>.
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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > > 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 <Ca...@compucredit.com> 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: 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
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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
>
>
> ---------------------------------------------------------------------
> 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: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
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:waynefay@gmail.com]
> 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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > > 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 <Ca...@compucredit.com> 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: 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
> >
> >
> >
---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by Wayne Fay <wa...@gmail.com>.
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 <Ca...@compucredit.com> 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:waynefay@gmail.com]
> > 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 <Ca...@compucredit.com> 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: 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
>
>
> ---------------------------------------------------------------------
> 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: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by "Beelen, M. - SPLXL" <Ma...@klm.com>.
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:Carlton.Brown@compucredit.com]
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:waynefay@gmail.com]
> 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 <Ca...@compucredit.com> 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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
**********************************************************************
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
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:waynefay@gmail.com]
> 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 <Ca...@compucredit.com> 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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to represent an arbitrary collection of jars as a single dependency?
Posted by Wayne Fay <wa...@gmail.com>.
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 <Ca...@compucredit.com> 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: 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: Best practice to represent an arbitrary collection of jars as
a single dependency?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
Brown, Carlton 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
Make sure that all these artifacts are accessible through some Maven
repo. Then create a new pom along these lines:
<project ...>
<groupId>foo-corp</groupId>
<artifactId>bigbagofjars</artifactId>
<version>5.7</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.3</version>
</dependency>
.... etc etc etc ..
</dependencies>
</project>
Deploy that pom to your inhouse repo and have everybody reference it as:
<depenency>
<groupId>foo-corp</groupId>
<artifactId>bigbagofjars</artifactId>
<version>5.7</version>
<type>pom</type>
</dependency>
voila.
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org