> -----Original Message-----
> From: dion gillard [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2003 5:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: private jar dependencies
>
> 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.
So they just override version? Not paths?
I am surly +1 for allowing overriding version.
This is also a must from the perspective of "transitive dependencies"
There must be some way of setting the preferred version or artifacts
Even if they are not listed as dependencies in project.xml
But we have two kinds of overrides:
maven.jar.artifactId = [path]
maven.jar.artifactId = [version]
First of all it's just heuristic guessing if user has overridden version or
path. And sometimes this guessing can fail (even ofen).
Secondly the version with [path] overriding is against maven philosophy of
forcing users to keep artifact in repositories.
Say that users have "unversion " artifacts inside his project (e.g in the
${basedir}/lib directory). They want to quickly switch to maven.
Maven should help them, but such help can be also resolved outside of maven
core using "special" fetchers.
Say you use fetcher which will during "download" convert paths like
/groupId/jars/artifactId-version.jar to ${basedir}/lib/artifactId.jar.
So after first run of such fetcher the local repository will be populated
with those jars. After some time when this operation was performed by all
team members the lib directory can be erased.
So -1 on first kind of overriding but +1 on second.
I also think that we should support per project repositories (they are in
practice threaten as another "remote" repository). This will allow easier
transition for project using e.g. ant to maven.
>
> > 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.
Not really. If we use jar overriding with
maven.jar.artifactId = [path]
it can be anywhere.
[...]
mm
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
