Michal Maczka wrote:
> 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.
Path overriding gives an extra bit of flexibility, but experience shows
that such extra bits is all too often used to complicate things beyound
need, and cause unnecessary grief.
I suggest that path overriding should be dropped if it causes
considerable implementation problems.
> 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.
I'd say that it would be enough if one developer run a special goal that
would copy the jars over. It could even be interactive - ask for lib
directory location, target repository location (local fs should be
sufficient - resulting repo can be copied over to the destination server
manually), and then iterate over the jars and ask for their groupId,
artifactId and version, trying to provide sensible defaults based on the
POM.
> So -1 on first kind of overriding but +1 on second.
I second Michal's opinion.
> 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.
Are they any different that any other remote repositories? I think that
maven supports them now, it's only a matter of terminology.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
