[jira] Commented: (MNG-4688) Clover 3.0.2 plugin is not working with Maven 3
[ http://jira.codehaus.org/browse/MNG-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246049#action_246049 ] Nick Pellow commented on MNG-4688: -- Thanks for the heads up on this. I have released maven-clover2-plugin v 3.0.4 and bumped the version of plexus-resources to alpha-7. This should appear in maven central shortly; https://studio.plugins.atlassian.com/browse/CLMVN-136 Cheers, Nick > Clover 3.0.2 plugin is not working with Maven 3 > --- > > Key: MNG-4688 > URL: http://jira.codehaus.org/browse/MNG-4688 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-1 >Reporter: Eric Berry >Assignee: Benjamin Bentmann > > The clover build is returning the error: > [ERROR] Failed to execute goal > com.atlassian.maven.plugins:maven-clover2-plugin:3.0.2:clover (default-cli) > on project co > m.ccadllc.mediacipher: An error has occurred in Clover report generation. > Could not resolve default-clover-report.xml. P > lease try specifying this via the maven.clover.reportDescriptor property. > Failed to load resource as file [/default-clov > er-report.xml]: Could not find resource '/default-clover-report.xml'. -> > [Help 1] > However, this file is located inside the maven-clover2-plugin-3.0.2.jar. > This problem does not occur on maven 2. > The problem can be worked around by extracting the file to a local directory > and setting -Dmaven.clover.reportDescriptor. -- 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] Commented: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179092#action_179092 ] Nick Pellow commented on MNG-3595: -- Bump - has there been any decision as to the best way to move forward? This issue is rather limiting to Clover and any other plugins which create classified artifacts. What about applying Jerome's patch to Maven, and seeing what breaks? I am guessing not a lot would, since it is an extra plugin point, and is backward compatible with previous functionality. > Changes made to project resolved artifacts are overriden when a plugin uses > @requiresDependencyResolution > - > > Key: MNG-3595 > URL: http://jira.codehaus.org/browse/MNG-3595 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Jerome Lacoste > Fix For: 3.x > > Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, > MNG-3595.diff > > > clover:instrument mojo creates instrumented artifacts and attaches them with > a 'clover' classifier. > It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which > tries to change the project direct and transitive dependencies after > 'swizzling' them [3] (replacing normal artifacts with their clovered ones). > This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR > containing all available clovered dependencies. > Unfortunately maven handles direct and transitive dependencies differently > [4]. While direct dependencies are somewhat preserved (the code comments > references clover), transitive dependencies are re-resolved, and thus the > results of the swizzling operation are lost as soon as a plugin > requiresDependencyResolution in a further part of the lifecycle. > I've managed to hack maven and clover:instrument to work together by allowing > a plugin to attach some sort of "dependency resolution post processing" > operation [5]. > In the case of clover:instrument, the swizzling is then registered in the > maven project and re-performed each time the artifacts are re-resolved. > I am not very fond of this solution, but it seems to work for us on the > attached example. I will further test the patch this week on a large scale > project. > I would like to discuss ways to solve this interaction, whether the clover > plugin should be implemented differently or if maven should have some sort of > support for this use case. > [1] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java > [2] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml > [3] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java > [4] > http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406 > [5] http://www.mail-archive.com/d...@maven.apache.org/msg74636.html -- 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: (MAVENUPLOAD-2385) maven1 clover 2.4.3 plugin bundle upload
maven1 clover 2.4.3 plugin bundle upload Key: MAVENUPLOAD-2385 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2385 Project: Maven Upload Requests Issue Type: Task Reporter: Nick Pellow Hi Carlos, I'm not sure if this bundle has already been automatically synced with repo1 as per the suggestion here: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 so am creating this upload bundle request anyway. Please let me know if there is anything we need to do to have this automated. Cheers, Nick -- 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] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164989#action_164989
]
Nick Pellow commented on MNG-3530:
--
ah. sorry for the confusion here. I think I tried removing the Clover plugin
entirely from the equation, however left the check in the verifications.xml .
Cheers,Nick
> Regression: 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
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> 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] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164515#action_164515
]
Nick Pellow commented on MNG-3530:
--
Hi Brett,
Could you please confirm it works under 2.1.0-M1? I just re-read my previous
comment that it was broken under 2.1.0-M1 for me too.
Either both of us were mistaken, or possibly something has changed?
I am happy to have this closed if solved in a final 2.1.0 release.
Thanks!
Nick
> Regression: 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
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> 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] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164501#action_164501
]
Nick Pellow commented on MNG-3530:
--
Hi john,
Thanks for looking into this. This looks to now be fixed on 2.1.0-M1. It is not
however working for 2.0.10-RC8.
Here is my output running:
{{mvn clean clover2:instrument}} using maven 2.0.8, 2.0.9, 2.0.10-RC8 and
2.1.0-M1:
2.0.8: *correct behavior*
{code}
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[touch] Creating /Users/niick/downloads/MNG-3530/target/clover/test.clover
[echo] Build Dir: ${project.build.directory}/test.clover
[INFO] Executed tasks
{code}
2.0.9 *broken*
{code}
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[touch] Creating /Users/niick/downloads/MNG-3530/target/test.clover
[echo] Build Dir: /Users/niick/downloads/MNG-3530/target/test.clover
[INFO] Executed tasks
{code}
2.0.10-RC8 *broken*
{code}
[INFO] Executing tasks
[touch] Creating /Users/niick/downloads/MNG-3530/target/test.clover
[echo] Build Dir: /Users/niick/downloads/MNG-3530/target/test.clover
[INFO] Executed tasks
{code}
2.1.0-M1: *correct behavior*
{code}
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[touch] Creating /Users/niick/downloads/MNG-3530/target/clover/test.clover
[echo] Build Dir: /Users/niick/downloads/MNG-3530/target/clover/test.clover
[INFO] Executed tasks
{code}
> Regression: 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
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> 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] Commented: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159344#action_159344 ] Nick Pellow commented on MNG-3595: -- Jerome, Thanks for the excellent analysis and diagnosis of this issue. Would it be possible to add a parameter to @requiresDependencyResolution, that determines what happens to transitive dependencies in a forked lifecycle? This could default to the current behavior, thereby preserving backwards compatibility yet allow plugins to define the strategy they require. Or, are there any other work-arounds the maven-clover2-plugin can do to prevent this? Cheers, Nick > Changes made to project resolved artifacts are overriden when a plugin uses > @requiresDependencyResolution > - > > Key: MNG-3595 > URL: http://jira.codehaus.org/browse/MNG-3595 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Jerome Lacoste > Fix For: 3.x > > Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, > MNG-3595.diff > > > clover:instrument mojo creates instrumented artifacts and attaches them with > a 'clover' classifier. > It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which > tries to change the project direct and transitive dependencies after > 'swizzling' them [3] (replacing normal artifacts with their clovered ones). > This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR > containing all available clovered dependencies. > Unfortunately maven handles direct and transitive dependencies differently > [4]. While direct dependencies are somewhat preserved (the code comments > references clover), transitive dependencies are re-resolved, and thus the > results of the swizzling operation are lost as soon as a plugin > requiresDependencyResolution in a further part of the lifecycle. > I've managed to hack maven and clover:instrument to work together by allowing > a plugin to attach some sort of "dependency resolution post processing" > operation [5]. > In the case of clover:instrument, the swizzling is then registered in the > maven project and re-performed each time the artifacts are re-resolved. > I am not very fond of this solution, but it seems to work for us on the > attached example. I will further test the patch this week on a large scale > project. > I would like to discuss ways to solve this interaction, whether the clover > plugin should be implemented differently or if maven should have some sort of > support for this use case. > [1] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java > [2] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml > [3] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java > [4] > http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406 > [5] http://www.mail-archive.com/d...@maven.apache.org/msg74636.html -- 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] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158439#action_158439
]
Nick Pellow commented on MNG-3530:
--
Hi John,
Could you please confirm which branch this has been fixed on?
This behavior still persists for me under Maven 2.1.0-M1.
The attached .zip file still reproduces the problem.
Cheers,
Nick
> Regression: 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
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> 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] Closed: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow closed MAVENUPLOAD-2292. Resolution: Fixed > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar, > maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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] Commented: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157324#action_157324 ] Nick Pellow commented on MAVENUPLOAD-2292: -- thanks Carlos. Please let me know if there is anything we can do to help automate this in the future. cheers, nick > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar, > maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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] Commented: (MAVENUPLOAD-2291) Clover 2.4.2 core artifact upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157203#action_157203 ] Nick Pellow commented on MAVENUPLOAD-2291: -- Hi Carlos, that's good news. So this means that if the maven1 plugin depends on clover-2.4.2.jar, it actually comes from http://repo2.maven.org/maven2/com/cenqua/clover/clover/2.4.2/ ? Does this also mean that we can now deploy the actual maven1 clover plugin via our sync repo? Cheers, Nick > Clover 2.4.2 core artifact upload request > - > > Key: MAVENUPLOAD-2291 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2291 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow >Assignee: Carlos Sanchez > Attachments: clover-2.4.2-bundle.jar > > > Please upload this to the maven1 repository. > Clover 2.4.2 for Maven has support for Clover's Test Optimization. > Clover is free for open source projects. -- 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] Commented: (MAVENUPLOAD-2291) Clover 2.4.2 core artifact upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157186#action_157186 ] Nick Pellow commented on MAVENUPLOAD-2291: -- Hi Carlos, I'm pretty sure that is for maven2 only. Please correct me if I am wrong. Cheers, Nick > Clover 2.4.2 core artifact upload request > - > > Key: MAVENUPLOAD-2291 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2291 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow >Assignee: Carlos Sanchez > Attachments: clover-2.4.2-bundle.jar > > > Please upload this to the maven1 repository. > Clover 2.4.2 for Maven has support for Clover's Test Optimization. > Clover is free for open source projects. -- 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] Commented: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157185#action_157185 ] Nick Pellow commented on MAVENUPLOAD-2292: -- The pom.xml is in the maven-clover-plugin-2.4.2.jar inside the bundle.jar . Should it be in the top level directory? > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar, > maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow updated MAVENUPLOAD-2292: - Attachment: maven-clover-plugin-2.4.2-bundle.jar > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar, > maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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] Commented: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156187#action_156187 ] Nick Pellow commented on MAVENUPLOAD-2292: -- Hi Carlos, Thanks for the heads-up on this. I've updated our release procedure for the plugin to include the pom.xml files for both the plugin, and the clover core artifact. Please let me know if there are any problems. Cheers, Nick > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow updated MAVENUPLOAD-2292: - Attachment: maven-clover-plugin-2.4.2-bundle.jar re-uploading with pom.xml included > maven1 clover2 plugin bundle upload > --- > > Key: MAVENUPLOAD-2292 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: maven-clover-plugin-2.4.2-bundle.jar > > > This is the actual maven1 plugin bundle - ready for deployment. > The new: > clover:test-optimize > goal, will run an optimized test set, depending on what tests hit what code > during the first full test run. -- 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: (MAVENUPLOAD-2291) Clover 2.4.2 core artifact upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow updated MAVENUPLOAD-2291: - Attachment: clover-2.4.2-bundle.jar re-uploading bundle with the pom.xml included. > Clover 2.4.2 core artifact upload request > - > > Key: MAVENUPLOAD-2291 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2291 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow > Attachments: clover-2.4.2-bundle.jar > > > Please upload this to the maven1 repository. > Clover 2.4.2 for Maven has support for Clover's Test Optimization. > Clover is free for open source projects. -- 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: (MAVENUPLOAD-2292) maven1 clover2 plugin bundle upload
maven1 clover2 plugin bundle upload --- Key: MAVENUPLOAD-2292 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2292 Project: Maven Upload Requests Issue Type: Task Reporter: Nick Pellow This is the actual maven1 plugin bundle - ready for deployment. The new: clover:test-optimize goal, will run an optimized test set, depending on what tests hit what code during the first full test run. -- 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] Closed: (MAVENUPLOAD-2290) Clover2.4.2 artifact upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow closed MAVENUPLOAD-2290. Resolution: Incomplete clone FAIL > Clover2.4.2 artifact upload > --- > > Key: MAVENUPLOAD-2290 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2290 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Nick Pellow >Assignee: Carlos Sanchez > > This bundle contains the Clover 2.3.1 core classes. The Maven Clover 2.3.1 > plugin depends on this. > Could you please upload this to your maven1 repository. -- 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: (MAVENUPLOAD-2291) Clover 2.4.2 core artifact upload request
Clover 2.4.2 core artifact upload request - Key: MAVENUPLOAD-2291 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2291 Project: Maven Upload Requests Issue Type: Task Reporter: Nick Pellow Please upload this to the maven1 repository. Clover 2.4.2 for Maven has support for Clover's Test Optimization. Clover is free for open source projects. -- 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: (MAVENUPLOAD-2290) Clover2.4.2 artifact upload
Clover2.4.2 artifact upload --- Key: MAVENUPLOAD-2290 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2290 Project: Maven Upload Requests Issue Type: Task Reporter: Nick Pellow Assignee: Carlos Sanchez This bundle contains the Clover 2.3.1 core classes. The Maven Clover 2.3.1 plugin depends on this. Could you please upload this to your maven1 repository. -- 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: (SUREFIRE-530) Allow runtime ordering of tests to be specified
Allow runtime ordering of tests to be specified --- Key: SUREFIRE-530 URL: http://jira.codehaus.org/browse/SUREFIRE-530 Project: Maven Surefire Issue Type: Improvement Components: plugin Affects Versions: 2.4.3 Environment: testNG, Junit Reporter: Nick Pellow Allow other plugins to specify tests to get run, and preserve the ordering of tests. Currently, a plugin may set the "test" parameter with a comma separated list of tests to run. However, the order is not preserved. For plugins such as the maven-clover2-plugin, (possibly the maven-reactor-plugin?) that optimize the build/test run, ordering of a tests is a very nice way to ensure the build fails as fast as possible. -- 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: (SUREFIRE-526) Better support for other plugins to determine which tests are included/excluded and the order the tests get run
Better support for other plugins to determine which tests are included/excluded and the order the tests get run --- Key: SUREFIRE-526 URL: http://jira.codehaus.org/browse/SUREFIRE-526 Project: Maven Surefire Issue Type: Improvement Components: plugin Reporter: Nick Pellow Currently, it is possible to provide the 'test' pattern to the maven-surefire-plugin to include/exclude specific tests to be run. This can be set on the MavenProject instance of any plugin which runs prior to the surefire plugin. Since this is just a pattern of tests to include, it has the following shortcomings: * To excludes a single test, you need to add _all_ tests, minus the test to exclude * The order of the test patterns is not used when the tests get run. If there is no better means to control which tests get run and in which order from outside the surefire plugin, how do you suggest this be achieved? This may require changes to maven core to allow attributes be set as well as Properties. -- 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] Commented: (MCLEAN-38) Allow a global set of include and exclude filters
[ http://jira.codehaus.org/browse/MCLEAN-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148238#action_148238 ] Nick Pellow commented on MCLEAN-38: --- My plugin consists of several MOJOs. One of which runs at the end of the build, storing some state about what happened during the build. This data is optionally required for following builds, allowing the build time to be drastically reduced. bq. For instance, what generated the files to exclude, your plugin or something else? Yes, the same plugin generated the files to exclude. However, conceivably they could be produced by any plugin. bq. If the files should be excluded from cleaning, why aren't they put somewhere else? They can optionally be put somewhere else. This requires extra configuration (and effort) by the user however. The target directory is the best location for these files however, since they will be removed when the user runs the clean goal, without running my plugin first. bq. How can they ever be deleted by Maven or isn't that intended? By simply running $> mvn clean, without my mojo being explicitly called first. Also, my mojo will be able to decide when those files are to be deleted. Apart from the use case I describe above, I see this patch to be providing the extremely useful ability to specify excludes and includes on the command line. > Allow a global set of include and exclude filters > - > > Key: MCLEAN-38 > URL: http://jira.codehaus.org/browse/MCLEAN-38 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Nick Pellow > Attachments: MCLEAN-38-maven-clean-plugin.patch > > > I am about to submit a patch to the maven-clean-plugin which will allow a > global includes and excludes patterns to be configured. > Currently, it is not possibly to easily do a clean and have specific files in > the default output directories preserved. > The patch will allow a comma separated list of exclusions and inclusions to > use when removing the default output directories. -- 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] Issue Comment Edited: (MCLEAN-38) Allow a global set of include and exclude filters
[
http://jira.codehaus.org/browse/MCLEAN-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148156#action_148156
]
npellow edited comment on MCLEAN-38 at 9/17/08 2:53 AM:
I saw MCLEAN-33, and it is not fine grained or flexible enough.
ie - the clean plugin can either delete all default directories, or none.
I considered excluding the default directories from cleaning, and then using
the filesets parameter. The problems with this approach however are:
# users are required to have duplicate configuration (ie - the build directory
locations) in their pom.xml
# the maven-clean-plugin will need to be added to the users pom
Allowing a simple String to be used, instead of a Collection, allows the
patterns to be passed in on the command line.
{code}
-Dexcludes=**/expensive.file1
{code}
It also allows other plugins (this is my use case), which are bound to the
pre-clean phase to set this property on the project to avoid specific files
being deleted when clean is run.
I agree that this usage is somewhat inconsistent. You would have to agree
however, that it is extremely practical.
IMO, maven should support splitting of comma and space separated Strings into
Collection parameters automatically. This is exactly what Ant does. It would
make the pom a lot more readable, and allow passing of collection arguments on
the command line.
was (Author: npellow):
I saw MCLEAN-33, and it is not fine grained or flexible enough.
ie - the clean plugin can either delete all default directories, or none.
I considered excluding the default directories from cleaning, and then using
the filesets parameter. The problems with this approach however are:
# users are required to have duplicate configuration (ie - the build directory
locations) in their pom.xml
# the maven-clean-plugin will need to be added to the users pom
Allowing a simple String to be used, instead of a Collection, allows the
patterns to be passed in on the command line.
{code}
-Dexcludes=**/expensive.file1
{code}
It also allows other plugins (this is my use case), which are bound to the
pre-clean phase to set this property on the project to avoid specific files
being deleted when clean is run.
IMO, maven should support splitting of comma and space separated Strings into
Collection parameters automatically. This is exactly what Ant does. It would
make the pom a lot more readable, and allow passing of collection arguments on
the command line.
> Allow a global set of include and exclude filters
> -
>
> Key: MCLEAN-38
> URL: http://jira.codehaus.org/browse/MCLEAN-38
> Project: Maven 2.x Clean Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Nick Pellow
> Attachments: MCLEAN-38-maven-clean-plugin.patch
>
>
> I am about to submit a patch to the maven-clean-plugin which will allow a
> global includes and excludes patterns to be configured.
> Currently, it is not possibly to easily do a clean and have specific files in
> the default output directories preserved.
> The patch will allow a comma separated list of exclusions and inclusions to
> use when removing the default output directories.
--
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] Commented: (MCLEAN-38) Allow a global set of include and exclude filters
[
http://jira.codehaus.org/browse/MCLEAN-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148156#action_148156
]
Nick Pellow commented on MCLEAN-38:
---
I saw MCLEAN-33, and it is not fine grained or flexible enough.
ie - the clean plugin can either delete all default directories, or none.
I considered excluding the default directories from cleaning, and then using
the filesets parameter. The problems with this approach however are:
# users are required to have duplicate configuration (ie - the build directory
locations) in their pom.xml
# the maven-clean-plugin will need to be added to the users pom
Allowing a simple String to be used, instead of a Collection, allows the
patterns to be passed in on the command line.
{code}
-Dexcludes=**/expensive.file1
{code}
It also allows other plugins (this is my use case), which are bound to the
pre-clean phase to set this property on the project to avoid specific files
being deleted when clean is run.
IMO, maven should support splitting of comma and space separated Strings into
Collection parameters automatically. This is exactly what Ant does. It would
make the pom a lot more readable, and allow passing of collection arguments on
the command line.
> Allow a global set of include and exclude filters
> -
>
> Key: MCLEAN-38
> URL: http://jira.codehaus.org/browse/MCLEAN-38
> Project: Maven 2.x Clean Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Nick Pellow
> Attachments: MCLEAN-38-maven-clean-plugin.patch
>
>
> I am about to submit a patch to the maven-clean-plugin which will allow a
> global includes and excludes patterns to be configured.
> Currently, it is not possibly to easily do a clean and have specific files in
> the default output directories preserved.
> The patch will allow a comma separated list of exclusions and inclusions to
> use when removing the default output directories.
--
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: (MCLEAN-38) Allow a global set of include and exclude filters
[ http://jira.codehaus.org/browse/MCLEAN-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Pellow updated MCLEAN-38: -- Attachment: MCLEAN-38-maven-clean-plugin.patch This patch allows the following parameters to be passed to the maven-clean-plugin: # *includes* a comma-delimited list of file patterns to be deleted when removing the defaultOutputDirectories # *excludes* a comma-delimited list of file patterns to be preserved when removing the defaultOutputDirectories > Allow a global set of include and exclude filters > - > > Key: MCLEAN-38 > URL: http://jira.codehaus.org/browse/MCLEAN-38 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Nick Pellow > Attachments: MCLEAN-38-maven-clean-plugin.patch > > > I am about to submit a patch to the maven-clean-plugin which will allow a > global includes and excludes patterns to be configured. > Currently, it is not possibly to easily do a clean and have specific files in > the default output directories preserved. > The patch will allow a comma separated list of exclusions and inclusions to > use when removing the default output directories. -- 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: (MCLEAN-38) Allow a global set of include and exclude filters
Allow a global set of include and exclude filters - Key: MCLEAN-38 URL: http://jira.codehaus.org/browse/MCLEAN-38 Project: Maven 2.x Clean Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Nick Pellow I am about to submit a patch to the maven-clean-plugin which will allow a global includes and excludes patterns to be configured. Currently, it is not possibly to easily do a clean and have specific files in the default output directories preserved. The patch will allow a comma separated list of exclusions and inclusions to use when removing the default output directories. -- 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: (MAVENUPLOAD-2074) Clover2.3.1 artifact upload
Clover2.3.1 artifact upload --- Key: MAVENUPLOAD-2074 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2074 Project: maven-upload-requests Issue Type: Task Reporter: Nick Pellow This bundle contains the Clover 2.3.1 core classes. The Maven Clover 2.3.1 plugin depends on this. Could you please upload this to your maven1 repository. -- 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: (MAVENUPLOAD-2073) Clover2.3.1 Maven1 Plugin upload request
Clover2.3.1 Maven1 Plugin upload request Key: MAVENUPLOAD-2073 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2073 Project: maven-upload-requests Issue Type: Task Reporter: Nick Pellow We have just released version 2.3.1 of Clover and the Maven1 Clover plugin. This fixes a problem when running Clover under jdk 1.4. Could you please deploy this bundle to the maven central repository. Kind Regards, Nick Pellow -- 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) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Pellow updated MNG-3530:
-
Attachment: MNG-3530.zip
This archive has no dependency on Clover.
FYI - the next release of the clover plugin will be have a valid evaluation
license bundled.
Cheers,
Nick
> Regression: 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
>Assignee: John Casey
> Fix For: 2.0.10
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> 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] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134877#action_134877
]
Nick Pellow commented on MNG-3530:
--
Hi Shane,
No need for verification. I mistakenly left a reference to the clover maven
plugin. This is not needed to reproduce the bug.
Please remove the plugin configuration from the pom.xml and try again.
I've attached the archive again, with the plugin removed.
Cheers,
Nick
> Regression: 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
>Assignee: John Casey
> Fix For: 2.0.10
>
> 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: (MAVENUPLOAD-2051) Clover2.3.0 Maven1 Plugin upload request
Clover2.3.0 Maven1 Plugin upload request Key: MAVENUPLOAD-2051 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2051 Project: maven-upload-requests Issue Type: Task Reporter: Nick Pellow We have just released version 2.3.0 of Clover and the Maven1 Clover plugin. Could you please deploy this bundle to the maven central repository. Kind Regards, Nick Pellow -- 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: (MAVENUPLOAD-2052) Clover2.3.0 artifact upload
Clover2.3.0 artifact upload --- Key: MAVENUPLOAD-2052 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2052 Project: maven-upload-requests Issue Type: Task Reporter: Nick Pellow This bundle contains the Clover 2.3.0 core classes. The Maven Clover 2.3.0 plugin depends on this. Could you please upload this to your maven1 repository. -- 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.
[
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: (MNG-3530) Properties get resolved before the LifeCycle is Forked.
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] Commented: (MAVENUPLOAD-2015) Maven1 Clover 2 Plugin 2.2.0 release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130832#action_130832 ] Nick Pellow commented on MAVENUPLOAD-2015: -- Hi Carlos, Since the maven1 project has been mothballed, Atlassian is now hosting the source code (http://svn.atlassian.com/fisheye/changelog/public/contrib/clover/maven1-clover-plugin/trunk ) . This means the plugin can be maintained and remain under version control. The attached plugin has been upgraded to use the latest version of Clover - 2.2.1 . This is something many of our users have asked for. We'd hope the group name can stay the same. This will make upgrading the plugin as simple as getting users to adjust the plugin version id. Please correct me if I am wrong. If you require any more information or details regarding this, please don't hesitate to contact us. Best Regards, Nick > Maven1 Clover 2 Plugin 2.2.0 release > > > Key: MAVENUPLOAD-2015 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2015 > Project: maven-upload-requests > Issue Type: Task >Reporter: James William Dumay > > Clover is a code coverage tool for Java > Please upload :) -- 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: (MCLOVER-62) Compile errors when files are 'ed from intrumentation.
Compile errors when files are 'ed from intrumentation. --- Key: MCLOVER-62 URL: http://jira.codehaus.org/browse/MCLOVER-62 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Nick Pellow Attachments: beanutils-clover-out.txt As far as I can tell, by looking at the source code, files that are excluded from instrumentation, are also excluded from being compiled. This means, that if I exclude source code that is referenced by the unit tests, or indeed other sources that aren't excluded, the compile will fail. To observe this behaviour: 1) Checkout the commons beanutils project from: http://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk 2) Add these lines to plugins element in the pom.xml org.apache.maven.plugins maven-clover-plugin **/locale/** 3) Run: mvn clean clover:instrument clover:clover Attached is the output from maven when running the above recipe with the -X option. -- 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
