Michal Maczka wrote:
There is one more mean for realizing such scenario which was not mentioned
here:
jar overriding mechanism (or more generally artifact overriding mechanism).
I am personally for dropping the jar overriding mechanism.
and for replacing them with such "fake remote repository" as Aslak has
described.
Big, big -1 on this. I have a real need for the jar override facility.
We have maven users who run common sql through db2. they each have their
own db2 release, and MUST use the jar file that corresponds to their db2
install.
This will make the implementation cleaner.
And less functional.
There is a lot of places in maven where the fact that artifact was overriden
is simply ignored.
This is a bug and should be fixed. Before 1.0
This feature probably is not used so often but surly plugins like
war, ear, eclipse are not aware of the fact that artifact can be overriden!
and what they do is something like:
<j:if test="${dep.getProperty('war.bundle')=='true' and dep.type
=='jar' }">
<ant:lib dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
<ant:include name="${dep.artifact}"/>
</ant:lib>
</j:if>
So basiclly they require that artifact must be in local repository.
Any artifact thats listed as a dependency MUST be available in the local
repository.
I think that this assumption is correct and it is the idea of jar overriding
which is wrong.
I think this assumption is correct, and that the plugins shouldn't
assume this format.
Moreover there is no easy way of determining if artifact was overriden or
not (it is in maven-new, but that's different story)
Is it needed?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
