[jira] Commented: (MASSEMBLY-54) Unable to filter files while creating assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-54?page=comments#action_56929 ] Corridor Software Developer commented on MASSEMBLY-54: -- agreed, this is an issue when creating distributions for various environments. We're currently working around it by having multiple file sets with the tweaks already in them and a profile per environment to specify which set to grab. Since only 2-4 lines in the files change, this is obviously inefficient, especially when the files need a sweeping change. > Unable to filter files while creating assembly > -- > > Key: MASSEMBLY-54 > URL: http://jira.codehaus.org/browse/MASSEMBLY-54 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.0 > Reporter: Chris Hagmann > Fix For: 2.1 > > > It doesn't seem to be possible to use filtering when creating assemblies. I > have a couple of plain-text files which need to be updated when creating the > assembly (e.g. README.TXT, .version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-483) Setting RUN_AS_USER causes startup script to fail.
[ http://jira.codehaus.org/browse/CONTINUUM-483?page=comments#action_52897 ] Corridor Software Developer commented on CONTINUUM-483: --- I'd like to add for the sake of completeness that I ended with the following command: su - $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE" the -m was causing the root accounts environment to be used instead of my "continuum" user account. While this may by fine in other people's cases, it was causing the path to not include mvn or java since I don't have these defined for the root user. `su - continuum` resolved this. > Setting RUN_AS_USER causes startup script to fail. > -- > > Key: CONTINUUM-483 > URL: http://jira.codehaus.org/browse/CONTINUUM-483 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0.1 > Environment: gentoo 2.6.5 kernel, bash 2.05 > Reporter: Corridor Software Developer > Assignee: Emmanuel Venisse > Fix For: 1.0.2 > > > If the run.sh script is modified to include a RUN_AS_USER, this line in the > script > su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF > wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE" > fails with the following error: > /bin/bash: continuum: No such file or directory > reducing the line yields the same error right down to the 'su -m user_name'. > However, if the -m is moved to beyond the user, everything works out: > su $RUN_AS_USER -m -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF > wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE" > note that it occurs twice in the 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] Commented: (CONTINUUM-410) Assigning a runAs user in the rc script yields "directory does not exist" error.
[ http://jira.codehaus.org/browse/CONTINUUM-410?page=comments#action_52333 ] Corridor Software Developer commented on CONTINUUM-410: --- Yep, it's the best approach. It uses the existing run.sh script with continuum, which operates as an rc script. rc-update add continuum default causes gentoo to start the service on boot. run.sh uses the wrapper. If continuum is run as root, then root would have to be set up to run java and maven 2, which I don't want to add to the path since it's not a development account. > Assigning a runAs user in the rc script yields "directory does not exist" > error. > > > Key: CONTINUUM-410 > URL: http://jira.codehaus.org/browse/CONTINUUM-410 > Project: Continuum > Type: Bug > Versions: 1.0-beta-1 > Environment: gentoo linux > Reporter: Corridor Software Developer > Priority: Critical > Fix For: 1.0.2 > > > Created a symlink to the linux run.sh script in init.d. > Change the runAs to a defined user named continuum > On attempts to run the server, I receive a "directory does not exist" error > at the su -m continuum command. I'll attach the exact debug when I have > the machine available. -- 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: (MEV-6) Broken dependencies for stax
[ http://jira.codehaus.org/browse/MEV-6?page=comments#action_51143 ] Corridor Software Developer commented on MEV-6: --- This dependency doesn't appear to be in the maven 2 repository. The xmlbeans-maven-plugin depends on it because of the stax dependency and this has worked in the past. Was xmlbeans-jsr173-api.jar removed from the maven repo on purpose? > Broken dependencies for stax > > > Key: MEV-6 > URL: http://jira.codehaus.org/browse/MEV-6 > Project: Maven Evangelism > Type: Task > Reporter: Mark Hobson > > > The following: > > xmlbeans-jsr173-api > xmlbeans-jsr173-api > 2.0-dev > > should be: > > xmlbeans > xmlbeans-jsr173-api > 2.0-dev > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-32) Plugin test harness
[ http://jira.codehaus.org/browse/MNG-32?page=comments#action_51141 ] Corridor Software Developer commented on MNG-32: I am Dave. Kenney Westerhof pointed me to the apache maven sandbox for an example test project runner maven-it-plugin used for integration tests: https://svn.apache.org/repos/asf/maven/sandbox/plugins/ Still working on using it with the xmlbeans maven plugin. > Plugin test harness > --- > > Key: MNG-32 > URL: http://jira.codehaus.org/browse/MNG-32 > Project: Maven 2 > Type: Task > Reporter: Jason van Zyl > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1485) 503 Error downloading geronimo:geronimo-j2ee 1.0-M5 pom
503 Error downloading geronimo:geronimo-j2ee 1.0-M5 pom --- Key: MNG-1485 URL: http://jira.codehaus.org/browse/MNG-1485 Project: Maven 2 Type: Bug Environment: ibiblio Reporter: Corridor Software Developer Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/1.3.33 Server at www.ibiblio.org Port 80 This on attempting to download the geronimo j2ee pom. http://www.ibiblio.org/maven2/geronimo/geronimo-j2ee/1.0-M5/geronimo-j2ee-1.0-M5.pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1453) Exception error messages and i18n
Exception error messages and i18n - Key: MNG-1453 URL: http://jira.codehaus.org/browse/MNG-1453 Project: Maven 2 Type: Improvement Components: maven-core Versions: 2.0 Environment: all Reporter: Corridor Software Developer Fix For: 2.1 Augment the exceptions thrown by components and plugins with a methodology supporting internationlization (i18n) of error messages. The framework would promote the use of readily translatable error message tables by deprecating the use of the standard new Exception(message:String). Each exception thrown by a plugin or component would have a code wrapped in an error object for easy use. A JUnit test object would be available to extend by component developers to immediately check for missing exception strings. For a working example, look to the xmlbeans-maven-plugin in the codohaus subversion repository. A patch will be attached for a single component for review, followed by a comprehensive patch of the core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-410) Assigning a runAs user in the rc script yields "directory does not exist" error.
Assigning a runAs user in the rc script yields "directory does not exist" error. Key: CONTINUUM-410 URL: http://jira.codehaus.org/browse/CONTINUUM-410 Project: Continuum Type: Bug Components: continuum-cli Versions: 1.0-beta-1 Environment: gentoo linux Reporter: Corridor Software Developer Priority: Critical Created a symlink to the linux run.sh script in init.d. Change the runAs to a defined user named continuum On attempts to run the server, I receive a "directory does not exist" error at the su -m continuum command. I'll attach the exact debug when I have the machine available. -- 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-1178) weird junit classloader issue
[ http://jira.codehaus.org/browse/MNG-1178?page=all ] Corridor Software Developer updated MNG-1178: - Attachment: mng-1178-1.tar.gz I am receiving the same exception under the following conditions: - Revision: 326303 - Consistently caused with `mvn tomcat:deploy` on the attached project. You won't be able to build it since one of the dependencies required to create the failure is another internal project. Included the build debug output in the attachment instead so you can see the outcome. > weird junit classloader issue > - > > Key: MNG-1178 > URL: http://jira.codehaus.org/browse/MNG-1178 > Project: Maven 2 > Type: Bug > Environment: java 1.5, linux > Reporter: Matthew Pocock > Assignee: Brett Porter > Fix For: 2.0.1 > Attachments: mng-1178-1.tar.gz > > > In some cases (that I've not narrowed down), I get this exception when doing > m2 install. The affected projects have no test cases and no dependencies taht > use JUnit in any way. i can get rid of this exceptino if Junit is added as a > test scope dependency. It smells like a class loader issue where something > funkey is going on to make the no-args constructor of UnitTest unavailable > for chaining from BatteryAssert. Beats me. > org.apache.maven.plugin.MojoExecutionException: Error executing surefire > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:294) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:419) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:599) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:326) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:152) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:237) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:251) > 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: java.lang.reflect.InvocationTargetException > 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.surefire.SurefireBooter.run(SurefireBooter.java:104) > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:289) > ... 16 more > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:274) > at org.codehaus.surefire.Surefire.run(Surefire.java:82) > at org.codehaus.surefire.Surefire.run(Surefire.java:76) > ... 22 more > Caused by: java.lang.IllegalAccessError: tried to access method > junit.framework.TestCase.()V from class > org.codehaus.surefire.battery.assertion.BatteryAssert > at > org.codehaus.surefire.battery.assertion.BatteryAssert.(BatteryAssert.java:23) > at > org.codehaus.surefire.battery.AbstractBattery.(AbstractBattery.java:31) > at > org.codehaus.surefire.battery.DirectoryBattery.(DirectoryBattery.java:39) > ... 29 more -- 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-1178) weird junit classloader issue
[ http://jira.codehaus.org/browse/MNG-1178?page=comments#action_48814 ] Corridor Software Developer commented on MNG-1178: -- The problem seems to stem from having a dependency on junit 3.7 in a subproject. Fabrizio, I'm assuming the junit dep you added to work around the problem was for version 3.8.1? > weird junit classloader issue > - > > Key: MNG-1178 > URL: http://jira.codehaus.org/browse/MNG-1178 > Project: Maven 2 > Type: Bug > Environment: java 1.5, linux > Reporter: Matthew Pocock > Assignee: Brett Porter > Fix For: 2.0.1 > Attachments: mng-1178-1.tar.gz > > > In some cases (that I've not narrowed down), I get this exception when doing > m2 install. The affected projects have no test cases and no dependencies taht > use JUnit in any way. i can get rid of this exceptino if Junit is added as a > test scope dependency. It smells like a class loader issue where something > funkey is going on to make the no-args constructor of UnitTest unavailable > for chaining from BatteryAssert. Beats me. > org.apache.maven.plugin.MojoExecutionException: Error executing surefire > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:294) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:419) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:599) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:326) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:152) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:237) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:251) > 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: java.lang.reflect.InvocationTargetException > 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.surefire.SurefireBooter.run(SurefireBooter.java:104) > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:289) > ... 16 more > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:274) > at org.codehaus.surefire.Surefire.run(Surefire.java:82) > at org.codehaus.surefire.Surefire.run(Surefire.java:76) > ... 22 more > Caused by: java.lang.IllegalAccessError: tried to access method > junit.framework.TestCase.()V from class > org.codehaus.surefire.battery.assertion.BatteryAssert > at > org.codehaus.surefire.battery.assertion.BatteryAssert.(BatteryAssert.java:23) > at > org.codehaus.surefire.battery.AbstractBattery.(AbstractBattery.java:31) > at > org.codehaus.surefire.battery.DirectoryBattery.(DirectoryBattery.java:39) > ... 29 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1235) NPE In DiagnosisUtils while using tomcat plugin
NPE In DiagnosisUtils while using tomcat plugin --- Key: MNG-1235 URL: http://jira.codehaus.org/browse/MNG-1235 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 (RC) Environment: gentoo linux, jdk 1.4.2_06 Reporter: Corridor Software Developer null pointer exception occurs as following when executing `m2 tomcat:deploy`: java.lang.NullPointerException at org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique(DiagnosisUtils.java:89) at org.apache.maven.usability.MojoExecutionExceptionDiagnoser.diagnose(MojoExecutionExceptionDiagnoser.java:66) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:81) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:693) at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:640) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:119) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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:324) 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) I'll add a test project shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1130) Support jar signing.
[ http://jira.codehaus.org/browse/MNG-1130?page=comments#action_48549 ] Corridor Software Developer commented on MNG-1130: -- https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/netbeans-freeform-maven-plugin/ is a better example. Demonstrates tests with multiple test projects. > Support jar signing. > > > Key: MNG-1130 > URL: http://jira.codehaus.org/browse/MNG-1130 > Project: Maven 2 > Type: New Feature > Components: maven-jar-plugin > Versions: 2.0-beta-3 > Environment: gentoo linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: mng-1130.tar.gz > > > The Java webstart framework requires that jars used by a webstart application > be signed. > Create a new goal on the maven jar plugin called jar:sign. The goal would > take a keystore file as input and sign the project artifact prior to > installing it to the local repository or deploying it to the repo. > The plugin should also allow a specific dependency or dependencies, as well > as it's runtime dependencies to be signed. > This functionality is required prior to finishing the webstart-maven-plugin. > Two example test projects will be attached to the ticket shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1130) Support jar signing.
[ http://jira.codehaus.org/browse/MNG-1130?page=comments#action_48547 ] Corridor Software Developer commented on MNG-1130: -- The jpox plugin on the mojo site has an example of an automated unit test. Check it out of svn: https://svn.codehaus.org/mojo/trunk/mojo/jpox-maven-plugin/ and look under src/test/java and src/test/projects. My assumption is that the test projects I attached to the ticket would reside under src/test/projects and could be called from a JUnit test in src/test/java. JpoxEnhancerMojoTest shows how to do this. Trygve knows of another good source as well, but I've since forgotten which project it was. > Support jar signing. > > > Key: MNG-1130 > URL: http://jira.codehaus.org/browse/MNG-1130 > Project: Maven 2 > Type: New Feature > Components: maven-jar-plugin > Versions: 2.0-beta-3 > Environment: gentoo linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: mng-1130.tar.gz > > > The Java webstart framework requires that jars used by a webstart application > be signed. > Create a new goal on the maven jar plugin called jar:sign. The goal would > take a keystore file as input and sign the project artifact prior to > installing it to the local repository or deploying it to the repo. > The plugin should also allow a specific dependency or dependencies, as well > as it's runtime dependencies to be signed. > This functionality is required prior to finishing the webstart-maven-plugin. > Two example test projects will be attached to the ticket shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1130) Support jar signing.
[ http://jira.codehaus.org/browse/MNG-1130?page=comments#action_48541 ]
Corridor Software Developer commented on MNG-1130:
--
Suggested Answers:
1) JarSignMojo is a good name.
2) Putting the signed jar at
${project.build.directory}/signed/${project.build.finalName}.jar seems the
most appropriate place. I would make this the default.
3) I'd let the jar signer check it's own parameters, but anything added
as a result of wrapping it with m2 ought to be checked. But no need to
double check something the jar signer validates unless the error message
is too obscure.
4) You should definately detect and fail if the jarsigner attempts to
prompt for password input. At the very least for the first beta you should
require a password so the scenario doesn't exist. Quietly hanging the
build won't go over very well :)
> Support jar signing.
>
>
> Key: MNG-1130
> URL: http://jira.codehaus.org/browse/MNG-1130
> Project: Maven 2
> Type: New Feature
> Components: maven-jar-plugin
> Versions: 2.0-beta-3
> Environment: gentoo linux, jdk 1.4.2_06
> Reporter: Corridor Software Developer
> Attachments: mng-1130.tar.gz
>
>
> The Java webstart framework requires that jars used by a webstart application
> be signed.
> Create a new goal on the maven jar plugin called jar:sign. The goal would
> take a keystore file as input and sign the project artifact prior to
> installing it to the local repository or deploying it to the repo.
> The plugin should also allow a specific dependency or dependencies, as well
> as it's runtime dependencies to be signed.
> This functionality is required prior to finishing the webstart-maven-plugin.
> Two example test projects will be attached to the ticket shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1130) Support jar signing.
[ http://jira.codehaus.org/browse/MNG-1130?page=comments#action_48513 ] Corridor Software Developer commented on MNG-1130: -- Brought them over from the keystore settings properties of the maven 1 jnlp plugin. I thought it was a little strange since you use them when creating a keystore with the keytool, not actual signing. If they don't make sense to have, then feel free to discard them. The format of the configuration, where the goal is located, etc are all flexible at this point. > Support jar signing. > > > Key: MNG-1130 > URL: http://jira.codehaus.org/browse/MNG-1130 > Project: Maven 2 > Type: New Feature > Components: maven-jar-plugin > Versions: 2.0-beta-3 > Environment: gentoo linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: mng-1130.tar.gz > > > The Java webstart framework requires that jars used by a webstart application > be signed. > Create a new goal on the maven jar plugin called jar:sign. The goal would > take a keystore file as input and sign the project artifact prior to > installing it to the local repository or deploying it to the repo. > The plugin should also allow a specific dependency or dependencies, as well > as it's runtime dependencies to be signed. > This functionality is required prior to finishing the webstart-maven-plugin. > Two example test projects will be attached to the ticket shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1130) Support jar signing.
[ http://jira.codehaus.org/browse/MNG-1130?page=all ] Corridor Software Developer updated MNG-1130: - Attachment: mng-1130.tar.gz rough ideas of how plugin configurations would appear. > Support jar signing. > > > Key: MNG-1130 > URL: http://jira.codehaus.org/browse/MNG-1130 > Project: Maven 2 > Type: New Feature > Components: maven-jar-plugin > Versions: 2.0-beta-3 > Environment: gentoo linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: mng-1130.tar.gz > > > The Java webstart framework requires that jars used by a webstart application > be signed. > Create a new goal on the maven jar plugin called jar:sign. The goal would > take a keystore file as input and sign the project artifact prior to > installing it to the local repository or deploying it to the repo. > The plugin should also allow a specific dependency or dependencies, as well > as it's runtime dependencies to be signed. > This functionality is required prior to finishing the webstart-maven-plugin. > Two example test projects will be attached to the ticket shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1130) Support jar signing.
Support jar signing. Key: MNG-1130 URL: http://jira.codehaus.org/browse/MNG-1130 Project: Maven 2 Type: New Feature Components: maven-jar-plugin Versions: 2.0-beta-3 Environment: gentoo linux, jdk 1.4.2_06 Reporter: Corridor Software Developer The Java webstart framework requires that jars used by a webstart application be signed. Create a new goal on the maven jar plugin called jar:sign. The goal would take a keystore file as input and sign the project artifact prior to installing it to the local repository or deploying it to the repo. The plugin should also allow a specific dependency or dependencies, as well as it's runtime dependencies to be signed. This functionality is required prior to finishing the webstart-maven-plugin. Two example test projects will be attached to the ticket shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1091) Reformat the autogenerated goal parameters page to improve readibility.
Reformat the autogenerated goal parameters page to improve readibility. --- Key: MNG-1091 URL: http://jira.codehaus.org/browse/MNG-1091 Project: Maven 2 Type: Improvement Components: maven-plugin-plugin Versions: 2.0-beta-3 Environment: any, jdk 1.4.2_06 Reporter: Corridor Software Developer Priority: Minor The goal plugin:xdoc creates a table describing the parameters for a plugin. An example may be found here: http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html In the example, notice that the nowrap on the type, expression and default-value columns causes the descriptions to be crammed into the right side of the page. So rather than having these values in their own columns, position them in rows below the parameter as is done in the maven-model documentation for the project descriptor. This way the fields don't compete for space across the page: http://maven.apache.org/maven2/maven-model/maven.html What's more, the inclusion of hyperlinked xml at the top of the page describing the configuration section of the plugin would benefit the end user without manual effort of the plugin developer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1044) @requiresDependencyResolution compile doesn't set plugin artifact file.
[ http://jira.codehaus.org/browse/MNG-1044?page=comments#action_47431 ] Corridor Software Developer commented on MNG-1044: -- Test project and code fix are in svn now. Running src/test/projects/mojo-54 ought to yield the warnings described now. > @requiresDependencyResolution compile doesn't set plugin artifact file. > --- > > Key: MNG-1044 > URL: http://jira.codehaus.org/browse/MNG-1044 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-beta-2 > Environment: gentoo linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Fix For: 2.0-beta-3 > > > setting @requiresDependencyResolution compile does not set the file for at > least one of the artifacts returned from project.getPluginArtifacts(). > To demonstrate, the maven-xmlbeans-plugin will soon have a test project > called MOJO-54. Building the plugin and running the testcase causes the > following warning to be displayed: > [WARNING] The xml bean plugin artifact file was null. > [WARNING] You must explicitly add the plugin dependencies to your project to > successfully compile. > This occurs when the getFile() call returns null. If the problem is resolved > the warning will go away. Grep the XmlBeansPlugin.java file for this ticket > number to find getClasspath() and where this warning originates from. > Note: I'll add an additional comment when the test project and code fix for > MOJO-54 are committed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1044) @requiresDependencyResolution compile doesn't set plugin artifact file.
@requiresDependencyResolution compile doesn't set plugin artifact file. --- Key: MNG-1044 URL: http://jira.codehaus.org/browse/MNG-1044 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-beta-2 Environment: gentoo linux, jdk 1.4.2_06 Reporter: Corridor Software Developer setting @requiresDependencyResolution compile does not set the file for at least one of the artifacts returned from project.getPluginArtifacts(). To demonstrate, the maven-xmlbeans-plugin will soon have a test project called MOJO-54. Building the plugin and running the testcase causes the following warning to be displayed: [WARNING] The xml bean plugin artifact file was null. [WARNING] You must explicitly add the plugin dependencies to your project to successfully compile. This occurs when the getFile() call returns null. If the problem is resolved the warning will go away. Grep the XmlBeansPlugin.java file for this ticket number to find getClasspath() and where this warning originates from. Note: I'll add an additional comment when the test project and code fix for MOJO-54 are committed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1009) Is it possible for all plugins to suport a common goal that causes the plugin to describe itself, its goals and its properties?
[ http://jira.codehaus.org/browse/MNG-1009?page=comments#action_47024 ] Corridor Software Developer commented on MNG-1009: -- m2 plugin:xdoc site:site generates an xdoc which is then rolled into the site. > Is it possible for all plugins to suport a common goal that causes the plugin > to describe itself, its goals and its properties? > --- > > Key: MNG-1009 > URL: http://jira.codehaus.org/browse/MNG-1009 > Project: Maven 2 > Type: Improvement > Components: maven-plugin-api > Reporter: John Allen > > > Would it be sensical (not to mention possible) to have all plugins suport a > common goal that causes the plugin to describe itself, its goals and its > properties? Java annotations could be employed to enable this to described by > the plugin author (i.e. bean style properties would have to be annotaed as > plugin properties, same for goals) and then this annoted information could be > programmatically accessed without the external resources such as generated > docs or hand written description files. There is the language issue mind you > but use of standard message catalogs should sort that > Anyway just an idea :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-910) Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates the plugin's fields.
[ http://jira.codehaus.org/browse/MNG-910?page=comments#action_46619 ] Corridor Software Developer commented on MNG-910: - outdated 1.0 snapshot, I believe it was maven-xdoclet-plugin-1.0-20050615.091250-3.jar or maven-xdoclet-plugin-1.0-20050813.152803-4.jar. Recall per our conversation earlier today [yesterday depending on tz] that I updated and the problem went away. Trygve, fair enough. Help me out, what project is org.codehaus.plexus.component.configurator.converters.ComponentValueSetter in? I would have just submitted a patch has I resolved the artifact & svn tree. > Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates > the plugin's fields. > > > Key: MNG-910 > URL: http://jira.codehaus.org/browse/MNG-910 > Project: Maven 2 > Type: Bug > Components: maven-plugin-api > Versions: 2.0-beta-1 > Environment: Gentoo Linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: TestcaseNPE.txt, testCase.tar.gz > > > The attached pom.xml reliably causes an NullPointerException (stacktrace also > attached) by attempting to describe the use of the xdoclet plugin. Issue > occurs even with little or no configuration in the actual plugin. > End of Stacktrace: > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.(ComponentValueSetter.java:65) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:112) > at > org.codehaus.plexus.component.configurator.OverrideComponentConfigurator.configureComponent(OverrideComponentConfigurator.java:41) > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1014) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:515) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:330) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-910) Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates the plugin's fields.
[ http://jira.codehaus.org/browse/MNG-910?page=all ] Corridor Software Developer closed MNG-910: --- Resolution: Won't Fix environment issue. please disregard. > Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates > the plugin's fields. > > > Key: MNG-910 > URL: http://jira.codehaus.org/browse/MNG-910 > Project: Maven 2 > Type: Bug > Components: maven-plugin-api > Versions: 2.0-beta-1 > Environment: Gentoo Linux, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Attachments: TestcaseNPE.txt, testCase.tar.gz > > > The attached pom.xml reliably causes an NullPointerException (stacktrace also > attached) by attempting to describe the use of the xdoclet plugin. Issue > occurs even with little or no configuration in the actual plugin. > End of Stacktrace: > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.(ComponentValueSetter.java:65) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:112) > at > org.codehaus.plexus.component.configurator.OverrideComponentConfigurator.configureComponent(OverrideComponentConfigurator.java:41) > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1014) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:515) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:330) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-910) Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates the plugin's fields.
Plugin descriptor in pom.xml causes NPE when DefaultPluginManager populates the plugin's fields. Key: MNG-910 URL: http://jira.codehaus.org/browse/MNG-910 Project: Maven 2 Type: Bug Components: maven-plugin-api Versions: 2.0-beta-1 Environment: Gentoo Linux, jdk 1.4.2_06 Reporter: Corridor Software Developer Attachments: TestcaseNPE.txt, testCase.tar.gz The attached pom.xml reliably causes an NullPointerException (stacktrace also attached) by attempting to describe the use of the xdoclet plugin. Issue occurs even with little or no configuration in the actual plugin. End of Stacktrace: java.lang.NullPointerException at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.(ComponentValueSetter.java:65) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:112) at org.codehaus.plexus.component.configurator.OverrideComponentConfigurator.configureComponent(OverrideComponentConfigurator.java:41) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1014) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:515) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:330) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-643) Support and for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ] Corridor Software Developer updated MNG-643: Attachment: FilterCriteriaForCompilerPlugin.patch The last conversation put the configuration of this functionality as such: org.apache.maven.plugins maven-compiler-plugin 2.0-beta-1-SNAPSHOT **/package/**/*.java **/package2/**/*.java **/*Test.java **/*Test.java **/*NoTest.java This patch update corresponds to this format and accomodates trygvis' commit to support compiler types which produce a single output file. Note that the implementation attribute is necessary to keep the Mojo from treating include, exclude, etc. as object names. > Support and for the source and testSource directories. > > > Key: MNG-643 > URL: http://jira.codehaus.org/browse/MNG-643 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: jdk 1.4.x, gentoo linux > Reporter: Corridor Software Developer > Assignee: John Casey > Fix For: 2.0-beta-1 > Attachments: FilterCriteriaForCompilerPlugin.patch, > FilterCriteriaForCompilerPlugin.patch, FilterCriteriaForCompilerPlugin.patch > > Original Estimate: 1 week > Remaining: 1 week > > m2 currently supports FileSets in and which allow > for the inclusion and exclusion of files based on a pattern. > Users may benefit from having this functionality in the source and testSource > directory definitions as well. Here are some scenarios: > 1) a volative package of java files may be excluded from a build to permit > developers to continue building the other source files without having to > delete or resolve issues for the problem files. > 2) Source files and test source files may be kept in the same source tree in > the same manner that resources and testResources may currently be kept in a > single directory. > 3) The change will allow for a parent pom.xml which applies a custom plugin > against all source files for subprojects (modules) and subprojects which only > compile subsets of these files to all point at the same directory. > 4) Some development environments keep their source files in a single > directory regardless of the deployment breakout. One reason is it isn't > always obvious which artifact a particular source file is located in and > consolidation eliminates the need to look around. > 5) Elegant way of continuing to maintain Maven's one project one source set > mantra in a multi-project environment without increasing the number of source > directories. > In an effort to avoid breaking the existing pom format, the following tags > would be supported: > ../../src/java > xor > > ../../src/java > >**/package/*.java > > >**/*Test.java > > > and > ../../src/java > xor > > ../../src/java > >**/*Test.java > > > This issue is NOT endorsing the support of multiple source directories. It > would simply be possible to exclude some source files from the single > directory. > The change creates a path for deprecating the existing format later if > desired. > The change would not break existing pom.xml files. > If a patch is not included with this issue, expect one soon. This f(x) is a > blocker for our development environment because we have several critical > tools which traverse all source files in a company project, not just a single > artifact's files. So either support for multiple source directories by a > parent project (ugh!) or filters on a single directory is a must have. I am > currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-643) Support and for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=comments#action_44765 ] Corridor Software Developer commented on MNG-643: - Dan Tran: Assuming the generated-source directory is added to the source path for the compile goal, then yes, the filter will apply to the generated source files as well. I need to update this patch once more per a discussion with Brett regarding the layout of the configuration items. He'd prefer to consolidate the configuration with includes, excludes, testIncludes, and testExcludes. The updated format is on my other computer but I'll post it with the new patch code. > Support and for the source and testSource directories. > > > Key: MNG-643 > URL: http://jira.codehaus.org/browse/MNG-643 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: jdk 1.4.x, gentoo linux > Reporter: Corridor Software Developer > Assignee: John Casey > Fix For: 2.0-beta-1 > Attachments: FilterCriteriaForCompilerPlugin.patch, > FilterCriteriaForCompilerPlugin.patch > > Original Estimate: 1 week > Remaining: 1 week > > m2 currently supports FileSets in and which allow > for the inclusion and exclusion of files based on a pattern. > Users may benefit from having this functionality in the source and testSource > directory definitions as well. Here are some scenarios: > 1) a volative package of java files may be excluded from a build to permit > developers to continue building the other source files without having to > delete or resolve issues for the problem files. > 2) Source files and test source files may be kept in the same source tree in > the same manner that resources and testResources may currently be kept in a > single directory. > 3) The change will allow for a parent pom.xml which applies a custom plugin > against all source files for subprojects (modules) and subprojects which only > compile subsets of these files to all point at the same directory. > 4) Some development environments keep their source files in a single > directory regardless of the deployment breakout. One reason is it isn't > always obvious which artifact a particular source file is located in and > consolidation eliminates the need to look around. > 5) Elegant way of continuing to maintain Maven's one project one source set > mantra in a multi-project environment without increasing the number of source > directories. > In an effort to avoid breaking the existing pom format, the following tags > would be supported: > ../../src/java > xor > > ../../src/java > >**/package/*.java > > >**/*Test.java > > > and > ../../src/java > xor > > ../../src/java > >**/*Test.java > > > This issue is NOT endorsing the support of multiple source directories. It > would simply be possible to exclude some source files from the single > directory. > The change creates a path for deprecating the existing format later if > desired. > The change would not break existing pom.xml files. > If a patch is not included with this issue, expect one soon. This f(x) is a > blocker for our development environment because we have several critical > tools which traverse all source files in a company project, not just a single > artifact's files. So either support for multiple source directories by a > parent project (ugh!) or filters on a single directory is a must have. I am > currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-744) Create and maintain an M2 implementation of a maven webstart (JNLP) plugin.
[ http://jira.codehaus.org/browse/MNG-744?page=comments#action_44593 ] Corridor Software Developer commented on MNG-744: - Adding my name to the Confluence Maven Plugin Matrix to indicate that the plugin is being developed. > Create and maintain an M2 implementation of a maven webstart (JNLP) plugin. > --- > > Key: MNG-744 > URL: http://jira.codehaus.org/browse/MNG-744 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: n/a > Reporter: Corridor Software Developer > Priority: Minor > > Original Estimate: 2 weeks > Remaining: 2 weeks > > I am finding a need for an M2 plugin which may be used to extend a Java > Webapp project to include other projects' jar artifacts as Java Webstart > applications, include Sun's suggested JNLP servlet and library resolution > implementations and update the web.xml file accordingly. > * This plugin would only be usable on a project which produces a webapp. > * The plugin would rely on the existing dependency management f(x) to include > those jars which contain the action client side application code. > * Multiple applications would be deployable in a single webapp. > * The web deployment descriptor would be updated so the user would have to > expend minimal effort to get a webstart application to work properly. > * The plugin would produce a jnlp descriptor which properly refers to the > client side app's library dependencies by version. > I'll update the Plugin Matrix to indicate that this plugin is being > developed, and will attach the plugin to this ticket when it is completed and > tested. Also interested in maintaining it for the foreseeable future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-744) Create and maintain an M2 implementation of a maven webstart (JNLP) plugin.
Create and maintain an M2 implementation of a maven webstart (JNLP) plugin. --- Key: MNG-744 URL: http://jira.codehaus.org/browse/MNG-744 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-alpha-3 Environment: n/a Reporter: Corridor Software Developer Priority: Minor I am finding a need for an M2 plugin which may be used to extend a Java Webapp project to include other projects' jar artifacts as Java Webstart applications, include Sun's suggested JNLP servlet and library resolution implementations and update the web.xml file accordingly. * This plugin would only be usable on a project which produces a webapp. * The plugin would rely on the existing dependency management f(x) to include those jars which contain the action client side application code. * Multiple applications would be deployable in a single webapp. * The web deployment descriptor would be updated so the user would have to expend minimal effort to get a webstart application to work properly. * The plugin would produce a jnlp descriptor which properly refers to the client side app's library dependencies by version. I'll update the Plugin Matrix to indicate that this plugin is being developed, and will attach the plugin to this ticket when it is completed and tested. Also interested in maintaining it for the foreseeable future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MNG-631) Update the Apache XML Beans plugin based on latest changes to plugin API & 1.x releases.
[ http://jira.codehaus.org/browse/MNG-631?page=all ] Corridor Software Developer resolved MNG-631: - Resolution: Fixed Fix Version: (was: 2.0-beta-1) Code changes committed to the mojo repository. Maven Plugin Matrix updated as well. > Update the Apache XML Beans plugin based on latest changes to plugin API & > 1.x releases. > > > Key: MNG-631 > URL: http://jira.codehaus.org/browse/MNG-631 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: n/a > Reporter: Corridor Software Developer > Attachments: maven-xmlbeans-plugin.tar.gz > > > Apache XML Beans is an xml schema compiler which produces a framework for > loading xml into java class objects. The attached zip is an update to the xml > beans plugin for the current m2 api. > The plugin has been tested but unit test cases are still being developed > based on the Apache site's xml beans tutorial for consistency. It seemed more > important to test against a few projects first and release it quickly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MNG-700) Update Maven Plugin Matrix to reflect availability of maven XML Beans Plugin.
[ http://jira.codehaus.org/browse/MNG-700?page=all ] Corridor Software Developer resolved MNG-700: - Resolution: Fixed Updated the plugin matrix to reflect the code update. > Update Maven Plugin Matrix to reflect availability of maven XML Beans Plugin. > - > > Key: MNG-700 > URL: http://jira.codehaus.org/browse/MNG-700 > Project: Maven 2 > Type: Improvement > Components: documentation > Environment: n/a > Reporter: Corridor Software Developer > Priority: Minor > > > The XML Beans plugin code has been committed to the codehaus repo. Once it's > available in the ibiblio repo the Maven Plugin Matrix should be updated to > reflect its release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-700) Update Maven Plugin Matrix to reflect availability of maven XML Beans Plugin.
Update Maven Plugin Matrix to reflect availability of maven XML Beans Plugin. - Key: MNG-700 URL: http://jira.codehaus.org/browse/MNG-700 Project: Maven 2 Type: Improvement Components: documentation Environment: n/a Reporter: Corridor Software Developer Priority: Minor The XML Beans plugin code has been committed to the codehaus repo. Once it's available in the ibiblio repo the Maven Plugin Matrix should be updated to reflect its release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-631) Update the Apache XML Beans plugin based on latest changes to plugin API & 1.x releases.
[ http://jira.codehaus.org/browse/MNG-631?page=comments#action_43952 ] Corridor Software Developer commented on MNG-631: - Rather than resubmitting as a tarball, the code has been committed to the codehaus mojo svn repo. > Update the Apache XML Beans plugin based on latest changes to plugin API & > 1.x releases. > > > Key: MNG-631 > URL: http://jira.codehaus.org/browse/MNG-631 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: n/a > Reporter: Corridor Software Developer > Fix For: 2.0-beta-1 > Attachments: maven-xmlbeans-plugin.tar.gz > > > Apache XML Beans is an xml schema compiler which produces a framework for > loading xml into java class objects. The attached zip is an update to the xml > beans plugin for the current m2 api. > The plugin has been tested but unit test cases are still being developed > based on the Apache site's xml beans tutorial for consistency. It seemed more > important to test against a few projects first and release it quickly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-631) Update the Apache XML Beans plugin based on latest changes to plugin API & 1.x releases.
[ http://jira.codehaus.org/browse/MNG-631?page=comments#action_43482 ] Corridor Software Developer commented on MNG-631: - Answers: 1) CodedException is an extension of MojoExecutionException which consolidates all of the error messages of the plugin into a resouce set. When you guys head down the i18n road, it will make locale support easy via additional resource bundles. But for now, it helps me make my error messages more consistent. Supports message format field replacement, root exceptions, etc. I am still considering writing an article about handling exceptions this way since I've never seen anyone do it like this and it helps to promote better error message creation. 2) Deal. I'll make changes to follow the guidelines and resubmit the tarball. > Update the Apache XML Beans plugin based on latest changes to plugin API & > 1.x releases. > > > Key: MNG-631 > URL: http://jira.codehaus.org/browse/MNG-631 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: n/a > Reporter: Corridor Software Developer > Fix For: 2.0-beta-1 > Attachments: maven-xmlbeans-plugin.tar.gz > > > Apache XML Beans is an xml schema compiler which produces a framework for > loading xml into java class objects. The attached zip is an update to the xml > beans plugin for the current m2 api. > The plugin has been tested but unit test cases are still being developed > based on the Apache site's xml beans tutorial for consistency. It seemed more > important to test against a few projects first and release it quickly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-643) Support and for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ] Corridor Software Developer updated MNG-643: Attachment: FilterCriteriaForCompilerPlugin.patch Testing revealed that assuming empty filters meant compile everything was wrong. Updated to construct a StaleScanner with no filter sets if none were defined in the configuration. Otherwise, if only the exclude is defined, make the include **/*.java. Replaces previous patch. > Support and for the source and testSource directories. > > > Key: MNG-643 > URL: http://jira.codehaus.org/browse/MNG-643 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: jdk 1.4.x, gentoo linux > Reporter: Corridor Software Developer > Fix For: 2.0-beta-2 > Attachments: FilterCriteriaForCompilerPlugin.patch, > FilterCriteriaForCompilerPlugin.patch > > Original Estimate: 1 week > Remaining: 1 week > > m2 currently supports FileSets in and which allow > for the inclusion and exclusion of files based on a pattern. > Users may benefit from having this functionality in the source and testSource > directory definitions as well. Here are some scenarios: > 1) a volative package of java files may be excluded from a build to permit > developers to continue building the other source files without having to > delete or resolve issues for the problem files. > 2) Source files and test source files may be kept in the same source tree in > the same manner that resources and testResources may currently be kept in a > single directory. > 3) The change will allow for a parent pom.xml which applies a custom plugin > against all source files for subprojects (modules) and subprojects which only > compile subsets of these files to all point at the same directory. > 4) Some development environments keep their source files in a single > directory regardless of the deployment breakout. One reason is it isn't > always obvious which artifact a particular source file is located in and > consolidation eliminates the need to look around. > 5) Elegant way of continuing to maintain Maven's one project one source set > mantra in a multi-project environment without increasing the number of source > directories. > In an effort to avoid breaking the existing pom format, the following tags > would be supported: > ../../src/java > xor > > ../../src/java > >**/package/*.java > > >**/*Test.java > > > and > ../../src/java > xor > > ../../src/java > >**/*Test.java > > > This issue is NOT endorsing the support of multiple source directories. It > would simply be possible to exclude some source files from the single > directory. > The change creates a path for deprecating the existing format later if > desired. > The change would not break existing pom.xml files. > If a patch is not included with this issue, expect one soon. This f(x) is a > blocker for our development environment because we have several critical > tools which traverse all source files in a company project, not just a single > artifact's files. So either support for multiple source directories by a > parent project (ugh!) or filters on a single directory is a must have. I am > currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-643) Support and for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ] Corridor Software Developer updated MNG-643: Attachment: FilterCriteriaForCompilerPlugin.patch That's very reasonable. This patch is an implementation of that idea. The compiler plugin filters may be set as follows: org.apache.maven.plugins maven-compiler-plugin 2.0-alpha-3 compile compile **/*Bean.java testCompile testCompile **/*Test.java The implementation="java.lang.String" attribute is hokey, but I needed it because it was otherwise looking to instantiate an Include.class object, which doesn't exist. If you know of an alternative, please let me know and I'll update the patch accordingly. > Support and for the source and testSource directories. > > > Key: MNG-643 > URL: http://jira.codehaus.org/browse/MNG-643 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: jdk 1.4.x, gentoo linux > Reporter: Corridor Software Developer > Fix For: 2.0-beta-2 > Attachments: FilterCriteriaForCompilerPlugin.patch > > Original Estimate: 1 week > Remaining: 1 week > > m2 currently supports FileSets in and which allow > for the inclusion and exclusion of files based on a pattern. > Users may benefit from having this functionality in the source and testSource > directory definitions as well. Here are some scenarios: > 1) a volative package of java files may be excluded from a build to permit > developers to continue building the other source files without having to > delete or resolve issues for the problem files. > 2) Source files and test source files may be kept in the same source tree in > the same manner that resources and testResources may currently be kept in a > single directory. > 3) The change will allow for a parent pom.xml which applies a custom plugin > against all source files for subprojects (modules) and subprojects which only > compile subsets of these files to all point at the same directory. > 4) Some development environments keep their source files in a single > directory regardless of the deployment breakout. One reason is it isn't > always obvious which artifact a particular source file is located in and > consolidation eliminates the need to look around. > 5) Elegant way of continuing to maintain Maven's one project one source set > mantra in a multi-project environment without increasing the number of source > directories. > In an effort to avoid breaking the existing pom format, the following tags > would be supported: > ../../src/java > xor > > ../../src/java > >**/package/*.java > > >**/*Test.java > > > and > ../../src/java > xor > > ../../src/java > >**/*Test.java > > > This issue is NOT endorsing the support of multiple source directories. It > would simply be possible to exclude some source files from the single > directory. > The change creates a path for deprecating the existing format later if > desired. > The change would not break existing pom.xml files. > If a patch is not included with this issue, expect one soon. This f(x) is a > blocker for our development environment because we have several critical > tools which traverse all source files in a company project, not just a single > artifact's files. So either support for multiple source directories by a > parent project (ugh!) or filters on a single directory is a must have. I am > currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-643) Support and for the source and testSource directories.
Support and for the source and testSource directories. Key: MNG-643 URL: http://jira.codehaus.org/browse/MNG-643 Project: Maven 2 Type: Improvement Components: maven-model Versions: 2.0-alpha-3 Environment: jdk 1.4.x, gentoo linux Reporter: Corridor Software Developer Priority: Blocker m2 currently supports FileSets in and which allow for the inclusion and exclusion of files based on a pattern. Users may benefit from having this functionality in the source and testSource directory definitions as well. Here are some scenarios: 1) a volative package of java files may be excluded from a build to permit developers to continue building the other source files without having to delete or resolve issues for the problem files. 2) Source files and test source files may be kept in the same source tree in the same manner that resources and testResources may currently be kept in a single directory. 3) The change will allow for a parent pom.xml which applies a custom plugin against all source files for subprojects (modules) and subprojects which only compile subsets of these files to all point at the same directory. 4) Some development environments keep their source files in a single directory regardless of the deployment breakout. One reason is it isn't always obvious which artifact a particular source file is located in and consolidation eliminates the need to look around. 5) Elegant way of continuing to maintain Maven's one project one source set mantra in a multi-project environment without increasing the number of source directories. In an effort to avoid breaking the existing pom format, the following tags would be supported: ../../src/java xor ../../src/java **/package/*.java **/*Test.java and ../../src/java xor ../../src/java **/*Test.java This issue is NOT endorsing the support of multiple source directories. It would simply be possible to exclude some source files from the single directory. The change creates a path for deprecating the existing format later if desired. The change would not break existing pom.xml files. If a patch is not included with this issue, expect one soon. This f(x) is a blocker for our development environment because we have several critical tools which traverse all source files in a company project, not just a single artifact's files. So either support for multiple source directories by a parent project (ugh!) or filters on a single directory is a must have. I am currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-631) Update the Apache XML Beans plugin based on latest changes to plugin API & 1.x releases.
Update the Apache XML Beans plugin based on latest changes to plugin API & 1.x releases. Key: MNG-631 URL: http://jira.codehaus.org/browse/MNG-631 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Environment: n/a Reporter: Corridor Software Developer Attachments: maven-xmlbeans-plugin.tar.gz Apache XML Beans is an xml schema compiler which produces a framework for loading xml into java class objects. The attached zip is an update to the xml beans plugin for the current m2 api. The plugin has been tested but unit test cases are still being developed based on the Apache site's xml beans tutorial for consistency. It seemed more important to test against a few projects first and release it quickly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-581) Add target/classes director to compiler:compile classpath
[ http://jira.codehaus.org/browse/MNG-581?page=all ] Corridor Software Developer updated MNG-581: Attachment: IncludeOutputInCompilerClasspath.maven-project.patch This patch adds the output directory to the compile classpath in the same manner that it is done for the test classpath. Tested with the xmlbeans plugin development and this resolves the problem. > Add target/classes director to compiler:compile classpath > - > > Key: MNG-581 > URL: http://jira.codehaus.org/browse/MNG-581 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: any OS, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > Attachments: IncludeOutputInCompilerClasspath.maven-project.patch > > > An upcoming plugin called during generate-sources produces class files in the > classes output directory and sources in the generated-sources directory. > While the plugin should be responsible for adding generated-sources to the > compileSourceRoot, it may be worthwhile to have the target classes directory > in the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-581) Add target/classes director to compiler:compile classpath
[ http://jira.codehaus.org/browse/MNG-581?page=comments#action_42732 ] Corridor Software Developer commented on MNG-581: - Someone please check me, but I believe this won't do any good now that I have another look at it. MavenProject.getCompileClasspathElements weeds out any items that aren't jar files. The call to isAddedToClasspath only returns true for jar's, ejb jars and ejb-client jars. As it stands now though, I still need a solution to the following problem: Apache XML Beans produces class files during generate-sources which need to end up on the classpath when the compile step is reached. If they are not jar'ed up, getCompileClasspathElements will not return them in the set. One potential solution is to use the XMLBean compiler's support for producing a jar file, then add this to the MavenProject artifacts list. But for now, I'd like to retract this defect. > Add target/classes director to compiler:compile classpath > - > > Key: MNG-581 > URL: http://jira.codehaus.org/browse/MNG-581 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: any OS, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > > > An upcoming plugin called during generate-sources produces class files in the > classes output directory and sources in the generated-sources directory. > While the plugin should be responsible for adding generated-sources to the > compileSourceRoot, it may be worthwhile to have the target classes directory > in the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-581) Add target/classes director to compiler:compile classpath
Add target/classes director to compiler:compile classpath - Key: MNG-581 URL: http://jira.codehaus.org/browse/MNG-581 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Environment: any OS, jdk 1.4.2_06 Reporter: Corridor Software Developer Priority: Minor An upcoming plugin called during generate-sources produces class files in the classes output directory and sources in the generated-sources directory. While the plugin should be responsible for adding generated-sources to the compileSourceRoot, it may be worthwhile to have the target classes directory in the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-566) Maven Plugin Matrix: XML Beans 2.0 support for m2
Maven Plugin Matrix: XML Beans 2.0 support for m2 - Key: MNG-566 URL: http://jira.codehaus.org/browse/MNG-566 Project: Maven 2 Type: Improvement Components: maven-plugins, documentation Environment: n/a Reporter: Corridor Software Developer Priority: Minor Please add the following entry to the Maven Plugin Matrix: Plugin: Maven XML Beans Plugin Maven 1.x: Yes Maven 2.x: No Author: David Jencks, Brett Porter and Kris Bravo Comments: Maven 2.x support for XML Beans 2.x in progress. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-565) JavadocReport is missing @requiresDependencyResolution compile tag
JavadocReport is missing @requiresDependencyResolution compile tag --- Key: MNG-565 URL: http://jira.codehaus.org/browse/MNG-565 Project: Maven 2 Type: Bug Components: maven-reports Versions: 2.0-alpha-3 Environment: Gentoo Linux, jdk 1.4.2_06 Reporter: Corridor Software Developer Attachments: JavadocReportNPE.patch The org.apache.maven.plugin.javadoc.JavadocReport make a call to MavenProject.getCompileClasspathElements(). This will throw an NPE at first line in the method if dependency resolution isn't set: List list = new ArrayList( getArtifacts().size() );< getArtifacts() returns null here... Adding the @requiresDependencyResolution tag to the class' javadoc causes getArtifacts() to return a valid result. Also, there is a minor grammar error in the exception handling of the executeReport method. A correction is included in this patch as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-564) AbstractMavenReport.execut() exception handling
AbstractMavenReport.execut() exception handling --- Key: MNG-564 URL: http://jira.codehaus.org/browse/MNG-564 Project: Maven 2 Type: Bug Components: maven-reports Versions: 2.0-alpha-3 Environment: gentoo linux, java 1.4.2_06 Reporter: Corridor Software Developer Attachments: MavenReportErrorHandling.patch org.apache.maven.reporting.AbstractMavenReport is catching all Exceptions in it's execute method and only printing the following if one occurs: "An error is occurred in " + getName( locale ) + " report generation." So there is a grammar error "error is occurred" and a loss of useful information, namely the stacktrace of the original error. So please change from throw new MojoExecutionException( "An error is occurred in " + getName( locale ) + " report generation."); to throw new MojoExecutionException( "An error has occurred in " + getName( locale ) + " report generation.", e ); Note that org.apache.maven.plugin.javadoc.JavadocReport has the same grammar error, but that's trivial - it attached the original error's stacktrace. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-556) NPE in MavenProject class
[ http://jira.codehaus.org/browse/MNG-556?page=comments#action_42570 ] Corridor Software Developer commented on MNG-556: - Ran into this as well while developing a plugin, only it was caused by not having @requiresDependencyResolution in the class javadoc. If the patch simply returns an empty Collection, it will quietly fail to return a proper classpath for plugin developers not familiar with this javadoc tag. So I recommend that, if the requiresDependencyResolution flag wasn't set properly, throw the DependencyResolutionRequiredException with a verbose message: "Dependencies have not been resolved. If this is a plugin, verify that @requiresDependencyResolution is set in the mojo object. See the developer's documentation for more detail." If it has been set and their are no artifacts, then an empty Collection would be appropriate. > NPE in MavenProject class > - > > Key: MNG-556 > URL: http://jira.codehaus.org/browse/MNG-556 > Project: Maven 2 > Type: Bug > Components: maven-project > Versions: 2.0-beta-1 > Reporter: Vincent Siveton > Fix For: 2.0-beta-1 > Attachments: mavenproject.patch > > > A NPE could be thrown in some circumstances (ie by the javadoc plugin) in the > MavenProject class. > getArtifacts() could be null. > Lets see the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-417) M2: pom for javax:j2ee:1.4
M2: pom for javax:j2ee:1.4 -- Key: MAVENUPLOAD-417 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-417 Project: maven-upload-requests Type: Improvement Reporter: Corridor Software Developer Attachments: j2ee-1.4.pom Here is a basic pom.xml for the j2ee 1.4 jar file. This is for a sun proprietary library which must be downloaded manually or within an internal maven-proxy , but requires a pom definition nonetheless. The format was taken from the existing poms under javax in ibiblio for consistency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
