[...]
> Those plugins are unnecessarily wrong though. The offending code in the
> war plugin:
>        <j:forEach var="dep" items="${pom.dependencies}">
>          <j:if test="${dep.getProperty('war.bundle.jar')=='true'}">
>            <lib dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
>              <include name="${dep.artifact}"/>
>            </lib>
>          </j:if>
>        </j:forEach>
> 
> Should read:
>        <j:forEach var="lib" items="${pom.artifacts}">
>            <j:set var="dep" value="${lib.dependency}"/>
>            <j:if test="${dep.getProperty('war.bundle.jar')=='true'}">
>              <lib dir="${maven.repo.local}">
>                <include name="${lib.path}"/>
>              </lib>
>            </j:if>
>        </j:forEach>
> 
> (or something like that) - jelly should always use artifacts, not
> dependencies, to construct paths. It doesnt stop you naming jars
> whatever you like, if they are in the local repo. I had a look over the
> broken plugins a while back and I think there was only one case where it
> wasnt clear that the use of dependency was a bug.
> 

What about the case when overridden jars are not in repository?

Say I will put:

maven.jar.a = ${mylibdir}/lib/a.jar
maven.jar.b = ${mylibdir}/lib/b.jar

and set myslib to 
mylib=c:\\temp



I don't see also any reason why we should guess or recompute artifacts paths
in plugins.

Artifact interface provides methods like;

File getFile();
String getPath();

(If those methods are not exactly what we need we can add similar)

Why not to use them? 
Plugin are supposed to work with artifacts.
Artifacts for me are just files with some metadata (defined by dependency).
Once we have a set of artifact we have a set of files with well defined
location in local file system. Maven core takes care about is. 
It doesn't matter if this location is relative to local repository or not.
It is fixed and already computed. Why should we bother to recalculate this
value all over again?
Only good reason I know is the fact we use ant FileSets. And they are
limited. But this is not a reason which is good enough.


mm

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

Reply via email to