date:20080417

[jira] Commented: (MNG-2589) Inherit transitive dependencies with runtime scope

2008-04-17 Thread Bugittaa Pahasti (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131084#action_131084
 ] 

Bugittaa Pahasti commented on MNG-2589:
---

Please read my comment in MNG-2205 (don't wan't to copy-paste that here). 
Generally, I think this should be how maven would work, so transitive 
dependencies would not be included in compile time classpath.

I know some people will think otherwise, so perhaps providing an option would 
be good, but I would prefer the default being as Joerg suggests.

Could someone fix the subject?

> Inherit transitive dependencies with runtime scope
> --
>
> Key: MNG-2589
> URL: http://jira.codehaus.org/browse/MNG-2589
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.1
>
>
> Transitive dependencies of scope "compile" should be inherited with scope 
> "compile" only. This would avoid unwanted usage of 3rd party packages and 
> make explicit dependencies visible. It should be possible at least to run 
> Maven in such a mode.

-- 
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

[jira] Created: (MNG-3530) Properties get resolved before the LifeCycle is Forked.

2008-04-17 Thread Nick Pellow (JIRA)

Properties get resolved before the LifeCycle is Forked.
---

 Key: MNG-3530
 URL: http://jira.codehaus.org/browse/MNG-3530
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.9
Reporter: Nick Pellow


Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project 
properties are resolved by maven before the lifecycle is forked.
This means that the forked lifecycle has the non-forked lifecycle's values.

This was not the case in maven prior to version 2.0.9, where properties were 
resolved at a much later time.

For example - the attached sample project uses the Clover plugin with the 
xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8* 
you can see the following output:

{code}
[INFO] [xdoclet:xdoclet {execution: default}]
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
 [echo] Build Dir: ${project.build.directory}/test.clover
[INFO] Executed tasks
{code}

whilst *Maven 2.0.9* outputs:

{code}
[INFO] [xdoclet:xdoclet {execution: default}]
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
[touch] Creating 
/Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
 [echo] Build Dir: 
/Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
[INFO] Executed tasks
[INFO] [resources:resources]
{code}

The fact the  ${project.build.directory} property has been expanded already 
under 2.0.9, means that the forked lifecycle has the same value for that 
property.

This new behavior will break any plugin which uses a forked lifecycle.

-- 
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

[jira] Updated: (MNG-3530) Properties get resolved before the LifeCycle is Forked.

2008-04-17 Thread Nick Pellow (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Pellow updated MNG-3530:
-

Attachment: MNG-3530.tar.gz

To reproduce this bug, simply unpack this archive and run:
{code}
mvn clean install
{code}

When run with version 2.0.9 of maven you will see that the properties get 
resolved.
When run with version 2.0.8, these properties are not resolved.

Please let me know if you have any difficulties reproducing this.

> Properties get resolved before the LifeCycle is Forked.
> ---
>
> Key: MNG-3530
> URL: http://jira.codehaus.org/browse/MNG-3530
> Project: Maven 2
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.0.9
>Reporter: Nick Pellow
> Attachments: MNG-3530.tar.gz
>
>
> Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project 
> properties are resolved by maven before the lifecycle is forked.
> This means that the forked lifecycle has the non-forked lifecycle's values.
> This was not the case in maven prior to version 2.0.9, where properties were 
> resolved at a much later time.
> For example - the attached sample project uses the Clover plugin with the 
> xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8* 
> you can see the following output:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
>  [echo] Build Dir: ${project.build.directory}/test.clover
> [INFO] Executed tasks
> {code}
> whilst *Maven 2.0.9* outputs:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
> [touch] Creating 
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
>  [echo] Build Dir: 
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [INFO] Executed tasks
> [INFO] [resources:resources]
> {code}
> The fact the  ${project.build.directory} property has been expanded already 
> under 2.0.9, means that the forked lifecycle has the same value for that 
> property.
> This new behavior will break any plugin which uses a forked lifecycle.

-- 
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

[jira] Created: (MDEP-162) localRepository as file URL in settings.xml makes unpacking dependencies fail: expanding into null

2008-04-17 Thread Heiko Selber (JIRA)

localRepository as file URL in settings.xml makes unpacking dependencies fail:
expanding into null
--

Key: MDEP-162
URL: http://jira.codehaus.org/browse/MDEP-162
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.0
Environment: Windows XP
Reporter: Heiko Selber
Assignee: Brian Fox
Priority: Minor
Attachments: expanding_into_null.txt

I specified the localRepository in settings.xml like this:

file:///C:/.m2/repository

Using a file URL is apparently valid for artifacts which are only downloaded.

However, when a dependency is to be expanded to .unpacked-modules, a file URL
leads to failure.

The dependency is unpacked to the directory where mvn was started.

The console output shows this line:

[INFO] Expanding:
c:\.m2\repository\com\company\project\activemq-cpp\2.1.3_02\activemq-cpp-2.1.3_02-win32.zip
into null

Debug output is attached, look for outputDirectory.

The problem here is an inconsistency in treating a file URL; it is correctly
used by some modules, but incorrectly by others.

Possible solutions:

1. Accept file URLs everywhere (preferred)
2. Don't accept file URLs anywhere and fail cleanly when file URL is encountered
3. Document clearly in which format the path is to be given

--
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

57 matches

Mail list logo