XSD doesn't seem to handle arbitrary content as far as I can tell, and hence we haven't got the properties in there.... -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
Paul Libbrecht <[EMAIL PROTECTED]> wrote on 04/09/2003 04:46:27 AM: > Well, you can... > But... it's not valid according to the schema. > It's also used in the JNLP plugin which does copy the jars. > > Paul > > > Jason Dillon wrote: > > You can specify properties for the dependency to indicate if it is > > runtime or not, then use that information to collect your runtime > > dependencies. > > > > Example: > > > > <dependency> > > <id>commons-logging</id> > > <version>1.0.3</version> > > <url>http://jakarta.apache.org/commons/logging</url> > > <properties> > > <runtime>true</runtime> > > </properties> > > </dependency> > > > > * * * > > <j:forEach var="artifact" items="${pom.artifacts}"> > > <j:set var="dependency" value="${artifact.dependency}"/> > > <j:if test="${dependency.getProperty('runtime') == 'true'}"> > > <ant:echo>Processing dependency: ${dependency.id}</ant:echo> > > <ant:mkdir dir="${aggregate.dir}/lib"/> > > <ant:copy todir="${aggregate.dir}/lib" file="${artifact.path}"/> > > </j:if> > > </j:forEach> > > > > --jason > > > > > > On Wednesday, September 3, 2003, at 09:57 PM, Jason van Zyl wrote: > > > >> On Wed, 2003-09-03 at 10:07, Berin Loritsch wrote: > >> > >>> Is there a magic flag to identify a runtime dependency from a compile > >>> time dependency? For example, Xerces and Xalan may be needed to compile > >>> some aspects of a project (some people use it to generate java source > >>> code), but never needed at run time. > >> > >> > >> There is no facility yet. But we've talked about it for a long time and > >> we do have working code for it in experimental versions of Maven but the > >> real crux of the problem is collecting POMs in the repositories so we > >> can build the necessary graphs. In this way you would only have to state > >> the compile time dependencies and the runtime dependencies would be > >> calculated. > >> > >> Not something that is going to make it into 1.0. > >> > >>> This will allow a number of things: > >>> > >>> * The extensions attributes can be generated ONLY for runtime > >>> dependencies > >>> * The GUMP descriptor will be able to reflect that information so that > >>> the other GUMP descriptors can propogate those dependencies for > >>> unit tests > >>> * I can develop my plugin to gather the dependencies into a > >>> distributable > >>> > >>> I personally have a need to generate a work directory like this: > >>> > >>> /${root} > >>> loader.jar > >>> /lib > >>> ***.jar > >>> /docs > >>> ***.html > >>> ***.pdf > >>> > >>> The thing is that I want to be able to collect all of the runtime > >>> dependencies for this special distribution format and place them in the > >>> lib directory. Currently, the best I can do is grab *all* the > >>> dependencies, > >>> regardless of runtime or compile time. > > > > --------------------------------------------------------------------- > 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]
