[jira] Created: (DOXIA-243) Add an 'unknown' element to Sink API
Add an 'unknown' element to Sink API
Key: DOXIA-243
URL: http://jira.codehaus.org/browse/DOXIA-243
Project: Maven Doxia
Issue Type: Improvement
Components: Sink API
Reporter: Lukas Theussl
Fix For: 1.0-beta-1
In order to solve the problem of rawText emission in the XdocParser (see
DOXIA-183) I propose to add an "unknown" event to the Sink API:
{code}
void unknown( String name, Object[] requiredParams, SinkEventAttributes atts );
{code}
This would avoid to make assumptions about the receiving sink in the parser and
allow the specific sinks to deal with the event.
--
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: (DOXIA-243) Add an 'unknown' element to Sink API
[
http://jira.codehaus.org/browse/DOXIA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-243:
Assignee: Lukas Theussl
Fix Version/s: 1.0-beta-1
> Add an 'unknown' element to Sink API
>
>
> Key: DOXIA-243
> URL: http://jira.codehaus.org/browse/DOXIA-243
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 1.0-beta-1
>
>
> In order to solve the problem of rawText emission in the XdocParser (see
> DOXIA-183) I propose to add an "unknown" event to the Sink API:
> {code}
> void unknown( String name, Object[] requiredParams, SinkEventAttributes atts
> );
> {code}
> This would avoid to make assumptions about the receiving sink in the parser
> and allow the specific sinks to deal with the event.
--
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-519) Timestamps on messages
[ http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-519: -- Component/s: Logging > Timestamps on messages > -- > > Key: MNG-519 > URL: http://jira.codehaus.org/browse/MNG-519 > Project: Maven 2 > Issue Type: Wish > Components: Logging, Plugins and Lifecycle >Reporter: Jeff Jensen >Priority: Minor > Fix For: 2.x > > > With current and/or moving forward with M2, I would like an option for > timestamped messages. > We have a somewhat long nightly process. I regularly wish for timestamps on > the log messages from the Maven build. The two primary reasons for this are > duration calculation - how long did something take, and an occasional > correlation with an outside event. -- 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-519) Timestamps on messages
[ http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136068#action_136068 ] Jerome Lacoste commented on MNG-519: As a work-around it is possible to pipe the output to a script that will add the timestamp for you. On Linux, you can use the ts perl script. > Timestamps on messages > -- > > Key: MNG-519 > URL: http://jira.codehaus.org/browse/MNG-519 > Project: Maven 2 > Issue Type: Wish > Components: Plugins and Lifecycle >Reporter: Jeff Jensen >Priority: Minor > Fix For: 2.x > > > With current and/or moving forward with M2, I would like an option for > timestamped messages. > We have a somewhat long nightly process. I regularly wish for timestamps on > the log messages from the Maven build. The two primary reasons for this are > duration calculation - how long did something take, and an occasional > correlation with an outside event. -- 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: (MJAVADOC-187) Javadoc jar manifest should contain Specification and Implementation details
[ http://jira.codehaus.org/browse/MJAVADOC-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-187: - Affects Version/s: 2.4 Fix Version/s: 2.5 > Javadoc jar manifest should contain Specification and Implementation details > > > Key: MJAVADOC-187 > URL: http://jira.codehaus.org/browse/MJAVADOC-187 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: SebbASF >Priority: Minor > Fix For: 2.5 > > > The javadoc jar manifest should contain Specification and Implementation > details, e.g.: > Implementation-Title: Commons SCXML > Implementation-Vendor: The Apache Software Foundation > Implementation-Vendor-Id: org.apache > Implementation-Version: 0.8 > Specification-Title: Commons SCXML > Specification-Vendor: The Apache Software Foundation > Specification-Version: 0.8 -- 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: (MJAVADOC-187) Javadoc jar manifest should contain Specification and Implementation details
[ http://jira.codehaus.org/browse/MJAVADOC-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-187. Assignee: Vincent Siveton Resolution: Fixed fixed in r659968, snapshot deployed. Have a glance to Maven archiver reference before: http://maven.apache.org/shared/maven-archiver/index.html > Javadoc jar manifest should contain Specification and Implementation details > > > Key: MJAVADOC-187 > URL: http://jira.codehaus.org/browse/MJAVADOC-187 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: SebbASF >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.5 > > > The javadoc jar manifest should contain Specification and Implementation > details, e.g.: > Implementation-Title: Commons SCXML > Implementation-Vendor: The Apache Software Foundation > Implementation-Vendor-Id: org.apache > Implementation-Version: 0.8 > Specification-Title: Commons SCXML > Specification-Vendor: The Apache Software Foundation > Specification-Version: 0.8 -- 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: (MJAVADOC-191) Add a new Mojo for test-jar
Add a new Mojo for test-jar --- Key: MJAVADOC-191 URL: http://jira.codehaus.org/browse/MJAVADOC-191 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Affects Versions: 2.4 Reporter: Vincent Siveton Similar to JavadocJar, but for test -- 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: (MJAVADOC-192) Bump to a new release of Doxia
[ http://jira.codehaus.org/browse/MJAVADOC-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-192: - Fix Version/s: 2.5 > Bump to a new release of Doxia > -- > > Key: MJAVADOC-192 > URL: http://jira.codehaus.org/browse/MJAVADOC-192 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Vincent Siveton > Fix For: 2.5 > > > The doxiaVersion is 1.0-alpha-7. We need to bump it. -- 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: (MJAVADOC-193) Bump
Bump Key: MJAVADOC-193 URL: http://jira.codehaus.org/browse/MJAVADOC-193 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Reporter: Vincent Siveton Fix For: 2.5 -- 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: (MJAVADOC-193) Bump plexus-utils to 1.5.1
[ http://jira.codehaus.org/browse/MJAVADOC-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-193: - Affects Version/s: 2.4 Fix Version/s: 2.5 Summary: Bump plexus-utils to 1.5.1 (was: Bump) > Bump plexus-utils to 1.5.1 > -- > > Key: MJAVADOC-193 > URL: http://jira.codehaus.org/browse/MJAVADOC-193 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Vincent Siveton > Fix For: 2.5 > > -- 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: (MJAVADOC-192) Bump to a new release of Doxia
Bump to a new release of Doxia -- Key: MJAVADOC-192 URL: http://jira.codehaus.org/browse/MJAVADOC-192 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.4 Reporter: Vincent Siveton Fix For: 2.5 The doxiaVersion is 1.0-alpha-7. We need to bump it. -- 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: (MARTIFACT-18) NumberFormatException parsing certain versions
[ http://jira.codehaus.org/browse/MARTIFACT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MARTIFACT-18: Attachment: martifact-parse-version-2.diff Updated patch that uses BigInteger to compare integer version parts. > NumberFormatException parsing certain versions > -- > > Key: MARTIFACT-18 > URL: http://jira.codehaus.org/browse/MARTIFACT-18 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Igor Fedorenko >Priority: Critical > Attachments: martifact-parse-version-2.diff, > martifact-parse-version.diff > > > ComparableVersion.parseVersion chokes on versions that have substrings that > look like numbers but are too big to fit into int value. For example, > 1.2.3.200705301630. -- 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: (MANTRUN-68) Use ant-1.7.0
[ http://jira.codehaus.org/browse/MANTRUN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136076#action_136076 ] ajbanck commented on MANTRUN-68: Looks like the Affects and Fix version/s fields are mixed up: Affects Version/s: 1.2 Fix Version/s: None Affects version/s should be 1.1 Fix version/s 1.2 (I assume..) > Use ant-1.7.0 > - > > Key: MANTRUN-68 > URL: http://jira.codehaus.org/browse/MANTRUN-68 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.2 > Environment: xp, linux >Reporter: Dan Tran > Attachments: MANTRUN-68-maven-antrun-plugin.patch > > > with out this upgrade, i will need to ant 1.7.0 to use its new > features like abily to do delete,move, etc using filelist -- 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-2076) Upload jSDP 1.1
Upload jSDP 1.1 --- Key: MAVENUPLOAD-2076 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2076 Project: Maven Upload Requests Issue Type: Wish Reporter: Claudio Di Vita Attachments: jsdp-info.txt jSDP is a Java library that enable users to manipulate SDP messages. I'm the developer of jSDP, please upload its artifacts. -- 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: (MANTRUN-93) maven-antrun-plugin must depend on ant v1.7.0
[ http://jira.codehaus.org/browse/MANTRUN-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MANTRUN-93. -- Resolution: Duplicate > maven-antrun-plugin must depend on ant v1.7.0 > - > > Key: MANTRUN-93 > URL: http://jira.codehaus.org/browse/MANTRUN-93 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Graham Leggett >Priority: Critical > > The most recent version of maven-antrun-plugin (1.1) has a hard dependency on > ant v1.6.5. > A version of maven-antrun-plugin needs to be released depending on ant > v1.7.0, so that ant v1.7.0 features are available to maven users. > This issue has been raised before (MNG-3083), though no clear reason was > given for marking this as "wont fix". -- 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-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
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 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/[EMAIL PROTECTED]/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-2077) Upload Request for fixedformat4j
Upload Request for fixedformat4j Key: MAVENUPLOAD-2077 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2077 Project: Maven Upload Requests Issue Type: Wish Reporter: Jacob von Eyben Bundles: http://fixedformat4j.googlecode.com/files/fixedformat4j-1.0.0-bundle.jar http://fixedformat4j.googlecode.com/files/fixedformat4j-1.1.0-bundle.jar Authentication: http://fixedformat4j.ancientprogramming.com/ http://fixedformat4j.ancientprogramming.com/team-list.html I'm a developer on fixedformat4j, and want to use the com.ancientprogramming groupId I own ancientprogramming.com domain, you can see my name on the blog at www.ancientprogramming.com -- 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-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:all-tabpanel ] Jerome Lacoste updated MNG-3595: Attachment: MNG-3595-test-project.tar.bz2 a simple test project that contains a log produced after patching maven and cloved plugin with the hack . Notice how the expected-mvn.log contains: [INFO] Building war: /tmp/clover-war-hello-world-trunk/webapp/target/clover/sayHello-1.0-clover.war [DEBUG] adding directory META-INF/ [...] [DEBUG] adding entry WEB-INF/lib/a-1.0-clover.jar [DEBUG] adding entry WEB-INF/lib/clover-2.1.0.jar [DEBUG] adding entry WEB-INF/lib/b-1.0-clover.jar while maven will today include b-1.0-clover.jar and a-1.0.jar > 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 > Attachments: MNG-3595-test-project.tar.bz2 > > > 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/[EMAIL PROTECTED]/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] Updated: (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:all-tabpanel ] Jerome Lacoste updated MNG-3595: Attachment: MNG-3595.diff The patch I've applied to maven before modifying the clover plugin > 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 > Attachments: MNG-3595-test-project.tar.bz2, 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/[EMAIL PROTECTED]/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] Closed: (NMAVEN-73) NUnit output is inconsistent with maven-test-plugin output
[
http://jira.codehaus.org/browse/NMAVEN-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evan Worley closed NMAVEN-73.
-
Resolution: Fixed
Patch applied long ago
> NUnit output is inconsistent with maven-test-plugin output
> --
>
> Key: NMAVEN-73
> URL: http://jira.codehaus.org/browse/NMAVEN-73
> Project: NMaven
> Issue Type: Improvement
>Affects Versions: 0.14 (Unreleased)
> Environment: Maven 2.0.4 with NMaven 0.14-SNAPSHOT
>Reporter: Evan Worley
>Priority: Minor
> Attachments: testPatch-withLicense.txt, testPatch-withLicense.txt,
> testPatch.txt, testPatch.txt
>
>
> I was thinking there would be some value in doing some work on the nunit
> plugin to add some output similar to the junit plugin. Currently when nunit
> tests run, all the output is logged to file. It is not too much fun when
> your tests run for a few minutes, you see nothing. Here is a junit output vs
> nunit output comparison
> -- JUNIT --
> Running package1.TestClass1
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running package2.TestClass2
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> .
> .
> .
> Results :
> Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> -- NUNIT --
> NMAVEN-040-000: Executed command: Commandline = nunit-console C:\dev\project
> \main\component\target\test-assemblies\Namespace.Artifact.dll /out
> {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> The nmaven test plugin should capture the stdout/stderr from nunit and format
> is similar to junit. These inconsistencies are especially noticed in
> environments where you build the same component in java and C#. Switching
> from the java to C# build seems like a whole new world, instead of simply a
> new language
--
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=136104#action_136104 ] Jerome Lacoste commented on MNG-3595: - I forgot to say that the patch I've made above applies to 2.0.6. I expect the same patch to work more or less on 2.0.9. Also the patch isn't cleaned up as the real change should be on the MavenProject class. Will attach a cleaned up patch. Doesn't really matter as the solution isn't going to be accepted as is :) > 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 > 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/[EMAIL PROTECTED]/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] Updated: (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:all-tabpanel ] Jerome Lacoste updated MNG-3595: Attachment: MNG-3595.diff > 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 > 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/[EMAIL PROTECTED]/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] Closed: (NMAVEN-107) Missing packaging paramter in bootstrap-build.bat
[ http://jira.codehaus.org/browse/NMAVEN-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-107. -- Resolution: Fixed Patch applied, thank you > Missing packaging paramter in bootstrap-build.bat > - > > Key: NMAVEN-107 > URL: http://jira.codehaus.org/browse/NMAVEN-107 > Project: NMaven > Issue Type: Bug >Reporter: Maria Catherine Tan >Priority: Minor > Attachments: fix-xmlschema-install.patch > > > this applies for > https://svn.apache.org/repos/asf/incubator/nmaven/tags/STABLE-2007-12-16/ -- 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: (NMAVEN-108) NMaven test compilation occurs in the compile phase
[ http://jira.codehaus.org/browse/NMAVEN-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-108. -- Resolution: Fixed Patch applied, thank you. > NMaven test compilation occurs in the compile phase > --- > > Key: NMAVEN-108 > URL: http://jira.codehaus.org/browse/NMAVEN-108 > Project: NMaven > Issue Type: Bug >Reporter: John Michael Luy > Attachments: NMAVEN-108.patch > > > Using the STABLE-2007-12-16 tag, NMaven test compilation occurs in the > compile phase. It should be on the test-compile phase. -- 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: (NMAVEN-109) The text '${file.separator}' sometimes appear in directory names
[
http://jira.codehaus.org/browse/NMAVEN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evan Worley closed NMAVEN-109.
--
Resolution: Fixed
Patch applied, thank you
> The text '${file.separator}' sometimes appear in directory names
>
>
> Key: NMAVEN-109
> URL: http://jira.codehaus.org/browse/NMAVEN-109
> Project: NMaven
> Issue Type: Bug
>Reporter: John Michael Luy
> Attachments: NMAVEN-109.patch
>
>
> Using the STABLE-2007-12-16 tag, the text '${file.separator}' sometimes
> appear in directory names for tests.
--
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: (NMAVEN-114) Jetty is pulled out by plugins, even if it isn't needed
[ http://jira.codehaus.org/browse/NMAVEN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-114. -- Resolution: Fixed Fix Version/s: 0.14 (Unreleased) Patch applied, thank you! > Jetty is pulled out by plugins, even if it isn't needed > --- > > Key: NMAVEN-114 > URL: http://jira.codehaus.org/browse/NMAVEN-114 > Project: NMaven > Issue Type: Improvement >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez >Priority: Minor > Fix For: 0.14 (Unreleased) > > Attachments: NMAVEN-114.patch > > > Jetty isn't necessary in most of the plugins, but it is still downloaded as a > dependency of the plugins. -- 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: (NMAVEN-116) Add feature for Solution.JavaBinding plugin to pickup resource file in the source directory
[ http://jira.codehaus.org/browse/NMAVEN-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136110#action_136110 ] Evan Worley commented on NMAVEN-116: For consistency, I think the resx files should be placed in src/main/resources, not src/main/csharp. What do you think? > Add feature for Solution.JavaBinding plugin to pickup resource file in the > source directory > --- > > Key: NMAVEN-116 > URL: http://jira.codehaus.org/browse/NMAVEN-116 > Project: NMaven > Issue Type: New Feature >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez > Attachments: NMAVEN-116.patch > > > If *.resx file is found in the source directory of nmaven project, > Solution.JavaBinding will generate the reference entry in *.csproj/.*vbproj > file. -- 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: (NMAVEN-117) The project generated by the NMaven netexecutable archetype defaults to version 0.14-incubating-SNAPSHOT when it should be 1.0-SNAPSHOT
[ http://jira.codehaus.org/browse/NMAVEN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-117. -- Resolution: Fixed Fix Version/s: 0.14 (Unreleased) Patch applied, thank you > The project generated by the NMaven netexecutable archetype defaults to > version 0.14-incubating-SNAPSHOT when it should be 1.0-SNAPSHOT > --- > > Key: NMAVEN-117 > URL: http://jira.codehaus.org/browse/NMAVEN-117 > Project: NMaven > Issue Type: Bug >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez > Fix For: 0.14 (Unreleased) > > Attachments: NMAVEN-117.patch > > > The project generated by the NMaven netexecutable archetype defaults to > version 0.14-maestro-1.5 when it should be 1.0-SNAPSHOT. It should probably > be filtered out. -- 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: (NMAVEN-118) Errors from .NET plugins are not recognized
[ http://jira.codehaus.org/browse/NMAVEN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-118. -- Resolution: Fixed Fix Version/s: 0.14 (Unreleased) Patch was previously applied > Errors from .NET plugins are not recognized > --- > > Key: NMAVEN-118 > URL: http://jira.codehaus.org/browse/NMAVEN-118 > Project: NMaven > Issue Type: Bug >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez > Fix For: 0.14 (Unreleased) > > Attachments: NMAVEN-118.patch > > > Errors are not detected because the process isn't allowed to finish. -- 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: (NMAVEN-121) Have a configurable root namespace for VB assembly
[ http://jira.codehaus.org/browse/NMAVEN-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Worley closed NMAVEN-121. -- Resolution: Fixed Fix Version/s: 0.14 (Unreleased) Patch file doesn't work with SVN patch.. Missing Index and other bits, not sure how you generated it. Manually applied patch. Thanks! > Have a configurable root namespace for VB assembly > -- > > Key: NMAVEN-121 > URL: http://jira.codehaus.org/browse/NMAVEN-121 > Project: NMaven > Issue Type: New Feature >Affects Versions: 0.14 (Unreleased) >Reporter: jan ancajas > Fix For: 0.14 (Unreleased) > > Attachments: NMAVEN-121.patch > > > Build using NMaven the does not include the root namespace. This is exclusive > to VB, where the name space can be specified in the root name space property. -- 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: (MJAR-107) [PATCH] Need the ability to include/exclude files based on output from other mojos.
[PATCH] Need the ability to include/exclude files based on output from other mojos. --- Key: MJAR-107 URL: http://jira.codehaus.org/browse/MJAR-107 Project: Maven 2.x Jar Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Christian Schulte Priority: Blocker Using various mojos to generate sources (JAXB,xmlbeans,castor,etc.) I would need the ability to let those mojos (or my own) specify a list of excludes for the jar mojo to not include all generated class files in the final jar file. I attached a patch which introduces two new mojo parameters includesFile and excludesFile which may point to textfiles containing includes or excludes to be used by the jar mojo. This way it is possible to let other mojos write those files and somehow configure the jar mojo that way. I did not find another solution to let mojos introduce such configuration of the jar mojo in another way. Any other solution highly appreciated. -- 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: (MJAR-107) [PATCH] Need the ability to include/exclude files based on output from other mojos.
[ http://jira.codehaus.org/browse/MJAR-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MJAR-107: --- Attachment: MJAR-107.patch Patch adding includesFile and excludesFile parameters. > [PATCH] Need the ability to include/exclude files based on output from other > mojos. > --- > > Key: MJAR-107 > URL: http://jira.codehaus.org/browse/MJAR-107 > Project: Maven 2.x Jar Plugin > Issue Type: Wish >Affects Versions: 2.2 >Reporter: Christian Schulte >Priority: Blocker > Attachments: MJAR-107.patch > > > Using various mojos to generate sources (JAXB,xmlbeans,castor,etc.) I would > need the ability to let those mojos (or my own) specify a list of excludes > for the jar mojo to not include all generated class files in the final jar > file. I attached a patch which introduces two new mojo parameters > includesFile and excludesFile which may point to textfiles containing > includes or excludes to be used by the jar mojo. This way it is possible to > let other mojos write those files and somehow configure the jar mojo that > way. I did not find another solution to let mojos introduce such > configuration of the jar mojo in another way. Any other solution highly > appreciated. -- 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: (NMAVEN-112) Unable to generate solution file from test project
[
http://jira.codehaus.org/browse/NMAVEN-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Napoleon Esmundo C. Ramirez updated NMAVEN-112:
---
Description:
To reproduce:
mvn archetype:create -DgroupId=NMaven -DartifactId=NMaven.Test
-DarchetypeArtifactId=maven-archetype-dotnet-simple
-DarchetypeGroupId=org.apache.maven.dotnet -DarchetypeVersion=0.14
cd NMaven.Test
mvn install
mvn clean
mvn org.apache.maven.dotnet.plugins:maven-vsinstaller-plugin:install
mvn NMaven.Plugins:NMaven.Plugin.Solution.JavaBinding:Solution
This results in some build output, then an error/debug dialog:
NMaven.Plugin.Loader has encountered a problem and needs to close
Console output:
{code}
[INFO] [NMaven.Plugin.Solution.JavaBinding:Solution]
NMAVEN: Start Process = 12/10/2007 2:35:19 PM
"parameterFile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml" "assemblyFile=C
:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14-mae
stro-1.5-M3__NMaven.Plugins\NMaven.Plugin.Solution.dll" "mojoName=NMaven.Plugin.
Solution.SolutionMojo" "startProcessAssembly=C:\Documents and Settings\wsmoak\.m
2\pab\gac_msil\NMaven.Plugin.Loader\0.14__NMaven.Plugin\NMaven.Pl
ugin.Loader.exe"
NMAVEN: End Process = 12/10/2007 2:35:19 PM
Creating Plugin Domain Manager
ParamFile = C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml, AssemblyFile = C:\
Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14-maest
ro-1.5-M3__NMaven.Plugins\NMaven.Plugin.Solution.dll, MojoName = NMaven.Plugin.S
olution.SolutionMojo
Loading Plugin: C:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.
Solution\0.14__NMaven.Plugins
Creating Plugin Domain Manager
System.String:NMaven.Model.Pom.Model
System.String:System.String
NMaven.Model.Pom.Model:NMaven.Model.Pom.Model
System.String:NMaven.Model.Pom.Model
System.String:System.String
[ERROR]
[ERROR] Unhandled Exception: System.IO.FileNotFoundException: Could not load fil
e or assembly 'NMaven.Solution, Version=0.14.0.0, Culture=neutral, PublicKeyToke
n=null' or one of its dependencies. The system cannot find the file specified.
[ERROR] File name: 'NMaven.Solution, Version=0.14.0.0, Culture=neutral, PublicKe
yToken=null'
[ERROR]at NMaven.Plugin.Solution.SolutionMojo.Execute()
[ERROR]at NMaven.Plugin.AbstractMojo.Execute()
[ERROR]at NMaven.Plugin.Loader.PluginLoader.Main(String[] args)
[ERROR]
[ERROR] WRN: Assembly binding logging is turned OFF.
[ERROR] To enable assembly bind failure logging, set the registry value [HKLM\So
ftware\Microsoft\Fusion!EnableLog] (DWORD) to 1.
[ERROR] Note: There is some performance penalty associated with assembly bind
failure logging.
[ERROR] To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
[ERROR]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] NMAVEN-xxx-000
Embedded error: NMAVEN-063-000: Execution Path = C:\Documents and Settings\wsmoa
k\.m2\pab\gac_msil\NMaven.Plugin.Runner\0.14__NMaven.Plugin, Comm
and = [parameterFile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml, assemblyF
ile=C:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.1
4__NMaven.Plugins\NMaven.Plugin.Solution.dll, mojoName=NMaven.Plu
gin.Solution.SolutionMojo, startProcessAssembly=C:\Documents and Settings\wsmoak
\.m2\pab\gac_msil\NMaven.Plugin.Loader\0.14__NMaven.Plugin\NMaven
.Plugin.Loader.exe]
NMAVEN-040-001: Could not execute: Command = NMaven.Plugin.Runner.exe parameterF
ile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml "assemblyFile=C:\Documents
and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14_
_NMaven.Plugins\NMaven.Plugin.Solution.dll" mojoName=NMaven.Plugin.Solution.Solu
tionMojo "startProcessAssembly=C:\Documents and Settings\wsmoak\.m2\pab\gac_msil
\NMaven.Plugin.Loader\0.14__NMaven.Plugin\NMaven.Plugin.Loader.ex
e", Result = 0
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 24 seconds
[INFO] Finished at: Mon Dec 10 14:36:15 MST 2007
[INFO] Final Memory: 5M/12M
[INFO]
C:\Temp\NMaven.Test>
{code}
was:
To reproduce:
mvn archetype:create -DgroupId=NMaven -DartifactId=NMaven.Test
-DarchetypeArtifactId=maven-archetype-dotnet-simple
-DarchetypeGroupId=org.apache.maven.dotnet
-DarchetypeVersion=0.14-maestro-1.5-M3
cd NMaven.Test
mvn install
mvn clean
mvn org.apache.maven.dotnet.plugins:maven-vsinstaller-plugin:install
mvn NMaven.Plugins:NMaven.Plugin.Solution.JavaBinding:Solution
This results in some build output, then an error/debug dialog:
NMaven.Plugin.Loader has encounte
