ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten.Pfeif...@gebit.de
Subject Re: How to deal with several "provided" artifacts from different frameworks
Date Mon, 13 Jan 2014 20:46:01 GMT
You can package all these jars as separate Ivy modules and have one or two 
"meta-modules" that aggregate the other modules..
Or you can have just one or two big modules with all those jars as 
artifacts.

And you need to use Ivy configurations to make sure that theses jars end 
up in the compile classpath, but
nowhere else.

Cheers
Carsten



Von:    "KARR, DAVID" <dk068x@att.com>
An:     "ivy-user@ant.apache.org" <ivy-user@ant.apache.org>
Datum:  13.01.2014 20:03
Betreff:        How to deal with several "provided" artifacts from 
different frameworks




I'm continuing to look at the large multi-module Ant build I work with, to 
see if I could clean this up a bit by integrating Ivy.

I'm not just looking at how to clean up the build, but to make it easier 
for developers to work with checked-out projects in Eclipse.

Besides the somewhat haphazard way we reference simple third-party and 
internal artifacts (all of which I see how I can Ivy-ize), we also use two 
large frameworks that encompass several jars each, and both of those jar 
sets are "provided" artifacts, like the use of "provided" artifacts in 
Maven, where we want to make them available at compile time, but those 
artifacts are not to be assembled into the deployable component, as they 
will be available at runtime, however the framework does it.

Presently, these "provided" frameworks are specified in our Eclipse 
projects as "variables", but this is messy.

If I end up specifying these numerous jars in ivy dependencies, it would 
be nice if I could group them, so it's clear what list of jars is part of 
framework "foo", and which is part of framework "bar".  You could do this 
with Maven by specifying a pom that just lists those artifacts, and having 
projects reference that pom.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message