[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52827 ] 

John Casey commented on MNG-1471:
---------------------------------

The whole point of maven is to have your project declaratively specified, and 
then use that information to build the project artifact, project documentation, 
etc., etc. Why would you want to remove that safety net?

Aside from this discussion, there *is* an SCM wagon provider (not sure of what 
quality it currently is), which can retrieve your dependencies from 
CVS/SVN/etc. if your scm repository is structured as a normal maven repository. 
Then, it's just a matter of specifying the correct <repositories/> 
configuration, and adding a build <extension/> for the scm wagon. Would this 
work?

It seems as if you've been using Maven 1 as a shell around Ant for some time 
now, if you're still adding lib/*.jar. System dependencies are "broken", in 
that they don't support transitivity, and can *very* easily become non-portable 
(like, if lib/ exists outside your project directory...it doesn't, does it??). 
For things like tools.jar, we're planning to support the notion of 
specification dependencies, where tools.jar might implement some javac POM or 
something. For native builds, where the dependency is actually installed on the 
system somewhere, alternative artifact resolver implementations are more 
appropriate, since specifying the path of these deps on the user-POM side isn't 
very efficient.

> 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
>     Assignee: John Casey
>     Priority: Critical
>      Fix For: 2.0.1
>  Attachments: MNG-1471-maven-project.patch
>
> Original Estimate: 30 minutes
>         Remaining: 30 minutes
>
> 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]

Reply via email to