[jira] Commented: (MDEP-275) Figuring out duplicate class definitions using the Analyze goal
[ http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233726#action_233726 ] Petter Måhlén commented on MDEP-275: I think Raymond's proposal is superior to mine, so that should probably be the focus for the merge. Figuring out duplicate class definitions using the Analyze goal --- Key: MDEP-275 URL: http://jira.codehaus.org/browse/MDEP-275 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.1 Reporter: Petter Måhlén Assignee: Brian Fox Attachments: dependency-analyzer.diff, dependency-plugin.diff Hi, I've pretty frequently run into issues where changes to the library structure of some product (that is, changing the way that classes are grouped into libraries) leads to the same classes being defined in more than one place. This can lead to system-dependent problems, because different versions of the same class are being loaded by different systems. I was going to create a new goal for the dependency plugin to check for duplicate classes, but when I looked a bit closer at the analyze goal, it already had all the information needed to do that check as well, so I came up with some changes that add this functionality. The intended usage is something like: mvn dependency:analyze -DcheckDuplicateClasses I get the feeling that I might want to add the ability to exclude certain packages (that I might be comfortable are safe to have duplicates of), so I added this option too: mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes=org., net.sf.cglib, javax.xml, junit. The output looks something like: [WARNING] Duplicate class definitions found: [WARNING]com.shopzilla.common.data.ObjectFactory defined in: [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile [WARNING]com.shopzilla.site.category.CategoryProvider defined in: [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile A couple of notes: - I was unable to get configuration (setting checkDuplicateClasses, etc.) using the pom to work, but I think that might be due to lack of understanding on my part. - I don't fully understand the effect of calling compileProject() during unit tests, but I think it may be sufficient to call it only once for the duplicateClasses project, during setUp(). That would speed up the unit tests. - I haven't added duplicate class definition checking to the AnalyzeReportMojo, because I wanted to get some feedback on whether this addition was felt to be valuable before spending any time on that. - A lot of the unit test dummy code in the attached diff files needs cleaning up, but again I wanted to wait with that until hearing whether this might be useful to others. - I made an API change in the ProjectDependencyAnalyzer interface, which might be an issue if there are other implementations than the default one. That change was only needed to support the 'exclude package' feature, which might not be super-important. Cheers, Petter -- 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: (MCOMPILER-130) compilerArgument option doesn't work with maxerrs option, compilerArguments does
[ http://jira.codehaus.org/browse/MCOMPILER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233727#action_233727 ] Per Hedman commented on MCOMPILER-130: -- It's seems like the compiler gets the whole string -Xmaxerrs 1000 as an argument, and not the working version with the argument and value pair of -Xmaxerrs 1000. In the AbstractCompilerMojo there is a line about creating the creation of the commandLine: String[] cl = compiler.createCommandLine( compilerConfiguration ); And then loops through the String Array, but when setting the compilerArgument-Xmaxerrs 1000/compilerArgument the inner content is considered a single argument, and separation between arguments and values are a single space . I think that it's escaping the spaces within the compilerArgument. I have tried compilerArgument-verbose -help/compilerArgument and that gives the same result. This is tested on Mac OS X. compilerArgument option doesn't work with maxerrs option, compilerArguments does Key: MCOMPILER-130 URL: http://jira.codehaus.org/browse/MCOMPILER-130 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: Mac OS X Reporter: Mike Dikan I looked into using this configuration for maven: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration compilerArgument-Xmaxerrs 1000/compilerArgument /configuration /plugin But no dice: Failure executing javac, but could not parse the error: javac: invalid flag: -Xmaxerrs 1000 Usage: javac options source files use -help for a list of possible options On the command line using javac, the maxerrs flag works as expected, and using the compilerArguments Map option works: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration forktrue/fork compilerArguments Xmaxerrs10/Xmaxerrs /compilerArguments /configuration /plugin -- 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: (MWAR-235) The web.xml file included twice into the result war
[ http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233728#action_233728 ] Noam Y. Tenne commented on MWAR-235: I can confirm this too. But it happens only in Windows. When built with Linux, it seems to be fine. The web.xml file included twice into the result war --- Key: MWAR-235 URL: http://jira.codehaus.org/browse/MWAR-235 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1 Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1 Reporter: Siarhei_Yarkavy Priority: Critical Attachments: asmModule.zip, pom.xml, screenshot.jpg Please have a look to the attached demo project and screen-shot -- 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-3814) Reactor builds fail due to erroneous cycle in project sorting which does not consider versions
[
http://jira.codehaus.org/browse/MNG-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233744#action_233744
]
Julien HENRY commented on MNG-3814:
---
If this is fixed maybe could you revert changes done in aggregator POM
maven-plugins.
Reactor builds fail due to erroneous cycle in project sorting which does not
consider versions
--
Key: MNG-3814
URL: http://jira.codehaus.org/browse/MNG-3814
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-3
Just to officially track the reason why the parent POM {{maven-plugins}}
currently excludes the maven-project-info-reports-plugin from the reactor:
{noformat}
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference:
Edge between
'Vertex{label='org.apache.maven.plugins:maven-remote-resources-plugin'}'
and
'Vertex{label='org.apache.maven.plugins:maven-project-info-reports-plugin'}'
introduces to cycle in the graph
org.apache.maven.plugins:maven-project-info-reports-plugin --
org.apache.maven.plugins:maven-remote-resources-plugin --
org.apache.maven.plugins:maven-project-info-reports-plugin
{noformat}
It appears the {{ProjectSorter}} does not take versions into account, i.e.
there is no cycle in a multi-module scenario like this:
{noformat}
parent:1
- plugin-a:2.0 which uses plugin-b:1.0
- plugin-b:2.0 which uses plugin-a:1.0
{noformat}
--
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-3814) Reactor builds fail due to erroneous cycle in project sorting which does not consider versions
[
http://jira.codehaus.org/browse/MNG-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233745#action_233745
]
Benjamin Bentmann commented on MNG-3814:
It's fixed only in M3 and the aggregator POM already has a profile for M3 that
enables all modules.
Reactor builds fail due to erroneous cycle in project sorting which does not
consider versions
--
Key: MNG-3814
URL: http://jira.codehaus.org/browse/MNG-3814
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-3
Just to officially track the reason why the parent POM {{maven-plugins}}
currently excludes the maven-project-info-reports-plugin from the reactor:
{noformat}
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference:
Edge between
'Vertex{label='org.apache.maven.plugins:maven-remote-resources-plugin'}'
and
'Vertex{label='org.apache.maven.plugins:maven-project-info-reports-plugin'}'
introduces to cycle in the graph
org.apache.maven.plugins:maven-project-info-reports-plugin --
org.apache.maven.plugins:maven-remote-resources-plugin --
org.apache.maven.plugins:maven-project-info-reports-plugin
{noformat}
It appears the {{ProjectSorter}} does not take versions into account, i.e.
there is no cycle in a multi-module scenario like this:
{noformat}
parent:1
- plugin-a:2.0 which uses plugin-b:1.0
- plugin-b:2.0 which uses plugin-a:1.0
{noformat}
--
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: (MWAR-235) The web.xml file included twice into the result war
[
http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233747#action_233747
]
Michael Glauche commented on MWAR-235:
--
Having the same problem, web.xml is getting added twice:
{code}
[DEBUG] Dump of the current build pathSet content --
[DEBUG] index.html
[DEBUG] META-INF/MANIFEST.MF
[DEBUG] WEB-INF/faces-config.xml
[DEBUG] WEB-INF/jetty-env.xml
[DEBUG] WEB-INF/web.xml
[DEBUG] -- end of dump --
...
[INFO] Webapp assembled in [921 msecs]
[DEBUG] Excluding [] from the generated webapp archive.
[DEBUG] Including [**] in the generated webapp archive.
[INFO] Building war:
C:\work\workspaces\project\project-web\target\project-web-0.2.0-SNAPSHOT.war
[DEBUG] adding directory META-INF/
[DEBUG] adding entry META-INF/MANIFEST.MF
[DEBUG] adding directory images/
[DEBUG] adding directory includes/
[DEBUG] adding directory pages/
[DEBUG] adding directory styles/
[DEBUG] adding directory WEB-INF/
[DEBUG] adding directory WEB-INF/classes/
...
[DEBUG] adding directory WEB-INF/lib/
[DEBUG] adding entry index.html
[DEBUG] adding entry WEB-INF/classes/application.properties
[DEBUG] adding entry WEB-INF/faces-config.xml
[DEBUG] adding entry WEB-INF/jetty-env.xml
[DEBUG] adding entry WEB-INF/lib/aopalliance-1.0.jar
[DEBUG] adding entry WEB-INF/lib/commons-fileupload-1.2.1.jar
... (many more libs)
[DEBUG] adding entry WEB-INF/web.xml
[DEBUG] adding entry WEB-INF/web.xml
[DEBUG] adding directory META-INF/maven/
...
{code}
Notice the two entries adding web.xml ...
Maven is 2.2.1, Maven-War Plugin is set to 2.1 (when unset, 2.1-alpha2 is used
and everything works)
Java is 1.6.0_20 on win32.
The zip file does contain the same entry twice, in the same directory.
The web.xml file included twice into the result war
---
Key: MWAR-235
URL: http://jira.codehaus.org/browse/MWAR-235
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1
Reporter: Siarhei_Yarkavy
Priority: Critical
Attachments: asmModule.zip, pom.xml, screenshot.jpg
Please have a look to the attached demo project and screen-shot
--
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: (MWAR-235) The web.xml file included twice into the result war
[ http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233755#action_233755 ] Michael Glauche commented on MWAR-235: -- The problem seems that the WarArchiver is using addFile( descr, WEB-INF/web.xml ); But later the WEB-INF lib does get added, too, so the web.xml is twice in the file-list. The web.xml file included twice into the result war --- Key: MWAR-235 URL: http://jira.codehaus.org/browse/MWAR-235 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1 Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1 Reporter: Siarhei_Yarkavy Priority: Critical Attachments: asmModule.zip, pom.xml, screenshot.jpg Please have a look to the attached demo project and screen-shot -- 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: (MWAR-235) The web.xml file included twice into the result war
[ http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Glauche updated MWAR-235: - Attachment: MWAR-235-test.patch Patch for the WarMojoTest to check duplicate files in a jar The web.xml file included twice into the result war --- Key: MWAR-235 URL: http://jira.codehaus.org/browse/MWAR-235 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1 Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1 Reporter: Siarhei_Yarkavy Priority: Critical Attachments: asmModule.zip, MWAR-235-test.patch, pom.xml, screenshot.jpg Please have a look to the attached demo project and screen-shot -- 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: (MWAR-235) The web.xml file included twice into the result war
[
http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233757#action_233757
]
Michael Glauche edited comment on MWAR-235 at 8/31/10 6:50 AM:
---
Patch for the WarMojoTest to check duplicate files in a jar. Now the test does
(correctly) fail like this:
{code}
junit.framework.AssertionFailedError: Duplicate Entry in Jar File:
WEB-INF/web.xml
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertNull(Assert.java:233)
at
org.apache.maven.plugin.war.WarMojoTest.assertJarContent(WarMojoTest.java:400)
at
org.apache.maven.plugin.war.WarMojoTest.testSimpleWar(WarMojoTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
{code}
was (Author: mglauche):
Patch for the WarMojoTest to check duplicate files in a jar
The web.xml file included twice into the result war
---
Key: MWAR-235
URL: http://jira.codehaus.org/browse/MWAR-235
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1
Reporter: Siarhei_Yarkavy
Priority: Critical
Attachments: asmModule.zip, MWAR-235-test.patch, pom.xml,
screenshot.jpg
Please have a look to the attached demo project and screen-shot
--
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-4786) beta-3 : Getting NPE when using an ant-mojo maven plugin
beta-3 : Getting NPE when using an ant-mojo maven plugin Key: MNG-4786 URL: http://jira.codehaus.org/browse/MNG-4786 Project: Maven 2 3 Issue Type: Bug Environment: 3.0-beta-3 (staging) Reporter: Vincent Latombe Attachments: antmojo.zip, NPE.log Testing latest beta-3 available in staging, I get an NPE when calling one of my plugins that use the ant wrapper (described at http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) Here is a sample plugin project that use this feature (I took the one available in Maven book). Compile it, then call mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world -e This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233782#action_233782 ] Javier Diaz commented on MNG-1683: -- We are interested in this ticket and we have tried the solution provided by Pino. We have used succesfully for some time but now we need to add type zip as a dependency for another project. Maven should treat it as a overlay like it does with war type. Is it getting to complex? Does it makes sense? Regards type zip for packaging ? Key: MNG-1683 URL: http://jira.codehaus.org/browse/MNG-1683 Project: Maven 2 3 Issue Type: Improvement Environment: not significant Reporter: Olivier Lamy Fix For: Issues to be reviewed for 3.x Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip Hi, I don't know if the artifact type zip exists (I think not after few test). But I want to separate the html content and the webapp content (classes, configuration files and so on). The use case is to separate this different works (html designer and java developpement) and production installation (one is to an http server and the other is on an app server) in two artifacts with separate versionning. But the packagingzip/packaging is not recognized. Then I would like to use it as an artifact with maven's features (snapshot, pom, version, goals : install, deploy release and all others). Add it to the webapp dependencies (needed only for developpment or unit tests). With this type of dependency the zip content could be unpacked to a directory in the exploded webapp. (certainly need hack on the maven-war-plugin). I have certainly the workaround to declare this as jar and using the assembly plugin to generate a zip. But I can't use install release deploy or something else to manage the generated zip which is not an artifact. Thanks for help or workaround. - Olivier -- 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: (MNG-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233782#action_233782 ] Javier Diaz edited comment on MNG-1683 at 8/31/10 10:15 AM: We are interested in this ticket and we have tried the solution provided by Pino. We have used it succesfully for some time but now we need to add type zip as a dependency for another project but is not possible. We expect that maven treats the dependency as an overlay like it does with war type. Is it getting to complex? Does it makes sense? Regards was (Author: jdiazch): We are interested in this ticket and we have tried the solution provided by Pino. We have used succesfully for some time but now we need to add type zip as a dependency for another project. Maven should treat it as a overlay like it does with war type. Is it getting to complex? Does it makes sense? Regards type zip for packaging ? Key: MNG-1683 URL: http://jira.codehaus.org/browse/MNG-1683 Project: Maven 2 3 Issue Type: Improvement Environment: not significant Reporter: Olivier Lamy Fix For: Issues to be reviewed for 3.x Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip Hi, I don't know if the artifact type zip exists (I think not after few test). But I want to separate the html content and the webapp content (classes, configuration files and so on). The use case is to separate this different works (html designer and java developpement) and production installation (one is to an http server and the other is on an app server) in two artifacts with separate versionning. But the packagingzip/packaging is not recognized. Then I would like to use it as an artifact with maven's features (snapshot, pom, version, goals : install, deploy release and all others). Add it to the webapp dependencies (needed only for developpment or unit tests). With this type of dependency the zip content could be unpacked to a directory in the exploded webapp. (certainly need hack on the maven-war-plugin). I have certainly the workaround to declare this as jar and using the assembly plugin to generate a zip. But I can't use install release deploy or something else to manage the generated zip which is not an artifact. Thanks for help or workaround. - Olivier -- 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: (MANTRUN-149) mvn antrun does not perform task options
mvn antrun does not perform task options
Key: MANTRUN-149
URL: http://jira.codehaus.org/browse/MANTRUN-149
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.4
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_21
OS name: linux version: 2.6.18-194.11.1.el5 arch: amd64 Family: unix
Reporter: Shawn Capron
I am testing antrun for transtioning my companys product from ant to maven, and
have a task thats must be run with ant. To test mvn antrun I created a test
pom.xml that contains:
{quote}
project
modelVersion4.0.0/modelVersion
artifactIdmy-test-app/artifactId
groupIdmy-test-group/groupId
version1.0-SNAPSHOT/version
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idcompile/id
phasecompile/phase
configuration
tasks
property name=compile_classpath
refid=maven.compile.classpath/
property name=runtime_classpath
refid=maven.runtime.classpath/
property name=test_classpath refid=maven.test.classpath/
property name=plugin_classpath
refid=maven.plugin.classpath/
echo message=compile classpath: ${compile_classpath}/
echo message=runtime classpath: ${runtime_classpath}/
echo message=test classpath:${test_classpath}/
echo message=plugin classpath: ${plugin_classpath}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
{quote}
Then at the command line, I type in mvn antrun:run and the output I get is this:
{quote}
scap...@altair:/home/scapron/antrun_test% mvn antrun:run
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - my-test-group:my-test-app:jar:1.0-SNAPSHOT
[INFO]task-segment: [antrun:run]
[INFO]
[INFO] [antrun:run {execution: default-cli}]
project.artifactId
[INFO] Executing tasks
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Aug 31 12:19:02 EDT 2010
[INFO] Final Memory: 9M/303M
[INFO]
scap...@altair:/home/scapron/antrun_test%
{quote}
It doesn't seem to matter what I place in the tasks, it does not get executed.
--
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-4786) beta-3 : Getting NPE when using an ant-mojo maven plugin
[
http://jira.codehaus.org/browse/MNG-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233792#action_233792
]
Benjamin Bentmann commented on MNG-4786:
NPE is caused by not injected logger, only affects plugins using
{{maven-script-ant:2.1.0}} and newer.
beta-3 : Getting NPE when using an ant-mojo maven plugin
Key: MNG-4786
URL: http://jira.codehaus.org/browse/MNG-4786
Project: Maven 2 3
Issue Type: Bug
Environment: 3.0-beta-3 (staging)
Reporter: Vincent Latombe
Attachments: antmojo.zip, NPE.log
Testing latest beta-3 available in staging, I get an NPE when calling one of
my plugins that use the ant wrapper (described at
http://www.sonatype.com/books/mhandbook/reference/ch04s04.html)
Here is a sample plugin project that use this feature (I took the one
available in Maven book).
Compile it, then call
mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world
-e
This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs)
--
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-4786) [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE
[ http://jira.codehaus.org/browse/MNG-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4786: --- Summary: [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE (was: beta-3 : Getting NPE when using an ant-mojo maven plugin) [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE --- Key: MNG-4786 URL: http://jira.codehaus.org/browse/MNG-4786 Project: Maven 2 3 Issue Type: Bug Environment: 3.0-beta-3 (staging) Reporter: Vincent Latombe Attachments: antmojo.zip, NPE.log Testing latest beta-3 available in staging, I get an NPE when calling one of my plugins that use the ant wrapper (described at http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) Here is a sample plugin project that use this feature (I took the one available in Maven book). Compile it, then call mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world -e This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- 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-149) mvn antrun does not perform task options
[
http://jira.codehaus.org/browse/MANTRUN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANTRUN-149.
-
Resolution: Not A Bug
Assignee: Benjamin Bentmann
Please see [Guide to Configuring
Plug-ins|http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Configuring_Build_Plugins],
in particular the last paragraph of the linked section, and [Guide to
Configuring Default Mojo
Executions|http://maven.apache.org/guides/mini/guide-default-execution-ids.html].
Configuration for direct CLI invocations either have to be placed directly
inside the {{plugin}} block or use the special id {{default-cli}}.
mvn antrun does not perform task options
Key: MANTRUN-149
URL: http://jira.codehaus.org/browse/MANTRUN-149
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.4
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_21
OS name: linux version: 2.6.18-194.11.1.el5 arch: amd64 Family: unix
Reporter: Shawn Capron
Assignee: Benjamin Bentmann
I am testing antrun for transtioning my companys product from ant to maven,
and have a task thats must be run with ant. To test mvn antrun I created a
test pom.xml that contains:
{quote}
project
modelVersion4.0.0/modelVersion
artifactIdmy-test-app/artifactId
groupIdmy-test-group/groupId
version1.0-SNAPSHOT/version
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idcompile/id
phasecompile/phase
configuration
tasks
property name=compile_classpath
refid=maven.compile.classpath/
property name=runtime_classpath
refid=maven.runtime.classpath/
property name=test_classpath refid=maven.test.classpath/
property name=plugin_classpath
refid=maven.plugin.classpath/
echo message=compile classpath: ${compile_classpath}/
echo message=runtime classpath: ${runtime_classpath}/
echo message=test classpath:${test_classpath}/
echo message=plugin classpath: ${plugin_classpath}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
{quote}
Then at the command line, I type in mvn antrun:run and the output I get is
this:
{quote}
scap...@altair:/home/scapron/antrun_test% mvn antrun:run
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - my-test-group:my-test-app:jar:1.0-SNAPSHOT
[INFO]task-segment: [antrun:run]
[INFO]
[INFO] [antrun:run {execution: default-cli}]
project.artifactId
[INFO] Executing tasks
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Aug 31 12:19:02 EDT 2010
[INFO] Final Memory: 9M/303M
[INFO]
scap...@altair:/home/scapron/antrun_test%
{quote}
It doesn't seem to matter what I place in the tasks, it does not get executed.
--
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-4786) [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE
[ http://jira.codehaus.org/browse/MNG-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233795#action_233795 ] Stuart McCulloch commented on MNG-4786: --- Fixed in spice-inject-plexus-1.3.4.1 (r2845) ... the issue was that objects created from non-java component factories weren't being processed properly. [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE --- Key: MNG-4786 URL: http://jira.codehaus.org/browse/MNG-4786 Project: Maven 2 3 Issue Type: Bug Environment: 3.0-beta-3 (staging) Reporter: Vincent Latombe Attachments: antmojo.zip, NPE.log Testing latest beta-3 available in staging, I get an NPE when calling one of my plugins that use the ant wrapper (described at http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) Here is a sample plugin project that use this feature (I took the one available in Maven book). Compile it, then call mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world -e This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- 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-2066) Specify multiple proxies
[ http://jira.codehaus.org/browse/MNG-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233796#action_233796 ] David Smiley commented on MNG-2066: --- I'm shocked so perhaps I'm misunderstanding things. I work in an enterprise environment with an HTTP proxy server used for both http (80), https (443), and FTP. The title of this JIRA issue suggests a use-case involving multiple proxies but I'm really talking about one proxy server. Java allows me to specify an appropriate proxy configuration for my situation on the command line when I invoke a Java command. Maven is built on Java so I'd think Maven would support this. Yet is Jason basically saying that Maven doesn't support a single proxy server being used for both http and https? What's unusual about that? http://download.oracle.com/javase/6/docs/technotes/guides/net/proxies.html And by the way I am using a maven repo manager but it's corporate wide (and I work for a large corporation) and I'm not about to request it mirror a repo that exists for exactly one project. By the way, the external repo happens to be an svn repository that exists for a project I'm collaborating on with an external party, just between us. It's a convenient way for me to use Maven to keep artifacts that aren't available broadly. Specify multiple proxies Key: MNG-2066 URL: http://jira.codehaus.org/browse/MNG-2066 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Thomas Recloux Attachments: MNG-2066-maven-site.patch, MNG-2066-maven.patch, multiple-proxies-paches.zip After this discussion : http://www.mail-archive.com/d...@maven.apache.org/msg53099.html In the attached zip file, you'll find four patch files : - on the maven-artifact-manager projet : changes in the DefaultWagonManager class, using the http proxy when no https proxy is specified. - on the maven-core project : changes in the DefaultMaven, adding all teh active proxies from the settings to the wagon manager - on the maven-settings project : changes in the settings.mdo file Theses patches are built on the maven-2.0.x branch. -- 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: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233802#action_233802 ] Dale Wyttenbach commented on MECLIPSE-94: - @KP: Here's a scenario for you: You are fixing an issue which requires modifying your project's parent pom, in order to update the dependency management section with a later version of some open source package that you use. You want the change to the parent pom to be part of the same change set that the rest of the bug fix is in. So you want the parent pom.xml to be visible to Team-Synchronize operation, etc. Allow eclipse:eclipse to work on pom (and other) projects - Key: MECLIPSE-94 URL: http://jira.codehaus.org/browse/MECLIPSE-94 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Felipe Leme Attachments: MECLIPSE-94.patch I'm creating a Java EE project based on the m2book (which I was reviewing; it's not available yet...) and one of the projects is a pom-packaging project used for integration tests. According to Vincent, currently this project must be a pom (in fact, I tried to set it as jar, but then the test phase would be run anyway, which would cause the tests to fail), as it doesn't produces a jar. But as it has java files (on the src/main/it/java directory), I tried to call eclipse:eclipse but it fails, saying that Not running eclipse plugin goal for pom project. For these scenarios, I think a propery would be enough. At first I thought something about a 'force' or 'forceGeneration' property, would enough, which the code change being from: if ( pom.equals( packaging ) eclipseProjectDir == null ) to: if ( pom.equals( packaging ) eclipseProjectDir == null !forceGeneration ) Then I realized there is other place where the pom nature is checked: if ( pom.equals( packaging ) eclipseProjectDir == null !forceGeneration ) So, I think a better name for the property would be 'javaProject' and the change would be: final boolean isJavaProjectProperty = // read property; defaults to false... if ( pom.equals( packaging ) eclipseProjectDir == null !isJavaProjectProperty ) isJavaProject = isJavaProjectProperty || !ear.equals( packaging ) !pom.equals( packaging ); If nobody objects and someone is willing to apply the changes, I can provide such patch (with the proper test cases). -- Felipe PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features already existed :-) -- 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-2803) org/slf4j/slf4j-android directory has wrong permissions
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233814#action_233814 ] Ceki Gulcu commented on MAVENUPLOAD-2803: - Just to be clear, the central repository nightly synchronizes with our rysync server, pixie.qos.ch, in relation with the org.slf4j groupId. org/slf4j/slf4j-android directory has wrong permissions Key: MAVENUPLOAD-2803 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2803 Project: Maven Upload Requests Issue Type: Wish Reporter: Ceki Gulcu Due to a file permission issue the org/sfl4j/slf4j-android folder was not properly synchronized in the maven central repo. The problem was solved on our end. However, http://repo1.maven.org/maven2/org/slf4j/slf4j-android/ still returns 403 forbidden. Could you either remove the corresponding directory or set its permissions so that it is readable, with the latter option being preferable? Many thanks in advance, -- 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-2804) Sync org.patterntesting repository
Sync org.patterntesting repository -- Key: MAVENUPLOAD-2804 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2804 Project: Maven Upload Requests Issue Type: Task Reporter: Oliver Boehm Attachments: org.patterntesting.sh Please synchronize http://patterntesting.sourceforge.net/m2/repository/ to the central maven repository. (http://jira.codehaus.org/browse/MAVENUPLOAD-1911 is obsolete now) -- 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-1911) Sync sf.net.patterntesting repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Boehm closed MAVENUPLOAD-1911. - Resolution: Fixed replaced by http://jira.codehaus.org/browse/MAVENUPLOAD-2804 Sync sf.net.patterntesting repository - Key: MAVENUPLOAD-1911 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1911 Project: Maven Upload Requests Issue Type: Task Reporter: Oliver Boehm Attachments: net.sf.patterntesting.sh Please synchronize http://patterntesting.sourceforge.net/m2/repository/ to the central maven 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] Closed: (MNG-4786) [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE
[ http://jira.codehaus.org/browse/MNG-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4786. -- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Benjamin Bentmann Fixed in [r991314|http://svn.apache.org/viewvc?view=revisionrevision=991314], thanks Stuart! [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE --- Key: MNG-4786 URL: http://jira.codehaus.org/browse/MNG-4786 Project: Maven 2 3 Issue Type: Bug Environment: 3.0-beta-3 (staging) Reporter: Vincent Latombe Assignee: Benjamin Bentmann Fix For: 3.0-beta-4 Attachments: antmojo.zip, NPE.log Testing latest beta-3 available in staging, I get an NPE when calling one of my plugins that use the ant wrapper (described at http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) Here is a sample plugin project that use this feature (I took the one available in Maven book). Compile it, then call mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world -e This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- 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: (WAGON-257) java.lang.ArrayIndexOutOfBoundsException: 0 when deploying via scp
[ http://jira.codehaus.org/browse/WAGON-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233819#action_233819 ] Esnault Frederic commented on WAGON-257: Could you check your id_rsa private key? Make sure it's only made of the first and ending lines with ONLY the key in between : -BEGIN RSA PRIVATE KEY- BljdivnlmkVCLJvxdkvxjKxdv(...)dfvdfv -END RSA PRIVATE KEY- For example, this key is wrong for Jsch (used by maven) (see the Proc-Type and DEK-Info headers, remove them and the empty line): -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,0AB406BADE9247B3 BljdivnlmkVCLJvxdkvxjKxdv(...)dfvdfv -END RSA PRIVATE KEY- java.lang.ArrayIndexOutOfBoundsException: 0 when deploying via scp -- Key: WAGON-257 URL: http://jira.codehaus.org/browse/WAGON-257 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-5 Environment: Mac OS X 10.4 Reporter: Thomas Vandahl Fix For: 1.0 (Not sure about the version of wagon, I am using Maven 2.1.0 release) When I try to deploy something that is supposed to use scp as the protocol, for example mvn site:deploy, I get the following exception ---8--- [INFO] [site:deploy] Using private key: /xxx/.ssh/id_rsa scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ - Session: Connection refused scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ - Session: Disconnecting scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: java.lang.ArrayIndexOutOfBoundsException: 0 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:215) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: java.lang.ArrayIndexOutOfBoundsException: 0 at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnectionInternal(AbstractJschWagon.java:137) at org.apache.maven.wagon.AbstractWagon.openConnection(AbstractWagon.java:105) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:207) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:142) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) ... 18 more Caused by: com.jcraft.jsch.JSchException: java.lang.ArrayIndexOutOfBoundsException:
[jira] Created: (MNG-4787) Allow class realm manager delegates to alter public part of Maven core realm
Allow class realm manager delegates to alter public part of Maven core realm Key: MNG-4787 URL: http://jira.codehaus.org/browse/MNG-4787 Project: Maven 2 3 Issue Type: Improvement Components: Class Loading Affects Versions: 3.0-beta-2 Reporter: Benjamin Bentmann Priority: Minor As part of the fix for MNG-4747, a new class realm was introduced that represents the public part of the Maven core. Life for integrators that need to contribute additional classes like Polyglot Maven or M2Eclipse would be easier if this realm is also subject to the class realm delegates. This would allow to inject the custom types at a central place rather than injecting them into each and every plugin realm. -- 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: (MNG-4787) Allow class realm manager delegates to alter public part of Maven core realm
[ http://jira.codehaus.org/browse/MNG-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4787. -- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Benjamin Bentmann Done in [r991347|http://svn.apache.org/viewvc?view=revisionrevision=991347]. Allow class realm manager delegates to alter public part of Maven core realm Key: MNG-4787 URL: http://jira.codehaus.org/browse/MNG-4787 Project: Maven 2 3 Issue Type: Improvement Components: Class Loading Affects Versions: 3.0-beta-2 Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Priority: Minor Fix For: 3.0-beta-4 As part of the fix for MNG-4747, a new class realm was introduced that represents the public part of the Maven core. Life for integrators that need to contribute additional classes like Polyglot Maven or M2Eclipse would be easier if this realm is also subject to the class realm delegates. This would allow to inject the custom types at a central place rather than injecting them into each and every plugin realm. -- 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: (MINSTALL-77) Checksum / timestamp check to allow install to assume previous successful completion
Checksum / timestamp check to allow install to assume previous successful completion Key: MINSTALL-77 URL: http://jira.codehaus.org/browse/MINSTALL-77 Project: Maven 2.x Install Plugin Issue Type: Improvement Components: install:install Environment: Windows Reporter: Brien Wheeler We have a large structured project with lots of components and artifacts (takes about 10 minutes to run mvn install from top of project). When doing refactoring and rebuilding from clean working pool, we will occasionally get through 7 or 8 minutes of building and have something at the end of the dependency tree fail. After fixing the affected artifact, we have two options -- try to suss out what was not yet built and manually do those in appropriate order, or re-run mvn install from the project root. Obviously manually trying to complete the mvn install is error prone. Rerunning mvn install from the root takes a long time because even though it can skip compilation on all the previously built artifacts, it still re-runs the tests and re-packages and re-installs to the local repository. It would be great if mvn install checked the target directory, determined that its target existed in the working pool, checked that no dependencies (source files, resource files, test files, dependency artifacts) had newer timestamps and assumed that the target artifact was up to date. Then it could skip all compilation, test, packaging steps. It could check MD5 checksum against the local repository to determine whether the local file copy was needed (although it would be very odd that the test and packaging was all up to date but the actual file copy wasn't performed). -- 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
