[jira] Created: (MNG-2356) Add timing information to integration tests
Add timing information to integration tests --- Key: MNG-2356 URL: http://jira.codehaus.org/browse/MNG-2356 Project: Maven 2 Type: Improvement Components: integration tests Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Trivial Attachments: MNG-2356.diff Also document why using your installed maven to recompile this plugin is a bad 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
[jira] Created: (MNG-2357) misc cleanup
misc cleanup Key: MNG-2357 URL: http://jira.codehaus.org/browse/MNG-2357 Project: Maven 2 Type: Improvement Versions: 2.1 Reporter: Jerome Lacoste Priority: Trivial Attachments: MNG-2357.diff small things including - a little bit of doc for integration tests - document 2 undocumented integration tests - svn:ignore -- 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: (MCHANGES-40) Documentation of changes plugin should be improved
Documentation of changes plugin should be improved -- Key: MCHANGES-40 URL: http://jira.codehaus.org/browse/MCHANGES-40 Project: Maven 2.x Changes Plugin Type: Improvement Reporter: Wim Deblauwe There is no documentation on the possible configuration things you can do with the changes plugin (http://maven.apache.org/plugins/maven-changes-plugin/howto.html). Also when clicking on the JIRA sample report, you suddenly go a different site, this is quite confusing. One thing that especially needs documentation is changing the location of changes.xml. There are quite a few people (MCHANGES-22, MCHANGES-3), who want to change it to src/site/changes/changes.xml in stead of the default src/changes/changes.xml. It reduces the clutter in the src directory, and since the changes.xml is used in the site, it is more locigal to me to have in the alternate location in stead of the default. -- 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: (MASSEMBLY-114) DirectoryInlineMojo but without it being an aggregator
DirectoryInlineMojo but without it being an aggregator -- Key: MASSEMBLY-114 URL: http://jira.codehaus.org/browse/MASSEMBLY-114 Project: Maven 2.x Assembly Plugin Type: New Feature Versions: 2.1 Reporter: Ron Tomlinson Priority: Minor Attachments: DirectoryInlineSingleMojo.java I have been using the maven 2 assembly plugin recently and required the use of the org.apache.maven.plugin.assembly.DirectoryInlineMojo but without it being an aggregator (to get around the maven multi-project issues). I had a go at doing this, and it works for me. I have attached the java source. -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=all ] Karel Vervaeke updated MCOMPILER-22: Attachment: MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Type: Bug > Reporter: Matthew Beermann > Priority: Critical > Fix For: 2.0.2 > Attachments: MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > 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: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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 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] Updated: (MNG-2352) Upgrade to plexus-container-default-alpha-10
[ http://jira.codehaus.org/browse/MNG-2352?page=all ] Jerome Lacoste updated MNG-2352: Attachment: MNG-2352.diff > Upgrade to plexus-container-default-alpha-10 > > > Key: MNG-2352 > URL: http://jira.codehaus.org/browse/MNG-2352 > Project: Maven 2 > Type: Improvement > Reporter: Jerome Lacoste > Priority: Blocker > Attachments: MNG-2352.diff > > > This is required for MNG-2201 in particular. -- 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-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=all ] Jerome Lacoste updated MNG-2293: Attachment: MNG-2293.diff > maven-plugin-descriptor: Not possible to define a default implementation for > a field defined by its interface > - > > Key: MNG-2293 > URL: http://jira.codehaus.org/browse/MNG-2293 > Project: Maven 2 > Type: New Feature > Components: Plugin Creation Tools > Versions: 2.0.4 > Reporter: Jerome Lacoste > Priority: Critical > Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, > dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, > patch-MNG-2293.diff > > > MOJO-393 is about letting the user define an alternate configuration element, > thus changing the way the webstart plugin works. > For that the idea was to make the mojo field an interface, provide a default > implementation in the plugin and let the user use plexus to instanciate a new > implemenation. > so for most users we would have: > > > > > and for some: > > > > > Unfortunately, today I am forced to specify the implementation in both cases. > There's no way to inform the plugin to use the default implementation. > The plugin.xml contains: > > bla > ...BlaInterface >... > > I tried to use > /[EMAIL PROTECTED] implementation="...BlaImplementation"*/ > BlaInterface bla; > but that fails as well. > Marking critical because it doesn't allow me add new features to the plugin > without breaking the config.xml. -- 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-45) add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
[ http://jira.codehaus.org/browse/MWAR-45?page=comments#action_67021 ]
Torgeir Lorange Østby commented on MWAR-45:
---
Would it be better if classesArchiveName defaults to ${project.build.finalName}
and then have an additional parameter/flag which triggers the feature? I guess
{code:xml}
${project.build.finalName}
{code}
would give the same result, but it is not that intuitive that this is what
actually makes the plugin behave differently.
> add config prop to specify webapp classes should be zipped and placed into
> WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
> -
>
> Key: MWAR-45
> URL: http://jira.codehaus.org/browse/MWAR-45
> Project: Maven 2.x War Plugin
> Type: New Feature
> Versions: 2.0
> Reporter: Ian Springer
> Assignee: Jason van Zyl
> Attachments: mwar-45.patch
>
>
> I think this is a common enough practice that there should be an option
> provided for it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-68) Cleaning snapshots when perform a release
[ http://jira.codehaus.org/browse/MRELEASE-68?page=all ] Olivier Lamy closed MRELEASE-68: Resolution: Won't Fix I close it. In fact, now I think it's a bad idea ;-). Because some other projects can depends on the SNAPSHOT version. And they can't be build if SNAPSHOTS removed. Maybe maven-repository will have a good feature for this. -- Olivier > Cleaning snapshots when perform a release > - > > Key: MRELEASE-68 > URL: http://jira.codehaus.org/browse/MRELEASE-68 > Project: Maven 2.x Release Plugin > Type: New Feature > Environment: all > Reporter: Olivier Lamy > > > It could a nice feature about cleaning repository when performing release > (maybe optionnal in the mojo configuration) > Sample, when performing a release on a version called 1.0-SNAPSHOT. > all 1.0-SNAPSHOT directories could be deleted. In the remote repository > included all wagons protocols. -- 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: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
[ http://jira.codehaus.org/browse/MSUREFIRE-131?page=all ]
Philip Gerlach updated MSUREFIRE-131:
-
Attachment: commons-events-pom.xml
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: MSUREFIRE-131
> URL: http://jira.codehaus.org/browse/MSUREFIRE-131
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.2
> Reporter: Philip Gerlach
> Attachments: commons-events-pom.xml, maven-surefire-junit-trunk-412516.patch
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
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: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_67025 ] Balaji Ravi commented on SUREFIRE-46: - Hi olivier, I understand there are other workarounds from the users perspective & that is what i am doing currently, but why shouldn't it be fixed in the future release of surefire... Also, it is not just the repository having spaces but any project shouldn't have spaces in their directory names. My main point is if we can fix it in the source, then it would require no tweaking in the user side... - Balaji > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: SurefirebugTest.java, pom.xml, pom.xml, surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
[ http://jira.codehaus.org/browse/MSUREFIRE-131?page=comments#action_67029
]
Philip Gerlach commented on MSUREFIRE-131:
--
@Bryce
I checked out commons-events from
http://svn.apache.org/repos/asf/jakarta/commons/dormant/events/trunk and
created a POM that I attached to the issue where I included the
"AllTestSuite.java" as the only JUnitTest and it works as it is supposed to
work with 310 tests run and 2 failures.
I'm not sure but perhaps your problem results from a typing mistake because
you've included the test "AllTestsSuite.java" while the correct name of the
file is "AllTestSuite.java" without the 's'.
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: MSUREFIRE-131
> URL: http://jira.codehaus.org/browse/MSUREFIRE-131
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.2
> Reporter: Philip Gerlach
> Attachments: commons-events-pom.xml, maven-surefire-junit-trunk-412516.patch
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
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: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[ http://jira.codehaus.org/browse/MRELEASE-91?page=all ] Olivier Lamy updated MRELEASE-91: - Attachment: changes.xml rewriting-dev-phase.apt MRELEASE-91.patch-2 > Updating of dependencyManagement inconsistent with updating of dependencies > with regard to SNAPSHOTs > > > Key: MRELEASE-91 > URL: http://jira.codehaus.org/browse/MRELEASE-91 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: maven 2.0.4, win XP > Reporter: Marcel Schutte > Assignee: Brett Porter > Fix For: 2.0-beta-4 > Attachments: MRELEASE-91.patch, MRELEASE-91.patch-2, changes.xml, > depmgnt.zip, release.patch, rewriting-dev-phase.apt, > snapshots-reactor-in-dependencies.tar, > snapshots-reactor-in-dependency-management.tar > > > The mechanism in release:prepare for creating the new development version of > POM's handles snapshots that are part of the current reactor build > differently for dependencyManagement and for dependencies. > A snapshot version in a dependencies section will be updated to the next > development version whereas one in dependencyManagement won't. > The attached patch will change this behavior. It will update a snapshot > version under dependencyManagement if and only if it is part of the current > reactor build. > Note that dependencies cannot contain snapshot versions that are not part of > the current reactor, but dependencyManagement can. I suggest to forbid this > too. > A second suggestion is to introduce a parameter to control the updating of > snapshot dependencies in both dependencyManagement and dependencies sections. > Either leave them at the released version or update them to the new > development version. This touches on the discussion in MRELEASE-36 about the > developer having to knowingly choose to use a new development version. I > would be fine with using a parameter to select the behavior as obtained with > my patch. My central point is that dependencyManagement and dependencies > snapshots should behave the same. -- 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-45) add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
[ http://jira.codehaus.org/browse/MWAR-45?page=comments#action_67041 ] Ian Springer commented on MWAR-45: -- +1 to Torgeir's suggestion. I think having a boolean parameter for enabling the option is more intuitive. > add config prop to specify webapp classes should be zipped and placed into > WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ > - > > Key: MWAR-45 > URL: http://jira.codehaus.org/browse/MWAR-45 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Ian Springer > Assignee: Jason van Zyl > Attachments: mwar-45.patch > > > I think this is a common enough practice that there should be an option > provided for it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-46) EJB-client libraries are added with wrong extension
[ http://jira.codehaus.org/browse/MWAR-46?page=comments#action_67043 ] Xavier Dury commented on MWAR-46: - maven-war-plugin 2.0-beta-2 was handling ejb-clients correctly but since 2.0 final, ejb-client don't have the right extension (the bug showed up somewhere between the 2 versions) until it is fixed I'll be using client instead of ejb-client but I hope it'll be fixed very soon. > EJB-client libraries are added with wrong extension > --- > > Key: MWAR-46 > URL: http://jira.codehaus.org/browse/MWAR-46 > Project: Maven 2.x War Plugin > Type: Bug > Versions: 2.0 > Reporter: Joerg Schaible > Priority: Blocker > > > If a war has a dependency to an ejb client library, this library is added to > META-INF/lib as artifactId.ejb-client. Such artifacts are not added to the > classpath by all app servers e.g. like WebLogic 8.1. The dependency must be > added as artifactId-ejb-client.jar. -- 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: (MVERIFIER-1) Verify that all dependencies are available in one of the remote repositories
Verify that all dependencies are available in one of the remote repositories Key: MVERIFIER-1 URL: http://jira.codehaus.org/browse/MVERIFIER-1 Project: Maven 2.x Verifier Plugin Type: New Feature Reporter: Geoffrey De Smet One problem I 've encountered a few times now is that everything builds locally on my pc but team mates can't build because my local repository differs from theirs. For example, I am working on 2 different projects A & B, each with it's own internal remote repo. The internal repo of A contains the ejb3 jar, but the other repo (the one of B) doesn't. When I created an indirect dependency on the ejb3 jar in the B project, it works locally because I 've already downloaded it for the project A. My team mates who are only working on project B, can't build and then send me angry e-mails :) It would be very nice that "mvn verify" verified that all dependencies are available in on of the pom defined (+ central) remote repositories. -- 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-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_67047 ] Scott McLachlan commented on CONTINUUM-725: --- issue 587. I'm using 1.03 and cannot retrieve my project in subversion with the following URL https:username:[EMAIL PROTECTED]/svn/sample/trunk/pom.xml I get the following error message: jvm 1 | 2006-06-08 15:23:01,054 [SocketListener0-0] INFO ContinuumProjectBuilder:maven-two-builder - Downloading https://my.server.com/svn/sample/trunk/proficio/pom.xml jvm 1 | 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Created 0 projects. jvm 1 | 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Created 0 project groups. jvm 1 | 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - 1 warnings. jvm 1 | 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Could not download https://my.server.com/svn/sample/trunk/proficio/pom.xml: Server returned HTTP response code: 401 for URL: https://my.server.com/svn/sample/trunk/proficio/pom.xml As I stated the username:password is valid. I can use the same information if I create an ANT project. I cannot create a M2 project because it isn't accepting the authenticated URL. > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 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
[jira] Closed: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=all ] Kenney Westerhof closed MNG-2293: - Assign To: Kenney Westerhof Resolution: Fixed Fix Version: 2.1 Reviewed the latest patch and ran a complete bootstrap to verify integration tests. As far as I can see it does NOT depend on MNG-2352. Committed in revision 413054. > maven-plugin-descriptor: Not possible to define a default implementation for > a field defined by its interface > - > > Key: MNG-2293 > URL: http://jira.codehaus.org/browse/MNG-2293 > Project: Maven 2 > Type: New Feature > Components: Plugin Creation Tools > Versions: 2.0.4 > Reporter: Jerome Lacoste > Assignee: Kenney Westerhof > Priority: Critical > Fix For: 2.1 > Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, > dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, > patch-MNG-2293.diff > > > MOJO-393 is about letting the user define an alternate configuration element, > thus changing the way the webstart plugin works. > For that the idea was to make the mojo field an interface, provide a default > implementation in the plugin and let the user use plexus to instanciate a new > implemenation. > so for most users we would have: > > > > > and for some: > > > > > Unfortunately, today I am forced to specify the implementation in both cases. > There's no way to inform the plugin to use the default implementation. > The plugin.xml contains: > > bla > ...BlaInterface >... > > I tried to use > /[EMAIL PROTECTED] implementation="...BlaImplementation"*/ > BlaInterface bla; > but that fails as well. > Marking critical because it doesn't allow me add new features to the plugin > without breaking the config.xml. -- 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-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_67050 ] Karel Vervaeke commented on MCOMPILER-22: - Oops, I messed up. The file named MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch should be called MNG-MCCOMPILER-22-maven-compiler-plugin-noformatting.patch > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Type: Bug > Reporter: Matthew Beermann > Priority: Critical > Fix For: 2.0.2 > Attachments: MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > 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: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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 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: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=comments#action_67052 ] Al Robertson commented on MWAR-21: -- I am surprised this is marked as fixed. I don't believe it is. Here is a structure that J2EE requires you to support ear jar1 war ->manifest classpath:jar1 jar2 war depends on jar1 and jar2 Currently, you can specify to add a manifest classpath entry. This adds an entry for each dependency that is not "Provided", because provided means "provided by the container". (CORRECT) In the above example, I can't configure maven to exclude jar1 from the war/WEB-INF/lib dir but include it in the classpath manifest. It appears to me that we need another dependency attribute to accompany scope "Provided", say true or a CONTAINER|MF-CP etc. In this solution, we wouldn't need the manifest->addClasspath plugin config. The war builder would only include the artifact in the war when the scope wasn't provided and the war archiver would know when to include the dependency in the manifest classpath. You would still require the manifest classpath prefix config. Does this make sense? Is there a way to accomplish this already? > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Assignee: John Tolentino > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff, MWAR-21-workaround.patch > > Time Spent: 6 hours >Remaining: 0 minutes > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- 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-1245) Reactor projects sometimes used even with version mismatch
[ http://jira.codehaus.org/browse/MNG-1245?page=comments#action_67054 ]
Mike Perham commented on MNG-1245:
--
The code in question appears to be in MavenProject.replaceWithActiveArtifact:
Note it should probably be doing some version checking also.
{code}
public Artifact replaceWithActiveArtifact( Artifact pluginArtifact )
{
if ( getProjectReferences() != null &&
!getProjectReferences().isEmpty() )
{
// TODO: use MavenProject getProjectReferenceId
String refId = ArtifactUtils.versionlessKey(
pluginArtifact.getGroupId(), pluginArtifact.getArtifactId() );
MavenProject ref = (MavenProject) getProjectReferences().get( refId
);
if ( ref != null && ref.getArtifact() != null )
{
// TODO: if not matching, we should get the correct artifact
from that project (attached)
if ( ref.getArtifact().getDependencyConflictId().equals(
pluginArtifact.getDependencyConflictId() ) )
{
// if the project artifact doesn't exist, don't use it. We
haven't built that far.
if ( ref.getArtifact().getFile() != null &&
ref.getArtifact().getFile().exists() )
{
pluginArtifact = new ActiveProjectArtifact( ref,
pluginArtifact );
}
...SNIP...
}
}
}
return pluginArtifact;
}
{code}
> Reactor projects sometimes used even with version mismatch
> --
>
> Key: MNG-1245
> URL: http://jira.codehaus.org/browse/MNG-1245
> Project: Maven 2
> Type: Bug
> Components: Plugins and Lifecycle
> Versions: 2.0
> Reporter: Kenney Westerhof
> Fix For: 2.0.5
> Attachments: deptest.tgz
>
> Original Estimate: 2 hours
> Remaining: 2 hours
>
> See attached sample project structure.
> In short: project A depends on project B version 1.1-SNAPSHOT,
> but only 1.0-SNAPSHOT is available (both in the reactor, so on disk), as well
> as in the local repository.
> Still, m2 install runs fine. Excerpt from building Project A:
> [DEBUG] Artifact not found - using stub model: Unable to download the
> artifact from any repository
> test:sub-b:1.1-SNAPSHOT:pom
> ..configuring compiler plugin.
> [DEBUG] (f) classpathElements =
> [/mnt/a/home/forge/work/sandbox/m2test/deptest/sub-a/target/classes,
> /mnt/a/home/forge/work/sandbox/m2test/deptest/sub-b/target/classes]
> Now, when running m2 eclipse:eclipse, m2 reacts as it should. Still the pom
> stub-model is used,
> but the .jar cannot be resolved.
> (weird enough m2 eclipse:eclipse doesn't accept reactor dependencies during
> resolve,
> although the generated projects do have internal links - but this is a
> different bug; this is a convenient bug for now.. ;))
> Proposed fix: Reactor projects can only be used when the pom versions match
> too. I thought
> this code was in months ago and working properly.
--
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-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_67056 ] Al Robertson commented on MWAR-9: - Comment taken from on MWAR-21 Here is a structure that J2EE requires maven to support ear ---jar1 ---war ->manifest classpath:jar1 ---jar2 war depends on jar1 and jar2 Currently, you can specify to add a manifest classpath entry. This adds an entry for each dependency that is not "Provided", because provided means "provided by the container". (CORRECT) In the above example, I can't configure maven to exclude jar1 from the war/WEB-INF/lib dir but include it in the classpath manifest. It appears to me that we need another dependency attribute to accompany scope "Provided", say true or a CONTAINER|MF-CP etc. In this solution, we wouldn't need the manifest->addClasspath plugin config. The war builder would only include the artifact in the war when the scope wasn't provided and the war archiver would know when to include the dependency in the manifest classpath. You would still require the manifest classpath prefix config. Does this make sense? Is there a way to accomplish this already? > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Mike Perham > > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- 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: (CONTINUUM-727) Allow Continuum to work with the release plugin to perform the official release
Allow Continuum to work with the release plugin to perform the official release --- Key: CONTINUUM-727 URL: http://jira.codehaus.org/browse/CONTINUUM-727 Project: Continuum Type: New Feature Reporter: Jason van Zyl This might eventually be a little tool for release management but it could start in Continuum. So the release plugin would do a release:prepare and store the information in a descriptor (maybe use modello to describe the release) and the descriptor could be sent to Continuum via a Web Service and Continuum could do the official 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
[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_67057 ] Jerome Lacoste commented on MNG-2293: - I don't get why it doesn't depend on the other issue as PLX-219 went into plexus alpha-10-SNAPSHOT. Could there be some local repository caching issue of some sort? > maven-plugin-descriptor: Not possible to define a default implementation for > a field defined by its interface > - > > Key: MNG-2293 > URL: http://jira.codehaus.org/browse/MNG-2293 > Project: Maven 2 > Type: New Feature > Components: Plugin Creation Tools > Versions: 2.0.4 > Reporter: Jerome Lacoste > Assignee: Kenney Westerhof > Priority: Critical > Fix For: 2.1 > Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, > dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, > patch-MNG-2293.diff > > > MOJO-393 is about letting the user define an alternate configuration element, > thus changing the way the webstart plugin works. > For that the idea was to make the mojo field an interface, provide a default > implementation in the plugin and let the user use plexus to instanciate a new > implemenation. > so for most users we would have: > > > > > and for some: > > > > > Unfortunately, today I am forced to specify the implementation in both cases. > There's no way to inform the plugin to use the default implementation. > The plugin.xml contains: > > bla > ...BlaInterface >... > > I tried to use > /[EMAIL PROTECTED] implementation="...BlaImplementation"*/ > BlaInterface bla; > but that fails as well. > Marking critical because it doesn't allow me add new features to the plugin > without breaking the config.xml. -- 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-727) Allow Continuum to work with the release plugin to perform the official release
[ http://jira.codehaus.org/browse/CONTINUUM-727?page=comments#action_67058 ] Jeremy Whitlock commented on CONTINUUM-727: --- IRC Conversation between Jason and myself: 08:53 the descriptor does not exist yet 08:54 when you run the release plugin it makes a properties file but nothing extensive 08:54 you would probably start with the release plugin and see what it produces 08:54 and then make that a little nicer to produce a standard release descriptor 08:54 something that continuum could use 08:54 this is all new 08:55 if you run mvn release:prepare on something you see it in action 08:55 it creates a release.properties 08:55 but would be nicer if that was a model of some sort 08:55 so i can help you start a modello model if you like as that's what we use for maven models 08:55 modello is a simple xml format for describing datamodels 08:56 and from that we generate java/xsd/dtd/xml reader/xml writer/docs/jdo bindings ... 08:56 so ultimately you end up with an xml file payload that gets send to continuum 08:57 but you can use a nice model inside the release plugin and serialize the xml 08:57 i can get you started on that if you like 08:57 not sure where i have to deploy now 08:58 http://people.apache.org/~jvanzyl/AppDeployment.png 08:58 let me add one more thing 09:02 http://people.apache.org/~jvanzyl/AppDeployment.png > Allow Continuum to work with the release plugin to perform the official > release > --- > > Key: CONTINUUM-727 > URL: http://jira.codehaus.org/browse/CONTINUUM-727 > Project: Continuum > Type: New Feature > Reporter: Jason van Zyl > Assignee: Jeremy Whitlock > > > This might eventually be a little tool for release management but it could > start in Continuum. So the release plugin would do a release:prepare and > store the information in a descriptor (maybe use modello to describe the > release) and the descriptor could be sent to Continuum via a Web Service and > Continuum could do the official 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
[jira] Created: (MRELEASE-130) Create a model for a release
Create a model for a release Key: MRELEASE-130 URL: http://jira.codehaus.org/browse/MRELEASE-130 Project: Maven 2.x Release Plugin Type: New Feature Reporter: Jason van Zyl Assigned to: Jeremy Whitlock Use modello to create a model for a release. Something that could be sent to a release mechanism for an official 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
[jira] Updated: (MNG-1245) Reactor projects sometimes used even with version mismatch
[ http://jira.codehaus.org/browse/MNG-1245?page=all ] Mike Perham updated MNG-1245: - Attachment: MNG-1245.patch > Reactor projects sometimes used even with version mismatch > -- > > Key: MNG-1245 > URL: http://jira.codehaus.org/browse/MNG-1245 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0 > Reporter: Kenney Westerhof > Fix For: 2.0.5 > Attachments: MNG-1245.patch, deptest.tgz > > Original Estimate: 2 hours > Remaining: 2 hours > > See attached sample project structure. > In short: project A depends on project B version 1.1-SNAPSHOT, > but only 1.0-SNAPSHOT is available (both in the reactor, so on disk), as well > as in the local repository. > Still, m2 install runs fine. Excerpt from building Project A: > [DEBUG] Artifact not found - using stub model: Unable to download the > artifact from any repository > test:sub-b:1.1-SNAPSHOT:pom > ..configuring compiler plugin. > [DEBUG] (f) classpathElements = > [/mnt/a/home/forge/work/sandbox/m2test/deptest/sub-a/target/classes, > /mnt/a/home/forge/work/sandbox/m2test/deptest/sub-b/target/classes] > Now, when running m2 eclipse:eclipse, m2 reacts as it should. Still the pom > stub-model is used, > but the .jar cannot be resolved. > (weird enough m2 eclipse:eclipse doesn't accept reactor dependencies during > resolve, > although the generated projects do have internal links - but this is a > different bug; this is a convenient bug for now.. ;)) > Proposed fix: Reactor projects can only be used when the pom versions match > too. I thought > this code was in months ago and working properly. -- 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-1245) Reactor projects sometimes used even with version mismatch
[ http://jira.codehaus.org/browse/MNG-1245?page=all ] Mike Perham updated MNG-1245: - Attachment: maven-project-2.0.5-SNAPSHOT.jar > Reactor projects sometimes used even with version mismatch > -- > > Key: MNG-1245 > URL: http://jira.codehaus.org/browse/MNG-1245 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0 > Reporter: Kenney Westerhof > Fix For: 2.0.5 > Attachments: MNG-1245.patch, deptest.tgz, maven-project-2.0.5-SNAPSHOT.jar > > Original Estimate: 2 hours > Remaining: 2 hours > > See attached sample project structure. > In short: project A depends on project B version 1.1-SNAPSHOT, > but only 1.0-SNAPSHOT is available (both in the reactor, so on disk), as well > as in the local repository. > Still, m2 install runs fine. Excerpt from building Project A: > [DEBUG] Artifact not found - using stub model: Unable to download the > artifact from any repository > test:sub-b:1.1-SNAPSHOT:pom > ..configuring compiler plugin. > [DEBUG] (f) classpathElements = > [/mnt/a/home/forge/work/sandbox/m2test/deptest/sub-a/target/classes, > /mnt/a/home/forge/work/sandbox/m2test/deptest/sub-b/target/classes] > Now, when running m2 eclipse:eclipse, m2 reacts as it should. Still the pom > stub-model is used, > but the .jar cannot be resolved. > (weird enough m2 eclipse:eclipse doesn't accept reactor dependencies during > resolve, > although the generated projects do have internal links - but this is a > different bug; this is a convenient bug for now.. ;)) > Proposed fix: Reactor projects can only be used when the pom versions match > too. I thought > this code was in months ago and working properly. -- 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-727) Allow Continuum to work with the release plugin to perform the official release
[ http://jira.codehaus.org/browse/CONTINUUM-727?page=comments#action_67061
]
Jeremy Whitlock commented on CONTINUUM-727:
---
More informative IRC conversation:
09:07 it will actually prepare a release and perform it
09:07 but something like continuum should perform the release
09:07 so it is done consistently
09:07 generally we do releases of our machines
09:07 which really isn't a good idea
09:07 So I would just extend the release plugin to create a model for
a release and then have Continuum be fed the release model and perform it right?
09:08 exactly
09:08 What usage do you foresee this being ran like?
09:09 i decide it's time for a release and i do a release:prepare with
the plugin configuration saying i want to deploy the release descriptor to
continuum
09:09 the release plugin pushes the descriptor to continuum
09:09 continuum queues it up for a release
09:09 and this can go all sorts of places
09:09 Ah.
09:09 I see what you mean.
09:09 Here are the steps:
09:09 you might want to make a separate release management tool that
continuum uses
09:10 as you might want to do announcments, deploy to a repo or make a
repo request or whatever
09:10 1. Extend the release plugin to prepare
09:10 2. Extend Continuum to be able to receive this prepare model
information to perform a release
09:10 That sound right?
09:10 yup, that sounds like a start
09:11 i would make this release stuff in continuum a clean separate
build/module
09:11 Will prepare *always* send to continuum or should it be a step
that can be ran at one point then finished up at another time?
09:11 as this could certainly be a stand-alone app eventually
09:11 Cool.
09:11 Could I create a release module for Continuum?
09:11 no, i think that should be optional and can be controlled via
plugin configuration
09:11 absolutely
09:11 that would be good
09:12 i'm just saying you might want to make a separate tool for this
and make a continuum wrapper to use it
09:12 it would be a cool little tool
09:12 Okay.
09:12 as you could stick in a chain of command that people could plug
into
09:12 Any example of this in practice? The tool via wrapper approach?
09:13 most of what we do is just making components and wiring them in
09:13 i can certainly get you started if you like
09:13 Also, if maven release:prepare should make the submission step
optional, how do you configure that?
09:13 Would it depend on the pom.xml configuration?
09:13 you would add some configuration to the plugin and control it in
the POM
09:13 yes, exactly
09:14 if (continuum bits are in the pom) { submit } else { just build
model document }
09:14 Something like ^^^?
09:14 yup
09:15 so if your bits which point to the continuum web service are
there then off it goes
09:15 What if it doesn't? Do we code in this tool a way to send an
actual file to the web service manually?
09:15 might want a way to just send the produced descriptor if you
change your mind
09:16 or someone might want to do it manually, in which case we don't
care
09:16 Okay.
09:16 we would encourage people to use continuum but they can carry as
much rope around with them as they like
> Allow Continuum to work with the release plugin to perform the official
> release
> ---
>
> Key: CONTINUUM-727
> URL: http://jira.codehaus.org/browse/CONTINUUM-727
> Project: Continuum
> Type: New Feature
> Reporter: Jason van Zyl
> Assignee: Jeremy Whitlock
>
>
> This might eventually be a little tool for release management but it could
> start in Continuum. So the release plugin would do a release:prepare and
> store the information in a descriptor (maybe use modello to describe the
> release) and the descriptor could be sent to Continuum via a Web Service and
> Continuum could do the official 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
[jira] Commented: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_67062 ] Al Maw commented on CONTINUUM-725: -- I've just tried this on our HTTP-authed viewcvs repository, and the initial addition and build works just fine. > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 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
[jira] Commented: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_67066 ] Scott McLachlan commented on CONTINUUM-725: --- can I get a copy of the latest snapshot distribution? the current 1.03 does not allow me to use https and an authenticated url. > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 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
[jira] Updated: (MNG-2357) misc cleanup
[ http://jira.codehaus.org/browse/MNG-2357?page=all ] Carlos Sanchez updated MNG-2357: Assign To: (was: Carlos Sanchez) Fix Version: 2.1 2.0.5 Fixed in trunk, will merge to branch > misc cleanup > > > Key: MNG-2357 > URL: http://jira.codehaus.org/browse/MNG-2357 > Project: Maven 2 > Type: Improvement > Versions: 2.1 > Reporter: Jerome Lacoste > Priority: Trivial > Fix For: 2.1, 2.0.5 > Attachments: MNG-2357.diff > > > small things including > - a little bit of doc for integration tests > - document 2 undocumented integration tests > - svn:ignore -- 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: (MSITE-148) does not seem to work
does not seem to work --- Key: MSITE-148 URL: http://jira.codehaus.org/browse/MSITE-148 Project: Maven 2.x Site Plugin Type: Bug Reporter: Grégory Joseph As far as I understand, adding true in thesection of my pom should have the same effect as org.apache.maven.plugins maven-project-info-reports-plugin ... but only that latter had any effect. (I was mainly trying to disable the dependencies report, because I have many dependencies build with m1 which don't have a proper m2 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
[jira] Commented: (MSITE-148) does not seem to work
[ http://jira.codehaus.org/browse/MSITE-148?page=comments#action_67070 ] Grégory Joseph commented on MSITE-148: -- (using site-plugin-2.0-beta-4) > does not seem to work > --- > > Key: MSITE-148 > URL: http://jira.codehaus.org/browse/MSITE-148 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Grégory Joseph > > > As far as I understand, adding > true > in thesection of my pom should have the same effect as > > org.apache.maven.plugins > maven-project-info-reports-plugin > > > > > ... but only that latter had any effect. > (I was mainly trying to disable the dependencies report, because I have many > dependencies build with m1 which don't have a proper m2 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
[jira] Commented: (MPSITE-51) site:war creates incomplete war with many files missing
[ http://jira.codehaus.org/browse/MPSITE-51?page=comments#action_67071 ] Jeff Jensen commented on MPSITE-51: --- You are right on - Ant 1.6.5 task exhibits the problem. Thanks Lukas. http://issues.apache.org/bugzilla/show_bug.cgi?id=39767 > site:war creates incomplete war with many files missing > --- > > Key: MPSITE-51 > URL: http://jira.codehaus.org/browse/MPSITE-51 > Project: maven-site-plugin > Type: Bug > Components: plugin > Versions: 1.6.1, 1.7 > Environment: beta3 > Reporter: Jeff Jensen > > > Problem first appeared when upgraded to 1.7. Downgrading to 1.6.1 caused the > problem to go away. Now, a month or two later, 1.6.1 exhibits the problem > too. Perhaps because the size of our codebase continues to grow it now shows > in 1.6.1. > How we create the war: > 1) clean all > 2) run site on each component > 3) run multiproject on the parent to get the dashboard report, its html pages > generated, and all subprojects copied into place > 4) run site:war to create the war > The war is missing files, including files in the root that are part of the > parent (e.g. FAQs) and most content of some subprojects. Yes, these files > exist in the target dir. > Interestingly, the -X output shows one of the missing files identified as > needed and added on a site:war run that doesn't delete the war first: > [war] [VERBOSE] perforcefaq.html added as perforcefaq.html is outdated. > > [war] [VERBOSE] adding entry perforcefaq.html > Yet the resulting war does not have that file (and others). Hmm, perhaps > this suggests a problem somewhere else... > The site and war is large, runs about 10 hours to generate and the war as-is > is around 360M. > I moved the site deploy process to the war approach from the file copy > approach, as it was cleaner and a bit faster. I think the workaround is to > go back to the file copy deploy approach. -- 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: (MPSITE-51) site:war creates incomplete war with many files missing
[ http://jira.codehaus.org/browse/MPSITE-51?page=all ] Lukas Theussl closed MPSITE-51: --- Assign To: Lukas Theussl Resolution: Won't Fix > site:war creates incomplete war with many files missing > --- > > Key: MPSITE-51 > URL: http://jira.codehaus.org/browse/MPSITE-51 > Project: maven-site-plugin > Type: Bug > Components: plugin > Versions: 1.6.1, 1.7 > Environment: beta3 > Reporter: Jeff Jensen > Assignee: Lukas Theussl > > > Problem first appeared when upgraded to 1.7. Downgrading to 1.6.1 caused the > problem to go away. Now, a month or two later, 1.6.1 exhibits the problem > too. Perhaps because the size of our codebase continues to grow it now shows > in 1.6.1. > How we create the war: > 1) clean all > 2) run site on each component > 3) run multiproject on the parent to get the dashboard report, its html pages > generated, and all subprojects copied into place > 4) run site:war to create the war > The war is missing files, including files in the root that are part of the > parent (e.g. FAQs) and most content of some subprojects. Yes, these files > exist in the target dir. > Interestingly, the -X output shows one of the missing files identified as > needed and added on a site:war run that doesn't delete the war first: > [war] [VERBOSE] perforcefaq.html added as perforcefaq.html is outdated. > > [war] [VERBOSE] adding entry perforcefaq.html > Yet the resulting war does not have that file (and others). Hmm, perhaps > this suggests a problem somewhere else... > The site and war is large, runs about 10 hours to generate and the war as-is > is around 360M. > I moved the site deploy process to the war approach from the file copy > approach, as it was cleaner and a bit faster. I think the workaround is to > go back to the file copy deploy approach. -- 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-447) Remove Project Exception
[ http://jira.codehaus.org/browse/CONTINUUM-447?page=comments#action_67072 ] Sylvain Deschênes commented on CONTINUUM-447: - Same thing on Suse linux 9.1 ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be deleted NestedThrowables: javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM BUILDDEFINITION WHERE ID = ? NestedThrowables: SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of foreign key constraint 'PROJECT_BUILP8_FK2' for key (67). The statement has been rolled back.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ javax.jdo.JDOUserException: One or more instances could not be deleted at org.jpox.AbstractPersistenceManager.deletePersistentAll(AbstractPersistenceManager.java:1438) at org.jpox.store.rdbms.scostore.ElementContainerStore.clear(ElementContainerStore.java:595) at org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304) at org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332) at org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTable.java:2280) at org.jpox.store.StoreManager.deleteDependent(StoreManager.java:838) at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4049) at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1391) at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1402) at org.codehaus.plexus.jdo.PlexusJdoUtils.removeObject(PlexusJdoUtils.java:53) at org.apache.maven.continuum.store.JdoContinuumStore.removeObject(JdoContinuumStore.java:969) at org.apache.maven.continuum.store.JdoContinuumStore.removeProject(JdoContinuumStore.java:901) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:328) 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 ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:1
[jira] Commented: (MRESOURCES-18) System properties and cmdline params not filtered without filter file
[ http://jira.codehaus.org/browse/MRESOURCES-18?page=comments#action_67073
]
Carlos Sanchez commented on MRESOURCES-18:
--
this is closed but I don't see any changes in the resources plugin inside
Subversion Commits tab?
> System properties and cmdline params not filtered without filter file
> -
>
> Key: MRESOURCES-18
> URL: http://jira.codehaus.org/browse/MRESOURCES-18
> Project: Maven 2.x Resources Plugin
> Type: Bug
> Versions: 2.2, 2.1
> Reporter: Kenney Westerhof
> Assignee: Kenney Westerhof
> Fix For: 2.2
>
>
> If you have a src/main/resources/test.properties with the following content:
> param=${param}
> userhome=${user.home}
> and you define a resources section with filtering enabled for this, then
> running
> mvn process-resources -Dparam=PARAM
> yields a target/classes/test.properties where the properties are not filtered
> (i.e. the file is unchanged).
> When you define a emptyfile no content,
> the resource is properly filtered.
--
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Scott Cytacki updated MNGECLIPSE-59: Attachment: project-artifacts.patch > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MPDIST-12) build-src goal use predefined src field, not sourceDirectory
[ http://jira.codehaus.org/browse/MPDIST-12?page=all ] Lukas Theussl closed MPDIST-12: --- Resolution: Fixed > build-src goal use predefined src field, not sourceDirectory > > > Key: MPDIST-12 > URL: http://jira.codehaus.org/browse/MPDIST-12 > Project: maven-dist-plugin > Type: Bug > Environment: win2k SP4, java 1.4.2_04, > maven 1.0-rc4 > Reporter: Marcin S. > Assignee: Lukas Theussl > Fix For: 1.7 > > Original Estimate: 3 hours > Remaining: 3 hours > > When I run maven dist:build-src I get product-src.zip containing only > build.xml, LICENSE.txt, project.properties and project.xml. > No files from sourceDirectory is taken. > If I move all contents of my sourceDirectory (Source/java) to src in project > root directory everything is OK. > I suppose that maven is always taking default location (src) and do not > change it with value from /project/build/sourceDirectory. > PS. Other actions like compiling, jar, javadoc are working perfect, so it > should not be a problem with my project.xml and mavem.xml. -- 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: (MNGECLIPSE-136) Plugin give wrong Maven goal for installing Javadoc jar
Plugin give wrong Maven goal for installing Javadoc jar --- Key: MNGECLIPSE-136 URL: http://jira.codehaus.org/browse/MNGECLIPSE-136 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Dependency Resolver Reporter: Tim Shadel Assigned to: Eugene Kuleshov The Eclipse plugin gives the following output when it cannot locate a remote -javadoc.jar file for a dependency 6/9/06 2:22:30 PM GMT-07:00: [WARN] Unable to get resource from repository central (http://repo1.maven.org/maven2) 6/9/06 2:22:30 PM GMT-07:00: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.springframework -DartifactId=spring \ -Dversion=2.0-m5 -Dpackaging=java-doc -Dfile=/path/to/file org.springframework:spring-2.0-m5.java-doc The part that is in error is "-Dpackaging=java-doc". Instead it should read "-Dpackaging=javadoc". The second version creates the right pattern for installation in the repository. The other one creates a .java-doc file instead (similar to the problem described in MNGECLIPSE-122). -- 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: (MPTEST-63) Memory leak in test plugin 1.8?
Memory leak in test plugin 1.8? --- Key: MPTEST-63 URL: http://jira.codehaus.org/browse/MPTEST-63 Project: maven-test-plugin Type: Bug Versions: 1.8 Environment: Linux FC3, jdk 1.4.2_10, m11b3 Reporter: Lukas Theussl Priority: Critical Fix For: 1.8.1 In a project with ~40 test classes, I was surprised to see 'maven dist-bin' fail with a java.lang.reflect.InvocationTargetException Exception in thread "main" java.lang.OutOfMemoryError when running the junit test suite, even though, the tests pass when running just 'maven test'. The point is that dist-bin runs the test suite twice (once from jar:jar,once from site:generate), and it's only the second time that it fails. I can reproduce it with a simple custom goal: It works by simply downgrading to test-plugin-1.7, so it's not a problem with my tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPTEST-64) test-plugin-1.8 is way slower than 1.7
test-plugin-1.8 is way slower than 1.7 -- Key: MPTEST-64 URL: http://jira.codehaus.org/browse/MPTEST-64 Project: maven-test-plugin Type: Bug Versions: 1.8 Environment: Linux FC3, jdk 1.4.2_10, m11b3 Reporter: Lukas Theussl This is maybe related to MPTEST-63: a test suite that takes ~30s with test-plugin-1.7, takes over a minute with 1.8. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPDIST-19) Make inclusion of site docs optional for binary distribution
[ http://jira.codehaus.org/browse/MPDIST-19?page=all ] Lukas Theussl closed MPDIST-19: --- Assign To: Lukas Theussl Resolution: Fixed Fix Version: 1.7 Added maven.dist.bin.include.site property. > Make inclusion of site docs optional for binary distribution > > > Key: MPDIST-19 > URL: http://jira.codehaus.org/browse/MPDIST-19 > Project: maven-dist-plugin > Type: Improvement > Reporter: Anders Westlund > Assignee: Lukas Theussl > Fix For: 1.7 > > > The fix for MPDIST-8 unfortunately has made "site" a prereq for > dist:build-bin. OK, the fix does make the behaviour predictable, but I would > not say "right". IMHO the full project site docs don't belong in a binary > distribution at all. What you need there is exactly what was bundled in RC2: > the jar, and the javadoc to use it. The site docs don't belong in the source > distribution either, as it is so easy to generate them from the source. > Not to break anything depending on the current behaviour, the site plugin > would need a property like maven.dist.bin.includeSite=true/false, the default > being true. -- 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: (MPDIST-26) Allow distribution of artifact types other than jar (better solution then as indicated at http://jira.codehaus.org/browse/MPDIST-13?).
[ http://jira.codehaus.org/browse/MPDIST-26?page=all ]
Lukas Theussl closed MPDIST-26:
---
Resolution: Fixed
Added a property maven.dist.bin.artifact.type.
> Allow distribution of artifact types other than jar (better solution then as
> indicated at http://jira.codehaus.org/browse/MPDIST-13?).
> --
>
> Key: MPDIST-26
> URL: http://jira.codehaus.org/browse/MPDIST-26
> Project: maven-dist-plugin
> Type: Improvement
> Environment: Not of importance.
> Reporter: Davy Toch
> Assignee: Lukas Theussl
> Fix For: 1.7
> Attachments: multiprojectProperties.txt, postGoal.xml
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The goal dist:build-bin should also allow to include artifacts different then
> the ones created by jar:jar (e.g. wars, ears, ...). A solution was already
> proposed at http://jira.codehaus.org/browse/MPDIST-13.
> Currently, we're writing a postGoal for dist:prepare-bin-filesystem that:
> 1. determines the current project 'type' (ejb, war, jar, ...)
> 2. removes the already generated jar if the current project type is different
> from 'jar'
> 3. attain the goal 'type':'type' to (re)create the artifact
> 4. copy the artifact to the binary distribution directory
> Cf postGoal.xml included as attachment.
> This postGoal currently uses the property maven.multiproject.type from the
> multiproject plugin:
> 1. maven.multiproject.type = 'master' :
> - master Maven project from which other projects can inherit (to avoid POM
> configuration duplication)
> - steps 1 and 2 of our custom postGoal are executed
> 2. maven.multiproject.type <> 'master' :
> - Maven projects that create artifacts (jars, ears, ...)
> - type = 'jar' : step 1 executed
> - type <> 'jar' : steps 1 to 4 executed
> Cf multiprojectProperties.txt included as attachment.
> Having a solution similar to the postGoal but already integrated in the
> plugin would allow minimizing custom scripting in maven.xml and have a more
> generic dist plugin. Also remark that an alternative to using
> maven.multiproject.type can be chosen (e.g. maven.dist.artifact.type), in
> order to avoid being dependent on properties of the multiproject plugin.
> The only problem I can see is that the prereqs='jar:jar' in the dist plugin
> would somehow have to be replaced by a call name="${type}:${type}"/>, meaning that it is possible that the goal
> ${type}:${type} will be called more than once.
> Regards,
> Davy Toch
--
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: (MPDIST-17) should be able to turn off creation of zip and.or tar.gz files via plugin properties
[ http://jira.codehaus.org/browse/MPDIST-17?page=all ] Lukas Theussl closed MPDIST-17: --- Resolution: Fixed > should be able to turn off creation of zip and.or tar.gz files via plugin > properties > > > Key: MPDIST-17 > URL: http://jira.codehaus.org/browse/MPDIST-17 > Project: maven-dist-plugin > Type: Improvement > Environment: n/a > Reporter: Ian Springer > Assignee: Lukas Theussl > Fix For: 1.7 > > > For our project, we want to only make our dist available as a zipfile. This > is because it is a Java project, and therefore we know the jar command will > always be available to our users to unzip the distribution, no matter what > platform they are on. So here is no need for a tar.gz dist. Unfortunately, it > is currently not possible to turn off creation of the tar.gz. Can you please > add some properties to control this? Something like: > maven.dist.create.zip = true > maven.dist.create.tar.gz = true > Thanks. > Ian -- 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: (MSITE-148) does not seem to work
[ http://jira.codehaus.org/browse/MSITE-148?page=comments#action_67089 ] Brett Porter commented on MSITE-148: is it because of inheritence (MNG-1999)? This works for me. > does not seem to work > --- > > Key: MSITE-148 > URL: http://jira.codehaus.org/browse/MSITE-148 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Grégory Joseph > > > As far as I understand, adding > true > in thesection of my pom should have the same effect as > > org.apache.maven.plugins > maven-project-info-reports-plugin > > > > > ... but only that latter had any effect. > (I was mainly trying to disable the dependencies report, because I have many > dependencies build with m1 which don't have a proper m2 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
[jira] Closed: (MWAR-46) EJB-client libraries are added with wrong extension
[ http://jira.codehaus.org/browse/MWAR-46?page=all ] Brett Porter closed MWAR-46: Assign To: Brett Porter Resolution: Duplicate > EJB-client libraries are added with wrong extension > --- > > Key: MWAR-46 > URL: http://jira.codehaus.org/browse/MWAR-46 > Project: Maven 2.x War Plugin > Type: Bug > Versions: 2.0 > Reporter: Joerg Schaible > Assignee: Brett Porter > Priority: Blocker > > > If a war has a dependency to an ejb client library, this library is added to > META-INF/lib as artifactId.ejb-client. Such artifacts are not added to the > classpath by all app servers e.g. like WebLogic 8.1. The dependency must be > added as artifactId-ejb-client.jar. -- 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: (MSITE-148) does not seem to work
[ http://jira.codehaus.org/browse/MSITE-148?page=comments#action_67090 ] Grégory Joseph commented on MSITE-148: -- Nope, this project is standalone, no inheritence involved. I could attach my complete pom next monday, but I'm not sure how much it'd help since many dependencies will not be available outside of my company's repo.. > does not seem to work > --- > > Key: MSITE-148 > URL: http://jira.codehaus.org/browse/MSITE-148 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Grégory Joseph > > > As far as I understand, adding > true > in thesection of my pom should have the same effect as > > org.apache.maven.plugins > maven-project-info-reports-plugin > > > > > ... but only that latter had any effect. > (I was mainly trying to disable the dependencies report, because I have many > dependencies build with m1 which don't have a proper m2 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
[jira] Created: (MPPDF-56) Some HTML in the .xml file do not translate to the PDF
Some HTML in the .xml file do not translate to the PDF -- Key: MPPDF-56 URL: http://jira.codehaus.org/browse/MPPDF-56 Project: maven-pdf-plugin Type: Bug Versions: 2.4 Environment: Maven 1.0.2; Java 1.5 Reporter: Jamie Bisotti Our documentation makes use of tags like the following: Foo; however, in the PDF the text is not appearing in red. Also, the tag seems to be ignored as well. Finally, the 'style' attribute seems to be ignored altogether. -- 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: (MEJB-16) clientExcludes generates empty packages i client-jar
clientExcludes generates empty packages i client-jar Key: MEJB-16 URL: http://jira.codehaus.org/browse/MEJB-16 Project: Maven 2.x Ejb Plugin Type: Bug Versions: 2.0 Environment: Discovered on MAC OSX, but I dont think it is OS dependent Reporter: Anders Kr. Andersen Priority: Minor When I use the ... the excluded packages are still package in the jar. But empty. The bigggest problem is probably the visual testing the developer is doing. Seeing that packages remanis in the jar ... and discovering that they are empty simple just takes a little time. I don't think the JVM have any problem with this ? But I don't think it is in the JAR specification either :-) -- 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
