[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_50574 ]
Jeff Jensen commented on MNG-1471:
----------------------------------
Thanks for the workaround.
I like the repo approach and strong Maven recommendation, especially for the
plugins and tools.
I think it is a Maven failing to enforce that on everything and not have a
simple supported mechanism to get ${basedir}/lib (or whatever dir) on the
classpath. It causes headaches for some adopters, including us, and may cause
it not to get used (that is IMO worse than supporting the relative system path
that deviates from the vision of all artifacts/dependencies in a Maven repo).
> when they are requested transitively they can not be found.
A use case is with 3rd party libs/jars that are source controlled and delivered
to the workspace in that manner. They are not housed by any Maven repos (you
say "put them in there", the product team's decision is "no"). The repo is the
source control repository. The version to use is the one in the referenced
directory. In this situation, the dependency is resolved in the process around
accepting a new lib version into source control and integrating to the correct
product versions. This is part of the reproducible builds best practice - all
"source" artifacts are sourced in the codeline. Jars without source are source
artifacts when that is the closest original source artifact obtainable.
Not everyone can get away from having jars source controlled and instead having
them in Maven repos.
My summary is instead of the tool forcing this particular manner on users, let
the user decide when it is correct to put them in a Maven repo and when not to
by having the local reference feature. This is flexibility and supports easier
Maven adoption.
> Module paths for system scope are relative to parent pom instead of its own
> ---------------------------------------------------------------------------
>
> Key: MNG-1471
> URL: http://jira.codehaus.org/browse/MNG-1471
> Project: Maven 2
> Type: Bug
> Components: maven-compiler-plugin
> Versions: 2.0
> Environment: Win XP, Maven 2.0
> Reporter: Jeff Jensen
> Priority: Critical
>
>
> When building from the parent POM dir, all paths are relative to it. A
> problem occurs when its modules have dependencies of <scope>system</scope> -
> the module's corresponding <systemPath> is relative to the parent POM dir,
> instead of the module's POM dir.
> With a module's <systemPath> set to compile correctly it on its own,
> compiling from its parent POM dir gives this error:
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> GroupId: thegrp
> ArtifactId: subsystem
> Version: 2.1-SNAPSHOT
> Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in
> path: src\lib\subsystem.jar
> thegrp:subsystem:2.1-SNAPSHOT:jar
> (would be nice to have the fully qualified path name listed there, instead of
> the relative one so users would know where it is really looking for it
> from)
> Expected behavior is that Maven treats system scope paths relative to the
> module POM, not the parent's POM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
