Re: Distinguishing between runtime and compile time dependencies

[Paul Libbrecht]

I know that...

But if jnlp, for example, is part of the "standard" distribution of 
plugins (does this exist?) then its tags should be fed as well.

An alternate route could be to have, at registration time, the plugins 
add elements to the schema... and have a "validate:generate-xsd" task.

Paul

On Jeudi, sept 4, 2003, at 02:28 Europe/Paris, [EMAIL PROTECTED] 
wrote:

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]


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