Re: xdoc DTD - Do we already have a PUBLIC identifier?
Actually, the navbar is in there already... I tried to discuss the question of what an xdoc is once on the maven dev list [1] but didn't get too much feedback. I then adopted the definition of an xdoc as something that is transformed into a valid xhtml1-transitional by the xdoc plugin. This of course links it intimately to maven and the xdoc plugin (which is also reflected in the current versioning scheme - the dtd in svn is called maven-xdoc-1.10.dtd and I assumed that we would publish a new version with every xdoc plugin). I never thought of '... getting XDOC out of the maven/velocity realm and making an official format'. As for now, the only difference between an xdoc and an xhtml1-transitional is the addition of the elements section, subsection, escapeXml, source and navbar. Any comments welcome. -Lukas [1] http://www.nabble.com/What-is-an-xdoc--t370461.html#a1023611 Henning Schmiedehausen wrote: Hi, getting XDOC out of the maven/velocity realm and making an official format would IMHO help its visibility tremendously. That's why I proposed to adopt it as -//Apache Software Foundation//DTD XDOC 1.0//EN and removed all the maven and velocity references from it. Having it online is good, having it at www.apache.org/dtds with an official location and version number (1.0) is IMHO much better. It would also avoid sneaking stuff in. ;-) (navbar...) Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Milos Klient as a committer
+1 -Lukas Brett Porter wrote: +1 I welcome any opportunity to work together with the MevenIDE project, and Milos has a good idea of what's needed in the embedder. - Brett Jason van Zyl wrote: Hi, Just giving all devs a heads up that I discussed adding Milos as a committer on Maven for his work on the embedder and the Netbeans plugin. There were enough +1s on the PMC list to bring Milos in but wanted to give other devs a chance to voice their opinion. Milos has a very good knowledge of Maven as he's been doing the integration in Netbeans for a long time. He's done the Maven1 and Maven2 integration. He does a lot embedder work which is essentially the maven core. I would gladly welcome his addition as a committer as the embedder needs a swift kick in the pants! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoc DTD - Do we already have a PUBLIC identifier?
No, there is none. The DTD is currently only available in SVN, it was added in the 1.10 version of the maven-1 xdoc plugin which is not released yet. As such, it is still work in progress, so I don't know if it's a good idea to publish it at this point. However, as far as I'm concerned, the xdoc-1.10 plugin could be released very soon, we will consider your demand as soon as it's done (please remind us if we forget, I know you are good at that! ;) ) -Lukas Henning Schmiedehausen wrote: Hi, I finally was able to make heads and tails of the xdoc DTD as included in the maven 1 xdoc plugin (thanks a lot for this, Lukas Arnaud!) . To make XMLMind to automatically identify these files, we do need a DTD public identifier. Do you already have one? Googling for this didn't really help me here. If you don't have decided for an identifier, I'd like to propose: !DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN http://www.apache.org/dtds/xdoc_1_0.dtd; as DTD identifier for the XDOC format. As I understand, we then must make this DTD visible at the designated location, which needs coordination with the infra people. However, putting it under www.apache.org means, that the mirror system will pick up these DTDs. Any opinions? If you agree, you can take a look at http://wiki.apache.org/jakarta-velocity/EditXdocs to get my XMLMind hackery for actually editing xdocs (not just painfully writing them... :-) ). Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] John Tolentino as a Maven Plugins and Repository Manager committer
+1 -Lukas Brett Porter wrote: Hi, John has been helping out on the users list, plugins and the repository manager for some time. I'd like to propose we give him commit access. [ ] +1 [ ] +0 [ ] -1 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Maria Odea (Deng) Ching as a Maven Plugins and Repository Manager committer
+1 -Lukas Brett Porter wrote: Hi, Like John, Deng has been helping out on the users list, plugins and the repository manager for some time. I'd like to propose we give her commit access. [ ] +1 [ ] +0 [ ] -1 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Jesse McConnell as a Maven Plugins committer
+1 -Lukas Brett Porter wrote: Hi, I think we all agree we need more keen people helping out with plugins! Jesse has been contributing on the users list and mojo project for some time, and has recently contributed several patches to the Apache Maven plugins, tests for the clean, compiler and jar plugins, and contributed a plugin testing harness. I'd like to propose we give him commit access. [ ] +1 [ ] +0 [ ] -1 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r388945 - /maven/maven-1/plugins/trunk/test/plugin.jelly
Fixed. Thanks!
-Lukas
Arnaud HERITIER wrote:
+j:if test=${maven.test.failure}
Hi Lukas,
Did you test it with maven 1.0.X ?
I remember that there were several problems with variables with dots in
their names.
Arnaud
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] plugin updates
ping I need a third binding vote, please! -Lukas Lukas Theussl wrote: Hi, Please vote for a release of the following m1 plugins: [] maven-changelog-plugin-1.9.1 [] maven-checkstyle-plugin-3.0.1 [] maven-java-plugin-1.6 [] maven-jdepend-plugin-1.6.1 Apart from the java plugin, these are all bug-fix versions of releases I did recently. Check the changes and jira reports for each plugin for a list of changes, future docs are here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/changelog/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/checkstyle/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/java/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/jdepend/ +1 from me and 72h to vote, Cheers, Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=1.9.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-checkstyle-plugin -Dversion=3.0.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-java-plugin -Dversion=1.6-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jdepend-plugin -Dversion=1.6.1-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] [vote] [m1] plugin updates
We finally have 3 binding +1 (Arnaud, Stephane, Lukas). Vote thread: http://www.nabble.com/-vote-m1-plugin-updates-t1320556.html#a3522561 I'll do the releases this weekend. Cheers, Lukas Lukas Theussl wrote: Hi, Please vote for a release of the following m1 plugins: [] maven-changelog-plugin-1.9.1 [] maven-checkstyle-plugin-3.0.1 [] maven-java-plugin-1.6 [] maven-jdepend-plugin-1.6.1 Apart from the java plugin, these are all bug-fix versions of releases I did recently. Check the changes and jira reports for each plugin for a list of changes, future docs are here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/changelog/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/checkstyle/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/java/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/jdepend/ +1 from me and 72h to vote, Cheers, Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=1.9.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-checkstyle-plugin -Dversion=3.0.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-java-plugin -Dversion=1.6-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jdepend-plugin -Dversion=1.6.1-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] [m1] plugin updates
Hi, Please vote for a release of the following m1 plugins: [] maven-changelog-plugin-1.9.1 [] maven-checkstyle-plugin-3.0.1 [] maven-java-plugin-1.6 [] maven-jdepend-plugin-1.6.1 Apart from the java plugin, these are all bug-fix versions of releases I did recently. Check the changes and jira reports for each plugin for a list of changes, future docs are here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/changelog/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/checkstyle/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/java/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/jdepend/ +1 from me and 72h to vote, Cheers, Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=1.9.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-checkstyle-plugin -Dversion=3.0.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-java-plugin -Dversion=1.6-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jdepend-plugin -Dversion=1.6.1-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira - Issues closed without assignee
I think you misunderstood my point. It was not at all about opening issues. In brief, I want to be able to set a fix for version (eg because somebody attaches a patch, or to set up a roadmap) without having to assign the issue (eg because I don't have time right now to test the patch, and I don't want to deter anybody else from taking a look at it). -Lukas Vincent Massol wrote: -Original Message- From: Lukas Theussl [mailto:[EMAIL PROTECTED] Sent: dimanche 19 mars 2006 02:38 To: Maven Developers List Subject: Re: Jira - Issues closed without assignee [snip] I also don't like the idea of making it obligatory to assign an issue for closing or setting a fix for version. If an issue gets opened with a patch attached, but I don't have time to check it right away, I still want to set the fix for so I won't forget it, but at the same time not prevent somebody else to take it up and fix it before me. I was not talking about forcing an assignee on issue creation but on issue close (but I don't know how easy or possible this is with Jira). Same thing for fix for. [snip] -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] PMD plugin v1.8 for maven 1.x
+1 Lukas Arnaud HERITIER wrote: Hi all, We are ready to release a new version of the PMD plugin. All bugs issues are solved and there's only one enhancement opened in Jira. Changes in this version include: New Features: o New property maven.pmd.targetjdk to define the target JDK. Fixes MPPMD-19. Thanks to Wim Deblauwe. o Add a link on each error to explain it. o New properties maven.pmd.failonerror and maven.pmd.failonruleviolation to fail the build if any errors or problems are found. Fixes MPPMD-21. o New property maven.pmd.console to display pmd errors to the console. Fixes MPPMD-13. Fixed bugs: o Do not generate links to JXR files if they are not created. o Fix NullPointerException if pom.build.sourceDirectory or pom.build.unitTestSourceDirectory are not defined. Changes: o Use properties maven.jxr.destdir and maven.jxr.destdir.test to generate links from the PMD report to jxr files. o Upgrade to pmd-3.5. You can find the staging site here : http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/pmd/ http://people.apache.org/%7Eaheritier/maven-stage-site/maven-1.x/plugins/pmd/ To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven ,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-pmd-plugin -Dversion=1.8-SNAPSHOT Please, vote : [] +1 : Ok, I tested it [] +0 : Ok, but I didn't test it [] -1 : I'm against because ... Vote is open for 72 hours. My +1 Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira - Issues closed without assignee
Honestly, apart from statistical purposes, I don't see the point in having closed issues assigned to somebody at all. Would all the people who have moved on to m2 take up an old m1 issue if it gets reopened today? What about people who have left the project? IMO it's the project lead/maintainer who should decide what should happen with reopened issues. I also don't like the idea of making it obligatory to assign an issue for closing or setting a fix for version. If an issue gets opened with a patch attached, but I don't have time to check it right away, I still want to set the fix for so I won't forget it, but at the same time not prevent somebody else to take it up and fix it before me. The only use case I know is when I start working on an issue and I don't want anybody else to waste some time on it. For m1, the chance of two people working on the same issue is almost negligible now, that's why I practically never assigned an issue to myself so far. -Lukas Arnaud HERITIER wrote: I agree. I don't want that we update all closed issues up until now, but only that we take care to define the assignee from now. Arnaud On 3/18/06, Brett Porter [EMAIL PROTECTED] wrote: As far as I'm concerned, setting the assignee to yourself when you close it has been accepted practice for some time (but we don't need to go back and change all the old ones). That way, if it is reopened, the person that closed it can deal with it. - Brett Arnaud HERITIER wrote: Hi guys, I noticed that we have in maven projects (particularly in m1) a lot of issues closed (2033) but without assignee (698). I think that it is a good practice to assign the issue to the one who closed it (even if it's a Won't fix or duplicated status). It's easier to see who closed it (in an issues list for example). We don't have to open the issue to see the change history. WDYT ? Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r385672 - /maven/maven-1/core/trunk/project.properties
Is there a specific reason for that? In general, I think that test code should be subject to the same quality criteria as main code. -Lukas [EMAIL PROTECTED] wrote: Author: aheritier Date: Mon Mar 13 14:15:20 2006 New Revision: 385672 URL: http://svn.apache.org/viewcvs?rev=385672view=rev Log: Ignore simian reporting in tests classes Modified: maven/maven-1/core/trunk/project.properties Modified: maven/maven-1/core/trunk/project.properties URL: http://svn.apache.org/viewcvs/maven/maven-1/core/trunk/project.properties?rev=385672r1=385671r2=385672view=diff == --- maven/maven-1/core/trunk/project.properties (original) +++ maven/maven-1/core/trunk/project.properties Mon Mar 13 14:15:20 2006 @@ -117,6 +117,7 @@ # Simian plugin settings #= maven.simian.linecount = 4 +maven.simian.includetests = false #= # Site plugin settings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Bring plugins to Maven
+1 Lukas Brett Porter wrote: A month ago I sent a proposal for discussion, to bring some mojos into the Maven plugins project, because a) originally coming from here in Maven 1.x b) having the core libraries located here c) being essential to the day to day use of the project. So, here is a vote to bring the following plugins to Maven: - jxr report (relates to jxr) - surefire report (relates to surefire) - changes/jira/announcement report (relates to issue stuff in sandbox) - changelog report (relates to scm) - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). Please vote: [ ] +1 [ ] +0 abstain [ ] -1 Vote is open for 72 hours. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Fabrice Bellingard as a plugins committer
+1 Lukas Brett Porter wrote: Hi, Fabrice worked on the JXR plugin, fixed a number of bugs in the original library and improved the mojo. Active on the users list, with a particular interest in the site plugin, I believe would be a good addition to the project. Please vote: [ ] +1 [ ] +0 abstain [ ] -1 Vote is open for 72 hours. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Brian Fox as a plugins committer
+1 Lukas Brett Porter wrote: Hi, Brian has done a great job in keeping the mojo project in order and has developed the dependency plugin there, which we previously indicated we'd like to have as a part of the Maven plugin artillery. He has also actively helped on the users list and participated on the dev@ list. Please vote: [ ] +1 [ ] +0 abstain [ ] -1 Vote is open for 72 hours. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r383371 - /maven/site/trunk/src/site/resources/.htaccess
Brett Porter wrote: That's what it does now, after I made the change. Before it was /reference/, now it is /maven-1.x/reference. It wasn't working, Lukas asked me to fix it. I don't know why you say that, I never contacted you about it. I couldn't have, as I was on vacation last week. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven EJB Plugin 1.7.2 released
Thanks for the reminder, Joerg. As for m1.0 compatibility, as far as I know, only the newer versions of the artifact plugin are completely incompatible with m1.0.2. Apart from that, we are trying to keep m1.0.2 compatibility for all plugins. If you find something that works under m1.1 but not m1.0.2, then it should probably be considered a bug. Only in some cases we have implemented specific new features that require m1.1, but this should be at least well documented. -Lukas Jörg Schaible wrote: Hi Stephane and other devs announcing plugin releases, just a recommendation for the next plugin announcement: Report the Maven version the plugin is designed for. Only the link to the documentation below indicates, that this is an update for a Maven 1 plugin. Also it does not really help users that are stuck to M102, since they don't know if this new version is still compatible to M102 or if it requires M11 already. - Jörg Stephane Nicoll wrote on Wednesday, March 08, 2006 8:01 PM: The maven team is pleased to announce the Maven EJB Plugin 1.7.2 release! http://maven.apache.org/maven-1.x/plugins/ejb/ To automatically install the plugin, type the following on a single line: maven plugin:download -DgroupId=maven -DartifactId=maven-ejb-plugin -Dversion=1.7.2 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plu gins/maven-ejb-plugin-1.7.2.jar Have fun! -The maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the current web site suck less
I think that's a good idea. In m1 we are already using the maven.site.stage.address property to publish sites more frequently to our personal pages (eg [1]) and I refer people to this site occasionally. This has the obvious drawback that the 'latest-and-greatest' docs for different plugins are always on different people's pages. I could imagine something like http://maven.apache.org/maven-1.x/stage-site/ where the whole m1 site is replicated but with more up-to date pages, and the main site only gets updated for releases or documentation bug fixes. -Lukas [1] http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/ Tim O'Brien wrote: Having to choose between publishing the latest and greatest docs and only the released version is a problem that Maven seems to have created for itself. Same issue comes up in other projects frequently - Commons has a problem because some of the sites only publish on a release. Latest and greatest are almost never there. What about publishing the latest and greatest docs to another directory? The Maven site gets pushed to a directory that has a version of a label. http://maven.apache.org/version/1.0 , http://maven.apache.org/version/2.0.2, and http://maven.apache.org/version/trunk. This way the Maven site can have a nightly publish of the most current Maven site to Trunk every single day, but still keep legacy docs around intact for people using older versions of the product. The consumer site can point to the latest release, and the developer site can point to trunk. The Maven site plugin would need some mechanism for adding a skin to a site to clearly identify it as Development. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making docs and tests suck less
+1 for everything and I hope this will be enforced (by all of us) -Lukas Brett Porter wrote: This is not too long, and important. Please read. I've just spent some time discussing this on users@, and felt it was time to bring it here to look at the practical steps going forward. Basically, I think we've all known for a long time that both need work. There was a big push around 2.0 but it fizzled out afterwards. I don't want to focus on what we are missing now - we can address that with what is already in place. I also want to put aside the documentation and testing efforts that are already under way as they've been taken into consideration. What I want to focus on is going forward - new work. I think we need to change the culture. I realise this is hard given the timing because there isn't a lot of new work going on - because we're all doing bug fixes, docs and testing! - but hopefully because of this it will be apparent why it is important to do them as we go. I've been trying to push for this for a long time, but haven't lived up to it myself which is one reason why it fails. I hate hypocrisy so can't really call other people on it (though I probably do anyway), and it requires everyone to buy in. So, I've committed r383963 which emphasises these requirements on patch contributions: * Whether it works and does what is intended. * Whether it fits the spirit of the project. * Whether it contains tests. It is expected that any patches relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. * Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. In the following, I'll discuss a technical veto. That's a -1 that means that the issue needs to be resolved before a release can occur. It doesn't mean someone rolls it back immediately (though a release manager may if it blocks a branch being released). It also doesn't mean anything negative about the committer in question, and it's important we keep it that way so that people aren't afraid to contribute or to call people on theese things. So my questions are, can we institute the following: * new functionality without automated test coverage can and should be technically vetoed. We can measure this with code coverage tools, and the measure will be that the % does not decline. It will actually break the build, being an automatic technical veto :) * new functionality without documentation can and should be technically vetoed. We can't really measure this with tools, so need to be vigilant on it ourselves. We also need to be understanding that docs may follow the code once it is finished, so we should use JIRA to track it (keep the original ticket open until documented, or create a new, blocking issue). * new code without javadoc/code documentation can be technically vetoed. I'm less tied to this one, though for public facing APIs I think Javadoc is imperative. It may be that we can use Checkstyle to enforce this to a degree. * code that doesn't meet current metrics can and should be technically vetoed. Again, we should set these up to fail the build, using Checkstyle, PMD and Clirr. Of course, I'll incorporate this into the dev process after some discussion. Thoughts? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] site updates
+1 -Lukas Arnaud HERITIER wrote: Hi guys, I would like to inform you and have your feedback about some changes I'm preparing to apply on the m1 web site. I added a homepage for the plugins in /maven-1.x/plugins/ http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/ And I created a subdirectory for each plugins category to store the multiprojects (/maven-1.x/plugins/bundled/ instead of /maven-1.x/reference/plugins/ and /maven-1.x/plugins/sandbox/ instead of /maven-1.x/sandbox/) http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/bundled/ http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/sandbox/ I also moved all plugins sites (bundled and sandbox) under the directory plugins (we don't have to move the site if we promote or decommision a plugin) http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/ant/ I'll update the rewritting rules to redirect /maven-1.x/sandbox and /maven-1.x/reference/plugins (already done) to the new directories. All breadcrumbs are fixed and follow this layout : Apache - Maven - Maven 1.x - Plugins - Bundled or Sandbox - A_Plugin Breadcrumbs are also used in the page title. The external links are fixed and are displayed only if the host is different from the one of the project's site. I also removed links in the maven-1.x site (and in its plugins) to the Maven projects (continuum, JXR, ...) because it was very too long with the breadcrumbs. On the other hand I updated our menu and the projects page : http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/project/index.html Cheers Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHANGELOG-75) Date pasing errors in plugins using CVS
[ http://jira.codehaus.org/browse/MPCHANGELOG-75?page=comments#action_60327 ] Lukas Theussl commented on MPCHANGELOG-75: -- You can make an upload request for cvslib-4.1 (or 5.0?) and we'll test it. I don't think it will make it into 1.1b3 though as we have a lot of other priorities still. In particular, a better use of Maven's scm code is planned for another changelog-plugin release before 1.1-final. Which version of cvs are you using? It seems that this issue only happens for certain cvs versions (see also MAVEN-1447), so just upgrading cvs might be a simpler solution? Date pasing errors in plugins using CVS --- Key: MPCHANGELOG-75 URL: http://jira.codehaus.org/browse/MPCHANGELOG-75 Project: maven-changelog-plugin Type: Bug Environment: Debian Sarge, Ubuntu Hoary, CVS 1.12.9 on the server Reporter: Peter Tillemans Apparently the date format change applied to CVS a while back continues to wreak havoc. I found the following mail very instructive (and fixed my issues): The problems with cvs date handling reported in http://jira.codehaus.org/browse/MAVEN-1447 have been fixed in netbeans version 4.1 http://www.netbeans.org/source/browse/javacvs/libsrc/org/netbeans/lib/cvsclient/command/log/LogInformation.java?r1=1.15r2=1.16 The current maven-1.1.-beta-2 is still shipping with a jar called cvslib-3.6.jar If one copies the ide5/modules/org-netbeans-lib-cvsclient.jar from a netbeans 4.1 installation to ~/.maven/repository/netbeans/jars/cvslib-3.6.jar then the problem goes away. Hope this helps Tim Pizey It does help. I have been looking in JIRA, but I found all tickets related to this issue as being closed, So I log this ticket as a reminder to maybe update the dependencies to use the newer library. I apologize beforehand if this already has been done. Just for good measure, here is a typical stack dump : java.lang.Exception: Couldn't parse date 2005-09-19 09:07:43 + at org.netbeans.lib.cvsclient.util.BugLog.bug(BugLog.java:58) at org.netbeans.lib.cvsclient.command.log.LogInformation$Revision.setDateString(LogInformation.java:382) at org.netbeans.lib.cvsclient.command.log.LogBuilder.processRevisionDate(LogBuilder.java:273) at org.netbeans.lib.cvsclient.command.log.LogBuilder.parseLine(LogBuilder.java:134) at org.netbeans.lib.cvsclient.command.BuildableCommand.messageSent(BuildableCommand.java:86) at org.netbeans.lib.cvsclient.event.MessageEvent.fireEvent(MessageEvent.java:96) at org.netbeans.lib.cvsclient.event.EventManager.fireCVSEvent(EventManager.java:107) at org.netbeans.lib.cvsclient.response.MessageTaggedResponse.process(MessageTaggedResponse.java:39) at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:485) at org.netbeans.lib.cvsclient.Client.processRequests(Client.java:439) at org.netbeans.lib.cvsclient.command.log.LogCommand.execute(LogCommand.java:132) at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:533) at org.apache.maven.cvslib.CvsConnection.executeCommand(CvsConnection.java:90) at org.apache.maven.cvslib.CvsConnection.processCommand(CvsConnection.java:421) at org.apache.maven.cvslib.CvsChangeLogGenerator.getEntries(CvsChangeLogGenerator.java:100) at org.apache.maven.changelog.ChangeLog.generateEntries(ChangeLog.java:239) at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:214) 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.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:92) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233
[jira] Commented: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project
[ http://jira.codehaus.org/browse/MAVEN-1741?page=comments#action_60337 ] Lukas Theussl commented on MAVEN-1741: -- There was actually an issue open for that: MPHTMLXDOC-6, which I closed as won't fix, but I am not so sure on that anymore. I'll leave this one open for the moment as I think there is a legitimate bug somewhere buried here: prereqs seem to be called once only as long as you don't call attainGoal somewhere in between - I'll try to construct a simple test case. Just for reference: see also my struggles at MPXDOC-181. maven 1.1 fails to run commons-attributes in mutliproject mode on a war project --- Key: MAVEN-1741 URL: http://jira.codehaus.org/browse/MAVEN-1741 Project: Maven Type: Bug Versions: 1.1-beta-2 Reporter: nicolas de loof Priority: Minor Attachments: test_maven11_commons-attributes.zip Attached zip contains a minimalist multiproject using commons-attributes that demonstrates the bug. - head (top level project) - jar (minimalist jar project) : Sample.java has a java.util.Date attribute - war (minimalist war project) : Sample.java has a java.util.Date attribute When runing maven war:install on war project, attributes are generated as expected. When running from head project using maven multiproject:install, commons-attributes are - generated as expected for the jar - NOT generated in the war (no log from plugin) I don't know if this is a maven, multiproject-plugin, war-plugin or commons-attributes-plugin bug. Please notice commons-attributes plugin uses a preGoal to automatically register itself. -- 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: (MPCHANGELOG-75) Date pasing errors in plugins using CVS
[ http://jira.codehaus.org/browse/MPCHANGELOG-75?page=all ] Lukas Theussl updated MPCHANGELOG-75: - Description: Apparently the date format change applied to CVS a while back continues to wreak havoc. I found the following mail very instructive (and fixed my issues): The problems with cvs date handling reported in http://jira.codehaus.org/browse/MAVEN-1447 have been fixed in netbeans version 4.1 http://www.netbeans.org/source/browse/javacvs/libsrc/org/netbeans/lib/cvsclient/command/log/LogInformation.java?r1=1.15r2=1.16 The current maven-1.1.-beta-2 is still shipping with a jar called cvslib-3.6.jar If one copies the ide5/modules/org-netbeans-lib-cvsclient.jar from a netbeans 4.1 installation to ~/.maven/repository/netbeans/jars/cvslib-3.6.jar then the problem goes away. Hope this helps Tim Pizey It does help. I have been looking in JIRA, but I found all tickets related to this issue as being closed, So I log this ticket as a reminder to maybe update the dependencies to use the newer library. I apologize beforehand if this already has been done. Just for good measure, here is a typical stack dump : java.lang.Exception: Couldn't parse date 2005-09-19 09:07:43 + at org.netbeans.lib.cvsclient.util.BugLog.bug(BugLog.java:58) at org.netbeans.lib.cvsclient.command.log.LogInformation$Revision.setDateString(LogInformation.java:382) at org.netbeans.lib.cvsclient.command.log.LogBuilder.processRevisionDate(LogBuilder.java:273) at org.netbeans.lib.cvsclient.command.log.LogBuilder.parseLine(LogBuilder.java:134) at org.netbeans.lib.cvsclient.command.BuildableCommand.messageSent(BuildableCommand.java:86) at org.netbeans.lib.cvsclient.event.MessageEvent.fireEvent(MessageEvent.java:96) at org.netbeans.lib.cvsclient.event.EventManager.fireCVSEvent(EventManager.java:107) at org.netbeans.lib.cvsclient.response.MessageTaggedResponse.process(MessageTaggedResponse.java:39) at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:485) at org.netbeans.lib.cvsclient.Client.processRequests(Client.java:439) at org.netbeans.lib.cvsclient.command.log.LogCommand.execute(LogCommand.java:132) at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:533) at org.apache.maven.cvslib.CvsConnection.executeCommand(CvsConnection.java:90) at org.apache.maven.cvslib.CvsConnection.processCommand(CvsConnection.java:421) at org.apache.maven.cvslib.CvsChangeLogGenerator.getEntries(CvsChangeLogGenerator.java:100) at org.apache.maven.changelog.ChangeLog.generateEntries(ChangeLog.java:239) at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:214) 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.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:92) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
[jira] Moved: (MSUREFIRE-75) NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar
[ http://jira.codehaus.org/browse/MSUREFIRE-75?page=all ] Lukas Theussl moved MPTEST-60 to MSUREFIRE-75: -- Workflow: Maven (was: jira) Key: MSUREFIRE-75 (was: MPTEST-60) Project: Maven 2.x Surefire Plugin (was: maven-test-plugin) NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar - Key: MSUREFIRE-75 URL: http://jira.codehaus.org/browse/MSUREFIRE-75 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Olivier Lamy Attachments: pom.xml, pom.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Add Torbjørn Smørgrav as Mav en-SCM committer
+1 Lukas Emmanuel Venisse wrote: Hi I'd want to add Torbjørn Smørgrav as Maven-SCM committer. He's the maintainer of bazaar scm provider and have done a good work on it and TCK. He want to maintain it in next year (at least). Here my +1 Emmanuel
Re: [vote] [m1] plugin releases
+2 For the ejb plugin I'd also prefer a minor version (1.7.2) and there are a few problems on the site to fix: the 'Task' menu entry does not exist and the linkcheck report shows some non-existent test classes in the checkstyle pages. I think this should be resolved if you use the latest checkstyle SNAPSHOT. -Lukas Stephane Nicoll wrote: Hi, Please vote on the release of the following m1 plugins: [] maven-ejb-plugin-1.8 [] maven-ear-plugin-1.8 The EJB plugin has simply a dependency convergence for maven 1.1 (MAVEN-1712). Regarding EAR plugin, it has been updated following the move of the J2EE plugin to the sandbox so it's now ready. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~snicoll/maven-ejb-plugin/ http://people.apache.org/~snicoll/maven-ear-plugin/ Vote closes in 72h. Here's my +1 Thanks, Stéphane -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 Lukas Jason van Zyl wrote: Hi, I just wanted to close this up as I think it's a good idea and anything that let's people manage their mail better IMO is a good thing. +1 In this type of vote it is non-technical so simple majority wins, but if it's close we can continue the discussion but I think a majority wanted preferred the separation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl closed MPASPECTJ-17: -- Resolution: Fixed Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- 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: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl closed MPASPECTJ-24: -- Resolution: Fixed failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- 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: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl closed MPASPECTJ-19: -- Resolution: Fixed Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPDASHBOARD-36) Add three jelly scripts JavaNCSS aggregators
[ http://jira.codehaus.org/browse/MPDASHBOARD-36?page=comments#action_59628 ] Lukas Theussl commented on MPDASHBOARD-36: -- Miguel, that's great, thanks a lot! However, we'd also need corresponding docs (in xdocs/) and tests (in src/plugin-test/) to go with your files. Could you provide these patches? Add three jelly scripts JavaNCSS aggregators Key: MPDASHBOARD-36 URL: http://jira.codehaus.org/browse/MPDASHBOARD-36 Project: maven-dashboard-plugin Type: New Feature Reporter: Miguel Fernandez Attachments: javancssccn.zip JavaNCSS aggregator: Extracts the average of CCN from JavaNCSS raw file. JavaNCSS aggregator: Calculate the pass rate of functions with a ccn less than 10 of CCN from JavaNCSS raw file. JavaNCSS aggregator: Extracts the number of functions with a ccn greater than 10 of CNN from JavaNCSS raw 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven-SCM 1.0 final
+1 Lukas Emmanuel Venisse wrote: Hi everyone, I'd like to release 1.0 final of Maven-SCM. All APIs are stable since a long time and we didn't find any blocker issues since 1.0-beta-2 release. The list of issues fixed are : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10527fixfor=12346 We have now 3 issues that i will fix before the release. I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, Emmanuel
Re: [vote] Release maven-deploy-plugin 2.2
+1 Lukas John Casey wrote: Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-1749) ant:echo throws StackOverflowError after migrating from 1.0.2 to 1.1-beta-2
[ http://jira.codehaus.org/browse/MAVEN-1749?page=all ]
Lukas Theussl closed MAVEN-1749:
Resolution: Won't Fix
The problem is the following line:
version =
${version.major}.${version.minor}.${version.patch}${version.snapshot}
which is a recursive definition of a property, see MPJAVA-28.
You should rename some of your properties, in particular also those that
contain a '-', see MAVEN-410.
ant:echo throws StackOverflowError after migrating from 1.0.2 to 1.1-beta-2
---
Key: MAVEN-1749
URL: http://jira.codehaus.org/browse/MAVEN-1749
Project: Maven
Type: Bug
Components: jelly/ant integration
Versions: 1.1-beta-2
Environment: Microsoft Windows 2000 [Version 5.00.2195]
java version 1.4.2_03
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
Reporter: Philipp Jardas
Attachments: test.zip
I don't exactly know whether this is a Maven or a Jelly issue. I'll post it
here anyway, hoping that knowing people will redirect it. =)
After migrating from Maven 1.0.2 to 1.1-beta-2 each and every invocation of
ant:echo within a plugin causes the error stated below.
{code:title=Output of maven -X}
BUILD FAILED
File.. C:\Dokumente und
Einstellungen\Jardas\.maven\cache\maven-java-plugin-1.5\plugin.jelly
Element... ant:echo
Line.. 43
Column -1
java.lang.reflect.InvocationTargetException
org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal
[java:compile] -- C:\Dokumente und
Einstellungen\Jardas\.maven\cache\maven-java-plugin-1.5\plugin.jelly:43:-1:
ant:echo null
at org.apache.maven.werkz.Goal.fire(Goal.java:663)
at org.apache.maven.werkz.Goal.attain(Goal.java:592)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:511)
at org.apache.maven.cli.App.main(App.java:1258)
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 com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
org.apache.commons.jelly.JellyTagException: C:\Dokumente und
Einstellungen\Jardas\.maven\cache\maven-java-plugin-1.5\plugin.jelly:43:-1:
ant:echo null
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:178)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109)
at org.apache.maven.werkz.Goal.fire(Goal.java:656)
at org.apache.maven.werkz.Goal.attain(Goal.java:592)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:511)
at org.apache.maven.cli.App.main(App.java:1258)
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
[result] [vote] [m1] plugin releases
Hi, We have 5 binding +1s (John, Jason, Emmanuel, Arnaud, Lukas) and one non-binding (Stephane), except one -0 for scm from Emmanuel. Here is the vote thread: http://www.nabble.com/-vote-m1-plugin-releases-t1158833.html#a3041603 I will proceed with the releases, also for scm for the reasons I stated before and also because I will be away for a couple of weeks now. Thanks, Lukas Lukas Theussl wrote: Hi, Please vote on the release of the following m1 plugins: [] maven-artifact-plugin-1.8 [] maven-jxr-plugin-1.5 [] maven-scm-plugin-1.6 The artifact and scm releases are necessary now that the repository and release plugins are demoted, the jxr plugin was just waiting for the first JXR release, which is now available. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ Vote closes in 72h. +1 Thanks, -Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.8-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPTEST-29) Missing formatter's extension
[ http://jira.codehaus.org/browse/MPTEST-29?page=all ] Lukas Theussl updated MPTEST-29: Assign To: (was: Jason van Zyl) Fix Version: 1.8 Need to document maven.test.reportsDirectory. Missing formatter's extension - Key: MPTEST-29 URL: http://jira.codehaus.org/browse/MPTEST-29 Project: maven-test-plugin Type: Bug Environment: XP Reporter: Dan Tran Fix For: 1.8 I would like to taylor my test report file name using my own setting of extension. Maven-test-pluggin hides that capability. How about add another property called maven.test.formatter.extention and pass it to junit task? -- 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: (MPCHANGELOG-83) NPE error if developer's id is missing
[ http://jira.codehaus.org/browse/MPCHANGELOG-83?page=all ] Lukas Theussl updated MPCHANGELOG-83: - Fix Version: 1.9.1 NPE error if developer's id is missing -- Key: MPCHANGELOG-83 URL: http://jira.codehaus.org/browse/MPCHANGELOG-83 Project: maven-changelog-plugin Type: Bug Versions: 1.9 Environment: tested on Linux, fecora core 3, Maven 1.1.beta2 Reporter: mike niemaz Priority: Minor Fix For: 1.9.1 Attachments: stack.txt If you forget to specify a developer id in project.xml, the changelog plugin will generates a dirty NullPointerException such as: Unable to obtain goal [site] -- /home/xxx/.maven/cache/maven-changelog-plugin-1.9/plugin.jelly:148:15: changelog:changelog null -- 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: (MPASPECTJ-15) Add property that define output folder for aspectj:compile goal.
[ http://jira.codehaus.org/browse/MPASPECTJ-15?page=all ] Lukas Theussl updated MPASPECTJ-15: --- Fix Version: (was: 3.3) 4.0 Add property that define output folder for aspectj:compile goal. Key: MPASPECTJ-15 URL: http://jira.codehaus.org/browse/MPASPECTJ-15 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Alexey Dashkevich Fix For: 4.0 Attachments: aspectj-patch-dash-20041203.zip, aspectj-test-case-dash-20041203.zip, aspectj.mpaspectj15.patch, mpaspectj-15.txt, patch.txt It will be good to have property for destination folder for compiled sources. It will be very helpful when you have aspects only for unit tests and don't wont to have weaved classes in classes folder. I propose to use property with name maven.aspectj.dest that by default will set to maven.build.dest. I have attached patch where added proposed property and test case that use this property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-14) Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory.
[ http://jira.codehaus.org/browse/MPASPECTJ-14?page=all ]
Lukas Theussl updated MPASPECTJ-14:
---
Fix Version: (was: 3.3)
4.0
Unable to weave only sources defined in argument files. Error during
compilation if argument file contains file from sourceDirectory.
-
Key: MPASPECTJ-14
URL: http://jira.codehaus.org/browse/MPASPECTJ-14
Project: maven-aspectj-plugin
Type: Bug
Versions: 3.2
Reporter: Alexey Dashkevich
Fix For: 4.0
Attachments: aspectj-patch-dash-20041130.zip,
aspectj-test-case-dash-20041130.zip, aspectj.mpaspectj14.patch, patch.txt
Some days ago I have started to use aspectj plugin for compilation
aspects. I use aspects only for tests. I have following structure in
project:
-src
|
aspectj - aspect sources
|
java - application sources
|
test - test sources
I have an lst file where defined what files should be compiled with
aspects e.g.:
com/toplinkmapping/UserRoleAspect.java
../java/com/toplinkmapping/UserRole.java
I want compile only files that defined in lst file and place classes
into test-classes folder. In project.properties I have defined
following properties:
maven.aspectj.source=1.4
maven.aspectj.argfiles=src/aspectj/aspects.lst
But when I have executed aspectj:compile I have error because this
task try to compile files from aspects.lst file and then from src/java
folder. And error occur because in aspects.lst defined files from java source
folder.
I have resolved this problem in my maven.xml by following way:
postGoal name=test:compile
ant:path id=build.dest location=${maven.build.dest}/
maven:addPath id=maven.dependency.classpath refid=build.dest/
ant:path id=maven.compile.src.set/
attainGoal name=aspectj:compile/
/postGoal
So as you can see I have overwrite maven.compile.src.set path that
not so good.
I think it will be good if will be introduced new property
like maven.aspectj.src.argfilesOnly that if true then only sources that
defined in argument files will be weaved. And following changes in plugin
script are needed e.g.:
from
ant:sourceroots
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
to
ant:sourceroots
j:if test=${context.getVariable('maven.aspectj.src.argfilesOnly')
!= 'true'}
ant:path refid=${sourcePathRefid}/
/j:if
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
I have attached patch and test case for it. Please, take a look at them.
--
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: (MPASPECTJ-16) aspectj:compile also compiles java files in CVS/Base
[ http://jira.codehaus.org/browse/MPASPECTJ-16?page=all ]
Lukas Theussl updated MPASPECTJ-16:
---
Fix Version: (was: 3.3)
4.0
aspectj:compile also compiles java files in CVS/Base
Key: MPASPECTJ-16
URL: http://jira.codehaus.org/browse/MPASPECTJ-16
Project: maven-aspectj-plugin
Type: Bug
Versions: 3.2
Reporter: Brian Jacobsen
Priority: Minor
Fix For: 4.0
When using the aspect:compile goal we receive a lot of errors, because the
jelly plugin also tries to compile java sources in CVC/Base directory.
---
xxx\CVS\Base\Yyy.java:82 error The constructor ZzzException(String,
NamingException) is undefined
throw new ZzzException(test, e);
xxx\CVS\Base\zzzException.java:6 error The type zzzException is already
defined
public class ZzzException extends Exception {
---
Suggested fix:
Use ant:srcdir instead of ant:sourceroots or make it possible to specify the
preferred behaviour with a property.
!--
ant:sourceroots
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
--
ant:srcdir
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:srcdir
Or perhaps it is possible to bypass the problem in another way?
regards
Brian
--
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: (MPASPECTJ-23) Report for the plugin
[ http://jira.codehaus.org/browse/MPASPECTJ-23?page=all ] Lukas Theussl updated MPASPECTJ-23: --- Fix Version: (was: 3.3) 4.0 Report for the plugin - Key: MPASPECTJ-23 URL: http://jira.codehaus.org/browse/MPASPECTJ-23 Project: maven-aspectj-plugin Type: Wish Reporter: Shinobu Kawai Yoshida Priority: Trivial Fix For: 4.0 Attachments: MPASPECTJ-23.patch, MPASPECTJ-23.xdocs.patch It would be great if there was a report feature to the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl updated MPASPECTJ-24: --- Fix Version: (was: 3.3) 4.0 failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- 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] Reopened: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl reopened MPASPECTJ-24: failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- 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] Reopened: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl reopened MPASPECTJ-19: Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl reopened MPASPECTJ-17: Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- 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: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl updated MPASPECTJ-17: --- Fix Version: (was: 3.3) 4.0 Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- 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: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl updated MPASPECTJ-19: --- Fix Version: (was: 3.3) 4.0 Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-20) aspectj:compile bug when using jdk 1.5
[ http://jira.codehaus.org/browse/MPASPECTJ-20?page=all ] Lukas Theussl reopened MPASPECTJ-20: aspectj:compile bug when using jdk 1.5 -- Key: MPASPECTJ-20 URL: http://jira.codehaus.org/browse/MPASPECTJ-20 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Fix For: 4.0 When using a jdk1.5 version and trying to weave classes, when using StringBuffer in source code, aspectj cannot compile the source code. The only solution is to download the last version of aspectj ( 1.5.0 ) from eclipse web site and change the jars in the .maven/repository/aspectj/jars folder. Now i have a warning saying that my version of aspectj is not 1.2 but 1.5 but i can compile without errors. So is it possible to update the aspectj jars to the 1.5.0 version ?? Stéphane -- 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: (MPASPECTJ-20) aspectj:compile bug when using jdk 1.5
[ http://jira.codehaus.org/browse/MPASPECTJ-20?page=all ] Lukas Theussl closed MPASPECTJ-20: -- Resolution: Fixed aspectj:compile bug when using jdk 1.5 -- Key: MPASPECTJ-20 URL: http://jira.codehaus.org/browse/MPASPECTJ-20 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Fix For: 4.0 When using a jdk1.5 version and trying to weave classes, when using StringBuffer in source code, aspectj cannot compile the source code. The only solution is to download the last version of aspectj ( 1.5.0 ) from eclipse web site and change the jars in the .maven/repository/aspectj/jars folder. Now i have a warning saying that my version of aspectj is not 1.2 but 1.5 but i can compile without errors. So is it possible to update the aspectj jars to the 1.5.0 version ?? Stéphane -- 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: (MPXDOC-91) bundled css files contain no filter tokens for ui property values
[ http://jira.codehaus.org/browse/MPXDOC-91?page=all ] Lukas Theussl closed MPXDOC-91: --- Resolution: Won't Fix It is now possible to use your own custom themes, see the maven.xdoc.theme.file and maven.xdoc.theme.url properties. bundled css files contain no filter tokens for ui property values - Key: MPXDOC-91 URL: http://jira.codehaus.org/browse/MPXDOC-91 Project: maven-xdoc-plugin Type: Bug Environment: linux Reporter: David Weinkauf the maven-base.css, maven-theme.css and print.css files currently in CVS and distributed with the latest version (1.6) appear to not have any filter tokens for the properties set in ui.properties and, as a result, any user-defined xdoc ui properties are not set in the CSS files. -- 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: (MPJAR-47) Documentation mentions nonexistent properties
[ http://jira.codehaus.org/browse/MPJAR-47?page=all ] Lukas Theussl closed MPJAR-47: -- Resolution: Fixed Fix Version: 1.8 Documentation mentions nonexistent properties - Key: MPJAR-47 URL: http://jira.codehaus.org/browse/MPJAR-47 Project: maven-jar-plugin Type: Bug Versions: 1.7 Reporter: Scott Lamb Fix For: 1.8 Trivial fix, really annoying. I spent a while wondering why maven.jar.include.source wasn't working. Finally, I looked at the plugin.properties and plugin.jelly and realized it didn't exist at all. There's been a patch to add it for a year (MPJAR-32), but it isn't applied. If it's not going to be, then the documentation should be reverted. There seem to be others like this, too. I don't see any occurence of maven.jarResources.basedir or maven.jar.resources.set. These docs really need to be accurate. -- 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: (MPJAR-32) Add the ability to include the source code in the jar
[ http://jira.codehaus.org/browse/MPJAR-32?page=all ] Lukas Theussl closed MPJAR-32: -- Resolution: Won't Fix This functionality is now provided by the maven-source-plugin. Add the ability to include the source code in the jar - Key: MPJAR-32 URL: http://jira.codehaus.org/browse/MPJAR-32 Project: maven-jar-plugin Type: New Feature Reporter: dion gillard Assignee: Jason van Zyl Priority: Minor Attachments: jar-source.txt, jar-source2.txt, jar-source3.txt, jar-source4.txt Often projects ship jars that include the source code, for convenience, or use in an IDE. This patch adds: - a plugin property, maven.jar.include.source, defaulted to false, that is used to decide whether source is included in the jar - a plugin property, maven.jar.source.path, defaulted to 'src', which is the location of the source in the jar - a goal to copy source into the maven.build.dest directory before jar'ing. -- 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: (MPJAR-3) Add ability to include user specified Manifest entries.
[ http://jira.codehaus.org/browse/MPJAR-3?page=all ] Lukas Theussl closed MPJAR-3: - Resolution: Fixed Patch was apparently applied a long time ago, only the docs were forgotten ... Add ability to include user specified Manifest entries. --- Key: MPJAR-3 URL: http://jira.codehaus.org/browse/MPJAR-3 Project: maven-jar-plugin Type: Improvement Reporter: Berin Loritsch Attachments: jar-plugin.diff, maven-jar-plugin.diff, properties-doc.diff The current JAR plugin provides you with a number of neat options for standardizing all the information in the JARs it creates. Unfortunately, there is no obvious way to add your own entries to it. There is also no support for sections. I have a patch that will allow all of this to happen--without sacrificing the standard JAR entries or current functionality. -- 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: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project
[ http://jira.codehaus.org/browse/MAVEN-1741?page=comments#action_59133 ] Lukas Theussl commented on MAVEN-1741: -- I think (I am not sure, I have to check the archives) that this is actually the intented behavior in maven 1.1. A pregoal is always only executed once in a build cycle, as you usually don't want the same pregoal executed several times from different goals to avoid overhead. If you want to make sure that a goal gets executed, you have to use the attainGoal tag. At least that's the behavior that I would expect. maven 1.1 fails to run commons-attributes in mutliproject mode on a war project --- Key: MAVEN-1741 URL: http://jira.codehaus.org/browse/MAVEN-1741 Project: Maven Type: Bug Versions: 1.1-beta-2 Reporter: nicolas de loof Priority: Minor Attachments: test_maven11_commons-attributes.zip Attached zip contains a minimalist multiproject using commons-attributes that demonstrates the bug. - head (top level project) - jar (minimalist jar project) : Sample.java has a java.util.Date attribute - war (minimalist war project) : Sample.java has a java.util.Date attribute When runing maven war:install on war project, attributes are generated as expected. When running from head project using maven multiproject:install, commons-attributes are - generated as expected for the jar - NOT generated in the war (no log from plugin) I don't know if this is a maven, multiproject-plugin, war-plugin or commons-attributes-plugin bug. Please notice commons-attributes plugin uses a preGoal to automatically register itself. -- 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: (MPJAVA-23) deprecation warnings are turned off by default, they should be on
[ http://jira.codehaus.org/browse/MPJAVA-23?page=all ] Lukas Theussl closed MPJAVA-23: --- Resolution: Fixed deprecation warnings are turned off by default, they should be on - Key: MPJAVA-23 URL: http://jira.codehaus.org/browse/MPJAVA-23 Project: maven-java-plugin Type: Improvement Reporter: dion gillard Assignee: Jason van Zyl Fix For: 1.6 When compiling code, deprecations should be obvious so that they can be minimised. -- 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: (MPJAVA-44) Create property to disable compilation warning
[ http://jira.codehaus.org/browse/MPJAVA-44?page=all ] Lukas Theussl closed MPJAVA-44: --- Resolution: Fixed Create property to disable compilation warning -- Key: MPJAVA-44 URL: http://jira.codehaus.org/browse/MPJAVA-44 Project: maven-java-plugin Type: New Feature Versions: 1.5 Reporter: Felipe Leme Priority: Minor Fix For: 1.6 Original Estimate: 30 minutes Remaining: 30 minutes Ant's javac task has the nowarn option, which suppress compilations warnings. We should offer this propery on the plugin as well, as sometimes the compilation generates so many warnings that is hard to find the erros (that happens specially while using the eclipse JDT compiler). -- 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: (MPJAVA-26) java plugin doc lacks default values for many entries
[ http://jira.codehaus.org/browse/MPJAVA-26?page=all ] Lukas Theussl closed MPJAVA-26: --- Resolution: Won't Fix Fix Version: (was: 1.6) The default values are usually the same as for the corresponding options of the javac ant task. There are links to the ant docs on the properties page. java plugin doc lacks default values for many entries - Key: MPJAVA-26 URL: http://jira.codehaus.org/browse/MPJAVA-26 Project: maven-java-plugin Type: Improvement Reporter: Jerome Lacoste Assignee: Jason van Zyl See http://maven.apache.org/reference/plugins/java/properties.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MCOMPILER-28) goal compile throws exception when src/main/java doesn't exist
[ http://jira.codehaus.org/browse/MCOMPILER-28?page=all ] Lukas Theussl moved MPASPECTJ-25 to MCOMPILER-28: - Workflow: Maven (was: jira) Key: MCOMPILER-28 (was: MPASPECTJ-25) Project: Maven 2.x Compiler Plugin (was: maven-aspectj-plugin) goal compile throws exception when src/main/java doesn't exist -- Key: MCOMPILER-28 URL: http://jira.codehaus.org/browse/MCOMPILER-28 Project: Maven 2.x Compiler Plugin Type: Bug Environment: linux Reporter: M. van der Plas I've create a profile in our companies generic root pom to use aspectj. In the configuration of the aspectj plugin I've added the goals compile and test-compile. Sometimes a project only consists of test classes, with the src/main/java directory non-existent. When the profile for these projects is activated, I get the exception listed below. Is it possible to ignore this exception ? ERROR] FATAL ERROR [INFO] [INFO] basedir D:\workspace\tracetest\src\main\java does not exist [INFO] [INFO] Trace java.lang.IllegalStateException: basedir D:\workspace\tracetest\src\main\java does not exist at org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542) at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1402) at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1368) at org.codehaus.mojo.aspectj.AjcHelper.getBuildFilesForSourceDirs(AjcHelper.java:137) at org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:272) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) 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:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) 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) -- 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: (MPJAVA-32) Support maven.compile.debuglevel property
[ http://jira.codehaus.org/browse/MPJAVA-32?page=all ] Lukas Theussl closed MPJAVA-32: --- Resolution: Fixed Support maven.compile.debuglevel property - Key: MPJAVA-32 URL: http://jira.codehaus.org/browse/MPJAVA-32 Project: maven-java-plugin Type: Improvement Reporter: Andrew Wason Fix For: 1.6 Support a maven.compile.debuglevel property that corresponds to the Ant javac task debuglevel (i.e. maps to javac -g:lines,vars,source). I normally build production code using lines,source and maven.compile.debug only lets me turn debug full on or full off. -- 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: (MPJAVA-41) Allow the generation of the compiler output report although compilation fails
[ http://jira.codehaus.org/browse/MPJAVA-41?page=all ] Lukas Theussl closed MPJAVA-41: --- Resolution: Fixed Introduced a maven.compile.failonerror property. Allow the generation of the compiler output report although compilation fails - Key: MPJAVA-41 URL: http://jira.codehaus.org/browse/MPJAVA-41 Project: maven-java-plugin Type: Improvement Versions: 1.6 Reporter: Carlos Sanchez Fix For: 1.6 -- 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: (MPJAVA-42) Generate files are not compiled if not generated files are not present
[ http://jira.codehaus.org/browse/MPJAVA-42?page=all ] Lukas Theussl closed MPJAVA-42: --- Resolution: Fixed Fix Version: 1.6 Generate files are not compiled if not generated files are not present -- Key: MPJAVA-42 URL: http://jira.codehaus.org/browse/MPJAVA-42 Project: maven-java-plugin Type: Bug Environment: Running maven rc4 with maven-javacc-plugin-1.1 and maven-javacc-plugin-1.4 Reporter: Kenneth Leider Priority: Minor Fix For: 1.6 Generated sources are placed in the target/generated-src/java/main directory, and this directory is added to maven.compile.src.set. However when the maven-java-plugin runs the compile goal, it skips compilation completely because the sourcesPresent variable is not true. I can only assume this variable is set if the sources listed in the pom resolve to files. -- 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: (MPJAVA-21) Unable to add something to java:compile classpath
[ http://jira.codehaus.org/browse/MPJAVA-21?page=all ] Lukas Theussl closed MPJAVA-21: --- Assign To: (was: Jason van Zyl) Resolution: Won't Fix Fix Version: (was: 1.6) I don't think it is a good idea to do that. Only things that are declared as dependencies should be added to the classpath, is there a reason for not adding those libs as dependencies? As a workaround, you may use the maven:addPath tag in a pregoal to java:compile. Unable to add something to java:compile classpath - Key: MPJAVA-21 URL: http://jira.codehaus.org/browse/MPJAVA-21 Project: maven-java-plugin Type: Wish Reporter: Stepan Koltsov Priority: Minor It is not possible to add anything to classpath used in java:compile in javac task. Its could be generated libraries (using XMLBeans for example) or other libraries stored somewhere in lib/ (we store some libraries in CVS, they are placed there). As workaround it's possible to edit maven.dependency.path, but that is dirty. Thanks. -- 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]
Re: sending JIRA mail to commits@maven.apache.org
-1 Anyone subscribed to the dev list should be interested in the evolution and development of the project (otherwise he wouldn't be subscribed). JIRA is a big part of that, it really belongs here. -Lukas Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3
+1 Lukas John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPCRUISECONTROL-34) FileNotFoundException with EmailPublisher
[ http://jira.codehaus.org/browse/MPCRUISECONTROL-34?page=all ] Lukas Theussl closed MPCRUISECONTROL-34: Resolution: Won't Fix Bug in CC that was fixed in version 2.3, see link above. FileNotFoundException with EmailPublisher - Key: MPCRUISECONTROL-34 URL: http://jira.codehaus.org/browse/MPCRUISECONTROL-34 Project: maven-cruisecontrol-plugin Type: Bug Versions: 1.7 Environment: CC 2.2.1 maven 1.0.2 plugin 1.7 linux Reporter: Michael Mattox Attachments: config.xml, cruisecontrol.log When I use the config.xml generated by the plugin I get the attached config.xml the output contains FileNotFoundExceptions. I searched the mailing list and found one other person with these exceptions but no replies. :( -- 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: (MPSCM-67) scm:prepare-release fails because project.xml has been locally modified
[ http://jira.codehaus.org/browse/MPSCM-67?page=all ] Lukas Theussl updated MPSCM-67: --- Fix Version: (was: 1.6) I'd like to release this week. scm:prepare-release fails because project.xml has been locally modified --- Key: MPSCM-67 URL: http://jira.codehaus.org/browse/MPSCM-67 Project: maven-scm-plugin Type: Bug Versions: 1.5 Environment: Windows XP, Maven 1.0.2, Sun JDK 1.4.2_08, CVSNT 2.0.51 on localhost, maven-release-plugin-1.4.1 Reporter: Dennis Lundberg Assignee: Lukas Theussl Attachments: MPSCM-67-2.patch, MPSCM-67.patch This is weird. When I try to prepare a release using maven scm:prepare-release it complains that project.xml has been locally modified. Well, it's supposed to change that's the idea of running scm:prepare-release, right? Anyway, if I manually check in the modified project.xml and run the command again it succeeds. Let me know if you need more information. Here's the output I get: -- G:\cvs\dennislundberg-codegeneration-HEADmaven scm:prepare-release __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: scm:find-connection: [echo] Using connection: scm|cvs|pserver|[EMAIL PROTECTED]|C:/Program/cvsnt/repositories|dennislundberg-codegeneration scm:parse-connection: [echo] Using SCM method: cvs [echo] Using CVSROOT: :pserver:[EMAIL PROTECTED]:C:/Program/cvsnt/repositories [echo] Using module: dennislundberg-codegeneration scm:check-deprecated-cvs-vars: scm:prepare-release: [echo] Verifying no modifications are present [INFO] Executing: cvs -f -n -q update -d [INFO] Working directory: G:\cvs\dennislundberg-codegeneration-HEAD What is the new tag name? RELEASE-2_8 What is the new version? [RELEASE-2_8] 2.8 [echo] Updating POM with version 2.8; tag RELEASE-2_8 [echo] Committing descriptors [echo] Tagging source tree [WARNING] Unknown status: '? '. [WARNING] Unknown status: '? '. Provider message: The cvs tag command failed. Command output: cvs server: project.xml is locally modified cvs [server aborted]: correct the above errors first! BUILD FAILED File.. C:\Documents and Settings\dlg01\.maven\cache\maven-scm-plugin-1.5\plugin.jelly Element... scm:tag Line.. 244 Column 189 Error! Total time: 29 seconds Finished at: Mon Sep 26 17:25:24 CEST 2005 -- 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: (MPJXR-3) Uses pom.build.sourceDirectory instead of maven.compile.src.set
[ http://jira.codehaus.org/browse/MPJXR-3?page=all ]
Lukas Theussl closed MPJXR-3:
-
Resolution: Fixed
Fix Version: 1.5
Uses pom.build.sourceDirectory instead of maven.compile.src.set
---
Key: MPJXR-3
URL: http://jira.codehaus.org/browse/MPJXR-3
Project: maven-jxr-plugin
Type: Bug
Reporter: Vincent Massol
Fix For: 1.5
I believe this is also true for several other plugins (javadoc, etc). This
means that if you use something like:
path id=maven.j2ee.compile.src.set
location=${pom.build.sourceDirectory}/../j2ee${cactus.j2ee.version}/
maven:addPath id=maven.compile.src.set
refid=maven.j2ee.compile.src.set/
it won't work with several plugins...
I'm starting to think that allowing multiple source directories in
project.xml wouldn't be so bad at all and that there are valid cases (I
believe Cactus is one - I'm happy to discuss that though).
Thanks
-Vincent
--
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]
[vote] [m1] plugin releases
Hi, Please vote on the release of the following m1 plugins: [] maven-artifact-plugin-1.8 [] maven-jxr-plugin-1.5 [] maven-scm-plugin-1.6 The artifact and scm releases are necessary now that the repository and release plugins are demoted, the jxr plugin was just waiting for the first JXR release, which is now available. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ Vote closes in 72h. +1 Thanks, -Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.8-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] plugin releases
I don't know, is it a big difference to the beta-2s we have now? The scm plugin is rather crucial as none of the published versions work with namespaces in poms, see http://jira.codehaus.org/browse/MPRELEASE-16. I view this as a bug fix release mainly, I expect another release for maven 1.1-final as the general scm compliance will have to be reviewed. -Lukas dan tran wrote: maven-scm-api and providers will be 1.0 in a couple of weeks. Isn't it worth to wait for that release first for maven-scm-plugin? -D On 2/20/06, John Casey [EMAIL PROTECTED] wrote: +1 Lukas Theussl wrote: Hi, Please vote on the release of the following m1 plugins: [] maven-artifact-plugin-1.8 [] maven-jxr-plugin-1.5 [] maven-scm-plugin-1.6 The artifact and scm releases are necessary now that the repository and release plugins are demoted, the jxr plugin was just waiting for the first JXR release, which is now available. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ Vote closes in 72h. +1 Thanks, -Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion= 1.8-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMULTIPROJECT-59) Multiproject plugin problem in Maven 1.1-betaX
[ http://jira.codehaus.org/browse/MPMULTIPROJECT-59?page=comments#action_59072 ] Lukas Theussl commented on MPMULTIPROJECT-59: - I cannot reproduce this with current maven 1.1-beta-3 trunk. Running multiproject:install on your test project installs both the jar and ejb into my local repo (I had to remove some dependencies that could not be downloaded though). Maybe this is fixed with MPARTIFACT-51? Multiproject plugin problem in Maven 1.1-betaX -- Key: MPMULTIPROJECT-59 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-59 Project: maven-multiproject-plugin Type: Bug Environment: Win2000 Professional SP3 Maven 1.1-beta1 and Maven1.1-beta2 java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) Classic VM (build 1.4.1, J2RE 1.4.1 IBM Windows 32 build cn1411-20031011 (JIT enabled: jitc)) Reporter: Oddmar Sandvik Fix For: 1.5 Attachments: project_root.xml, project_sub1.xml, project_sub2.xml A multiproject that works fine in Maven 1.02 fails in 1.1-betaX. The first project always runs fine. The second project seems to fail after uploading the jar to the repository. Even if I switch the order of the projects or remove some of them, the second seems to fail always. maven multiproject:install Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settings\AB36632\.maven\cache\maven-artifact-plugin-1.6\plugin.jelly:73:9: artifact:artifact-install Error getting the project as a string See the stack trace below. If I go to the subproject in question and run maven, it works fine. (Default goal is set in project.xml). One item to note is that the defaultGoal is different in different projects, i.e. jar:install and ejb:install. As is, this is a complete showstopper for Maven 1.1-betaX. Stack trace: org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [multiproject:install] -- C:\Documents and Settings\AB36632\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly:218:9: maven:reactor Reactor subproject failure occurred at org.apache.maven.werkz.Goal.fire(Goal.java:663) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: C:\Documents and Settings\AB36632\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly:218:9: maven:reactor Reactor subproject failure occurred at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:378) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109) at org.apache.maven.werkz.Goal.fire(Goal.java:656) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:210) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109) at org.apache.maven.werkz.Goal.fire(Goal.java:656) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79
[jira] Closed: (MPJAVA-38) sourceModifications handled incorrectly when more than one clause present
[ http://jira.codehaus.org/browse/MPJAVA-38?page=all ]
Lukas Theussl closed MPJAVA-38:
---
Resolution: Fixed
Fix Version: 1.6
sourceModifications handled incorrectly when more than one clause present
-
Key: MPJAVA-38
URL: http://jira.codehaus.org/browse/MPJAVA-38
Project: maven-java-plugin
Type: Bug
Versions: 1.5
Reporter: Simon Kitching
Fix For: 1.6
Attachments: sourceModifications.patch
The loop
j:forEach var=sm items=${pom.build.sourceModifications}
ant:available property=classPresent classname=${sm.className}/
is flawed. When the class is not present, the available action does NOT
reset $classPresent to a false value; instead, its previous value is left
unaltered (ie is the value from the previous time around the loop).
So a sourceModified clause with a classname that is present will cause all
following sourceModified clauses to be skipped, regardless of whether their
test class is present or not.
The following ant file demonstrates this nicely:
project name=foo default=def basedir=.
target name=def
echoav: ${av}/echo
available property=av classname=dafasfas/
echoav: ${av}/echo
available property=av classname=java.lang.String/
echoav: ${av}/echo
available property=av classname=no.such.class/
echoav: ${av}/echo
/target
/project
perhaps simply inserting an assignment to reset the variable to false
immediately before the ant:available test will fix this?
--
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: (MPJAVA-39) Plug-in ignores source generated during Maven run
[ http://jira.codehaus.org/browse/MPJAVA-39?page=all ] Lukas Theussl closed MPJAVA-39: --- Resolution: Duplicate Plug-in ignores source generated during Maven run - Key: MPJAVA-39 URL: http://jira.codehaus.org/browse/MPJAVA-39 Project: maven-java-plugin Type: Bug Environment: Windows XP SP2; JDK 1.5; Maven 1.0.2; Reporter: Guy Rixon Priority: Critical My project generates its Java source-code and then tries to compile it: I have a custom goal that does both in one run of Maven . The java plug-in ignores the generated source and claims that there are no Java files to compile. If I run java:compile again, without cleaning the directory,then the plug-in notices the source-code and compiles it. It looks like the check for files to compile is done when Maven starts, not when the goals in the Java plug-in are run. This is a BAD design decision and is causing me real grief. Please support generated code. -- 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: (MPJAVA-4) Compile fails using forked compiler when directory contains spaces
[ http://jira.codehaus.org/browse/MPJAVA-4?page=all ] Lukas Theussl closed MPJAVA-4: -- Resolution: Fixed Fix Version: 1.6 Should be fixed now as Maven 1.1 comes with ant 1.6.5. Compile fails using forked compiler when directory contains spaces -- Key: MPJAVA-4 URL: http://jira.codehaus.org/browse/MPJAVA-4 Project: maven-java-plugin Type: Bug Environment: Windows NT Reporter: Michael Brown Fix For: 1.6 Running the java:compile goal usually runs fine. However, if you want to fork it to use another java compiler, the compile fails since javac treats the first section of the source directory as an argument. Thus a project under 'c:\project\my project' fails with the error 'javac: invalid argument: c:\project\my' I tried to look and see what's causing this, but couldn't figure out why the directory was treated differently when forked. -- 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: (MPJAVA-30) Compiling gives incorrect warning about target JVM version
[ http://jira.codehaus.org/browse/MPJAVA-30?page=all ] Lukas Theussl closed MPJAVA-30: --- Resolution: Fixed Fix Version: 1.6 Compiling gives incorrect warning about target JVM version -- Key: MPJAVA-30 URL: http://jira.codehaus.org/browse/MPJAVA-30 Project: maven-java-plugin Type: Bug Versions: 1.5 Reporter: Ross Burnett Priority: Minor Fix For: 1.6 Original Estimate: 5 minutes Remaining: 5 minutes Compiling Java code with: - maven-java-plugin-1.5 - JDK1.4.2 - no value set for maven.compile.target - no value set of maven.compile.source leads to the following message: == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == I believe this is incorrect - the compilation will target whatever JVM is the default setting for that javac (1.2 in the case of a 1.4 JDK). Running the compiled unit tests on a 1.3 JVM succeeds. I suggest that the note be removed. The plugin could emit a more accurate message if it maintained a map of which target applies by default for each JVM, but that seems like overkill. Setting maven.compile.target supresses the message. -- 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: (MPJAVA-31) please add a property for the encoding of the java:compile goal
[ http://jira.codehaus.org/browse/MPJAVA-31?page=all ] Lukas Theussl closed MPJAVA-31: --- Resolution: Won't Fix Use the maven.compile.encoding property. please add a property for the encoding of the java:compile goal --- Key: MPJAVA-31 URL: http://jira.codehaus.org/browse/MPJAVA-31 Project: maven-java-plugin Type: Improvement Reporter: christian koestlin -- 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: (MPJAVA-32) Support maven.compile.debuglevel property
[ http://jira.codehaus.org/browse/MPJAVA-32?page=all ] Lukas Theussl updated MPJAVA-32: Fix Version: 1.6 Support maven.compile.debuglevel property - Key: MPJAVA-32 URL: http://jira.codehaus.org/browse/MPJAVA-32 Project: maven-java-plugin Type: Improvement Reporter: Andrew Wason Fix For: 1.6 Support a maven.compile.debuglevel property that corresponds to the Ant javac task debuglevel (i.e. maps to javac -g:lines,vars,source). I normally build production code using lines,source and maven.compile.debug only lets me turn debug full on or full off. -- 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: (MPJAVA-21) Unable to add something to java:compile classpath
[ http://jira.codehaus.org/browse/MPJAVA-21?page=all ] Lukas Theussl updated MPJAVA-21: Fix Version: 1.6 Unable to add something to java:compile classpath - Key: MPJAVA-21 URL: http://jira.codehaus.org/browse/MPJAVA-21 Project: maven-java-plugin Type: Wish Reporter: Stepan Koltsov Assignee: Jason van Zyl Priority: Minor Fix For: 1.6 It is not possible to add anything to classpath used in java:compile in javac task. Its could be generated libraries (using XMLBeans for example) or other libraries stored somewhere in lib/ (we store some libraries in CVS, they are placed there). As workaround it's possible to edit maven.dependency.path, but that is dirty. Thanks. -- 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: (MPJAVA-44) Create property to disable compilation warning
[ http://jira.codehaus.org/browse/MPJAVA-44?page=all ] Lukas Theussl updated MPJAVA-44: Fix Version: 1.6 Create property to disable compilation warning -- Key: MPJAVA-44 URL: http://jira.codehaus.org/browse/MPJAVA-44 Project: maven-java-plugin Type: New Feature Versions: 1.5 Reporter: Felipe Leme Priority: Minor Fix For: 1.6 Original Estimate: 30 minutes Remaining: 30 minutes Ant's javac task has the nowarn option, which suppress compilations warnings. We should offer this propery on the plugin as well, as sometimes the compilation generates so many warnings that is hard to find the erros (that happens specially while using the eclipse JDT compiler). -- 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: (MAVEN-1747) ear:ear doesn't work with symbolic links in repository for libaries
[ http://jira.codehaus.org/browse/MAVEN-1747?page=all ]
Lukas Theussl closed MAVEN-1747:
Resolution: Won't Fix
This has been fixed in ear plugin 1.7, please upgrade and check. See the links
given at MPEAR-37, in particular MPEAR-36.
ear:ear doesn't work with symbolic links in repository for libaries
---
Key: MAVEN-1747
URL: http://jira.codehaus.org/browse/MAVEN-1747
Project: Maven
Type: Bug
Versions: 1.0.2
Environment: ubuntu / linux
Reporter: Andreas Ebbert-Karroum
I am trying to assemble an ear file with maven 1.0.2 on linux. The problem is
that I have a lot of dependencies, which have to go into the ear file as
libraries, which have to be downloaded from the web and manually added to the
repository.
I did this with symbolic links under linux, and this is causing problems for
the ear:ear goal. The below mentioned oss_common_spec-1.2.jar is copied to
the repository for testing purposes (it was a link previously), the
oss_cbe_service_spec is a symbolic link. I couldn't find any open bug report
for this behaviour.
The problem is - as far as I can tell - that the test
j:if
test=${!(checkFile.getAbsolutePath().equals(checkFile.getCanonicalPath()))}
Doesn't work for symbolic links.
Here's the output from the build:
ear:ear:
[echo] Building EAR oss_sa_ri_ear-1.2 with appxml
/home/andreas/Documents/Development/java.net/ossj/service_activation/root/../ri/app/target/application.xml
[echo] Bundling: jar - ossj:oss_common_spec - 1.2
[echo] Dependency oss_common_spec-1.2.jar will be bundled as
/oss_common_spec-1.2.jar
[copy] Copying 1 file to
/home/andreas/Documents/Development/java.net/ossj/service_activation/ri/app/target/tmpEarDeps
BUILD FAILED
File..
/home/andreas/Documents/Development/java.net/ossj/service_activ
ation/root/maven.xml
Element... m:reactor
Line.. 28
Column 131
Unable to obtain goal [ear:ear] --
/home/andreas/.maven/cache/maven-ear-plugin-1.6/plugin.jelly:99:24:
ant:fail Case-sensitive issue: The dependency ossj:oss_cbe_service_spec
has a case problem. The dependency was either retrieved in the past with
the wrong case or has been specified with the wrong case in your project.xml
file.
Fix your project.xml or update your local repository with the properly-cased
file and try again.
Total time: 10 seconds
Finished at: Wed Feb 08 09:37:32 CET 2006
--
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: (MPREPO-10) create-upload-bundle doesn't resolve extension
[ http://jira.codehaus.org/browse/MPREPO-10?page=comments#action_58823 ] Lukas Theussl commented on MPREPO-10: - Why are you posting this here? This has nothing to do with the problem that the issue was opend for. - Please only post to JIRA if you are sure that you have found a bug, otherwise ask on the mailing list first. - The repositor plugin has recently been deprecated, it is not officially maintained by us anymore. - The error that you get suggests that you forgot to set the maven.username property. create-upload-bundle doesn't resolve extension -- Key: MPREPO-10 URL: http://jira.codehaus.org/browse/MPREPO-10 Project: maven-repository-plugin Type: Bug Versions: 1.2 Reporter: Carlos Sanchez Priority: Blocker Use the same procedure as in deploy goals to create a temporary self contained 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] Commented: (MAVEN-1746) StackOverflowError
[ http://jira.codehaus.org/browse/MAVEN-1746?page=comments#action_58824 ]
Lukas Theussl commented on MAVEN-1746:
--
Could it be related to MAVEN-1745?
StackOverflowError
--
Key: MAVEN-1746
URL: http://jira.codehaus.org/browse/MAVEN-1746
Project: Maven
Type: Bug
Versions: 1.0.2
Environment: Which.version=Which.java:($Revision: 1.2 $)
WhichJar.java:($Revision: 1.2 $)
java.version=1.5.0_06
file.encoding=Cp1252
java.ext.dirs=D:\Program Files\Java\jdk1.5.0_06\jre\lib\ext
java.class.path=D:\maven-1.0.2\maven-1.0.2\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=D:\maven-1.0.2\maven-1.0.2\lib\endorsed\xerces-2.4.0.jar;D:\
maven-1.0.2\maven-1.0.2\lib\endorsed\xml-apis-1.0.b2.jar;D:\Program
Files\Java\j
dk1.5.0_06\jre\lib\rt.jar;D:\Program
Files\Java\jdk1.5.0_06\jre\lib\i18n.jar;D:\
Program Files\Java\jdk1.5.0_06\jre\lib\sunrsasign.jar;D:\Program
Files\Java\jdk1
.5.0_06\jre\lib\jsse.jar;D:\Program
Files\Java\jdk1.5.0_06\jre\lib\jce.jar;D:\Pr
ogram Files\Java\jdk1.5.0_06\jre\lib\charsets.jar;D:\Program
Files\Java\jdk1.5.0
_06\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
Installed plugins:
maven-abbot-plugin-1.1
maven-announcement-plugin-1.3
maven-ant-plugin-1.8.1
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4.1
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.2
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5.1
maven-checkstyle-plugin-2.5
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.6
maven-dashboard-plugin-1.6
maven-developer-activity-plugin-1.5.1
maven-dist-plugin-1.6.1
maven-docbook-plugin-1.2
maven-ear-plugin-1.6
maven-eclipse-plugin-1.9
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5.1
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.2
maven-html2xdoc-plugin-1.3.1
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5.1
maven-jalopy-plugin-1.3.1
maven-jar-plugin-1.6.1
maven-java-plugin-1.5
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.7
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.9
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3.1
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.2
maven-jnlp-plugin-1.4.1
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.2
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.4
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.2.1
maven-plugin-plugin-1.5.2
maven-pmd-plugin-1.6
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4.1
maven-repository-plugin-1.2
maven-scm-plugin-1.4.1
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.2
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6.1
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Home Build properties: {maven.repo.list=brink,
maven.multiproject.topwebmodule=m
ecp-web/, maven.multiproject.includes=mecp/project.xml,mecp-web/project.xml,
mav
en.announcement.mail.server=mail.micc.lk, jmeter.config.mecpuser=admin,
maven.wa
r.src=web, [EMAIL PROTECTED], maven.announcement.mail.
[EMAIL PROTECTED],[EMAIL PROTECTED], jmeter.config.mecp.initContex
t=org.jnp.interfaces.NamingContextFactory,
maven.repo.remote=http://192.168.1.28
:9090/MavenCache/repository/,http://217.212.21.5/maven/,
maven.multiproject.base
dir=D:/work/, maven.multiproject.topmodule=mecp/,
maven.announcement.stylesheet.
path=${basedir}/../commons/announcement.jsl, maven.test.skip=true,
jmeter.config
.targetserver=localhost,
maven.checkstyle.header.file=${basedir}/../commons/LICE
NSE.txt, maven.license.licenseFile=${basedir}/../commons/LICENSE.txt,
jmeter.con
fig.mecp.url=localhost:1099, maven.repo.brink=ftp://217.212.21.5,
maven.announce
ment.mail.passwordFileName=micc_mail.conf, maven.repo.brink.password=maven,
mecp
.test.outputdir=d:/temp, maven.repo.brink.username=maven,
jmeter.config.protocol
=http, maven.announcement.mail.subject=[YANR] ${pom.name} %VERSION% released,
ma
ven.multiproject.excludes=site/*,commons/*,,
maven.checkstyle.properties=${based
ir}/../commons/mecp_checks.xml,
jmeter.config.mecp.pkgPrefix=org.jboss.naming:or
[jira] Commented: (MPCLOVER-54) Can't connect to X11 window server when trying to to generate clover historic data
[ http://jira.codehaus.org/browse/MPCLOVER-54?page=comments#action_58825 ] Lukas Theussl commented on MPCLOVER-54: --- Can you try to upgrade your clover plugin? 1.8 is rather old, the last version is 1.11. Can't connect to X11 window server when trying to to generate clover historic data -- Key: MPCLOVER-54 URL: http://jira.codehaus.org/browse/MPCLOVER-54 Project: maven-clover-plugin Type: Bug Versions: 1.11 Environment: AIX, JDK1.4.2, CruiseControl-2.3.1, maven-1.0.2 Reporter: Shahzad Chaudhry Attachments: stack.txt When trying to generate historical data clover report complains about connection to X11 window server. Have already tried: -Djava.awt.headless=true set the value of DISPLAY but nothing seems to work. I have come against a wall and would really appricate a solution. Thanks in advance. Regards, Shaz -- 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] Reopened: (MPXDOC-181) xdoc:init is called 6 times
[ http://jira.codehaus.org/browse/MPXDOC-181?page=all ] Lukas Theussl reopened MPXDOC-181: -- *sigh* xdoc:init is called 6 times --- Key: MPXDOC-181 URL: http://jira.codehaus.org/browse/MPXDOC-181 Project: maven-xdoc-plugin Type: Improvement Reporter: Lukas Theussl Assignee: Lukas Theussl Fix For: 1.10 Running xdoc once results in the xdoc:init goal being called 6 (six!) times via various prereqs. This has a negative performance effect on goals that are attained within a preGoal of xdoc:init, like eg html2xdoc. -- 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: (MPXDOC-181) xdoc:init is called 6 times
[ http://jira.codehaus.org/browse/MPXDOC-181?page=all ] Lukas Theussl closed MPXDOC-181: Resolution: Won't Fix Fix Version: (was: 1.10) I had to roll back my 'fix' for this as it broke projects that declared pre-/post goals on any of the modified goals. I don't see a proper way to fix this, apart from doing it in the core (MAVEN-256). xdoc:init is called 6 times --- Key: MPXDOC-181 URL: http://jira.codehaus.org/browse/MPXDOC-181 Project: maven-xdoc-plugin Type: Improvement Reporter: Lukas Theussl Assignee: Lukas Theussl Running xdoc once results in the xdoc:init goal being called 6 (six!) times via various prereqs. This has a negative performance effect on goals that are attained within a preGoal of xdoc:init, like eg html2xdoc. -- 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: (MAVEN-1520) maven:makeRelativePath tag is borked
[ http://jira.codehaus.org/browse/MAVEN-1520?page=all ]
Lukas Theussl closed MAVEN-1520:
Resolution: Fixed
Done.
maven:makeRelativePath tag is borked
Key: MAVEN-1520
URL: http://jira.codehaus.org/browse/MAVEN-1520
Project: Maven
Type: Bug
Components: core
Versions: 1.0.1
Environment: Reactor Build
Reporter: Hiram Chirino
Fix For: 1.1-beta-3
Noticed the problem when the eclipse plugin started breaking a little.
I added some dubug lines to it's jelly file:
maven:makeRelativePath var=srcDir basedir=${basedir} path=${res}
separator=//
ant:echoBase DIR: ${basedir}, SRC DIR: ${srcDir}, RES ${res}/ant:echo
Running that resulted in:
[echo] Base DIR: C:\sandbox\activemq\modules\core, SRC DIR:
C:/sandbox/activemq/src/conf, RES src/conf
I would have expectd srcDir to be
C:/sandbox/activemq/modules/core/src/conf not C:/sandbox/activemq/src/conf
--
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: (MPREPO-9) create-upload-bundle deficiencies
[ http://jira.codehaus.org/browse/MPREPO-9?page=all ] Lukas Theussl closed MPREPO-9: -- Resolution: Fixed This was fixed after the goal was moved to the artifact plugin. create-upload-bundle deficiencies - Key: MPREPO-9 URL: http://jira.codehaus.org/browse/MPREPO-9 Project: maven-repository-plugin Type: Bug Versions: 1.2 Reporter: Andy Jefferson Using maven 1.0.1 and the 1.2 version of the repository plugin. I have a project that has a top level that contains the LICENSE.txt, and project.xml with the currentVersion,groupId. This has subprojects that reference the toplevel project.xml (and so have the same version and groupId). When I call maven create-upload-bundle in the subproject there are 2 issues 1. It cant find LICENSE.txt. This is not specifiable via a property either. 2. When it overcomes the first issue (by manual copying of the LICENSE) it creates the bundle jar but this just contains the project.xml from that subproject (which doesnt have the groupId, currentVersion). Would be great if we can get this plugin usable in such a multiproject situation. Let me know if you need any more info. -- 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: (MPREPO-10) create-upload-bundle doesn't resolve extension
[ http://jira.codehaus.org/browse/MPREPO-10?page=all ] Lukas Theussl closed MPREPO-10: --- Resolution: Fixed This was fixed after the goal was moved to the artifact plugin. create-upload-bundle doesn't resolve extension -- Key: MPREPO-10 URL: http://jira.codehaus.org/browse/MPREPO-10 Project: maven-repository-plugin Type: Bug Versions: 1.2 Reporter: Carlos Sanchez Priority: Blocker Use the same procedure as in deploy goals to create a temporary self contained 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] Moved: (MPARTIFACT-65) Document create-upload-bundle and probably rename to repository:create-upload-bundle
[ http://jira.codehaus.org/browse/MPARTIFACT-65?page=all ] Lukas Theussl moved MPREPO-11 to MPARTIFACT-65: --- Version: (was: 1.2) Key: MPARTIFACT-65 (was: MPREPO-11) Project: maven-artifact-plugin (was: maven-repository-plugin) Document create-upload-bundle and probably rename to repository:create-upload-bundle Key: MPARTIFACT-65 URL: http://jira.codehaus.org/browse/MPARTIFACT-65 Project: maven-artifact-plugin Type: Improvement Reporter: Carlos Sanchez Fix For: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPARTIFACT-65) Document artifact:create-upload-bundle
[ http://jira.codehaus.org/browse/MPARTIFACT-65?page=all ] Lukas Theussl updated MPARTIFACT-65: Fix Version: 1.8 Summary: Document artifact:create-upload-bundle (was: Document create-upload-bundle and probably rename to repository:create-upload-bundle) Document artifact:create-upload-bundle -- Key: MPARTIFACT-65 URL: http://jira.codehaus.org/browse/MPARTIFACT-65 Project: maven-artifact-plugin Type: Improvement Reporter: Carlos Sanchez Fix For: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r378351 - /maven/maven-1/core/trunk/xdocs/navigation.xml
After I added the sitemap, I found the links section a bit overloaded. I also think it's more logical to have these links on the main Maven site only, as Maven 1.X is just a sub-project now, among others. However, I don't feel too strong about it. Actually I just commented out the links instead of removing them because I thought you might want to put them back... ;) -Lukas Arnaud HERITIER wrote: Why did you remove links to continuum, SCM, ... ? It was to be similar to the m2 site. Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPARTIFACT-65) Document artifact:create-upload-bundle
[ http://jira.codehaus.org/browse/MPARTIFACT-65?page=all ] Lukas Theussl closed MPARTIFACT-65: --- Resolution: Fixed Document artifact:create-upload-bundle -- Key: MPARTIFACT-65 URL: http://jira.codehaus.org/browse/MPARTIFACT-65 Project: maven-artifact-plugin Type: Improvement Reporter: Carlos Sanchez Fix For: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-54) Navigation links broken with checkstyle 3.0 in multiproject build
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-54?page=comments#action_58878 ] Lukas Theussl commented on MPCHECKSTYLE-54: --- Actually I cannot reproduce this. I have tested with multiproject navigation = aggregate and independent and I don't see any broken links. Can you give a concrete example or attach a test page to illustrate the problem? Navigation links broken with checkstyle 3.0 in multiproject build - Key: MPCHECKSTYLE-54 URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-54 Project: maven-checkstyle-plugin Type: Bug Environment: m11b3 Reporter: Lukas Theussl Fix For: 3.0.1 From MPCHECKSTYLE-24: I have an issue with the new checkstyle plugin version (3.0) too when running in a multiproject build. The problem is, is that the checkstyle files are now by default generated under the /target/checkstyle dir. When the maven site is generated, the navigation links from the checkstyle pages are broken. This is because the navgation links are relative and the same navigation is applied to all docs for the maven site. In the case of the checkstyle files - which are one subdir deeper- the links are broken. Of course i could let checkstyle generate to another dir, but i think there's a bigger problem behind this one: How should navigation work for files in subdir and subdirs of subdirs, etc. -- 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]
Re: maven source plugin to core plugins
+1 -Lukas Stephane Nicoll wrote: Hi, I would like to move the maven source plugin from the sandbox to the core plugins. I just added a couple of tests. In the same time, we can release a 1.0 WDYT? Thanks, Stéphane -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-clean-plugin 2.1
+1 -Lukas John Casey (mergere) wrote: Hi, I wanted to call a vote to see if we can release a new version of the maven-clean-plugin for Maven 2. I've just added two features which were covered by two of the three outstanding jira issues - the final jira issue will have to wait for a new version of plexus-utils, and consequently, Maven (since the plexus-utils artifact is filtered out of the plugin's dependency list, and provided by maven's core). The two issues were: * MCLEAN-2: Allow configuration of filesets/ beyond the three main directories that are cleaned. * MCLEAN-4: Provide a flag and behavior to handle symbolic links (followSymLinks = true|false) Anyway, these are the only issues in the MCLEAN jira project, so if there have been other fixes, we have no record of them. I'll summarize in 72 hours. Please vote +1/0/-1. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release file-management in maven/shared 1.0
+1 -Lukas John Casey wrote: Hi again, I forgot to mention yesterday, when I called a vote for the maven-clean-plugin, that I had added a dependency on a shared library used for fileset management. This library is in the maven/shared SVN area, and will itself need a release before the maven-clean-plugin can be released. It's currently a replica of the fileset model from the maven-assembly-plugin, along with a manager class to handle interaction with plexus-utils (for DirectoryScanner and FileUtils). The code in this library is fairly well-tested, and fairly simple for now. I believe it's ready for a 1.0 release. +1/0/-1, and I'll leave it for 72 hours. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in html2xdoc
Nicolas, Here is the page that I generated from your index.xml: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/examples/ It looks ok to me, or am I missing something? -Lukas Nicolas De Loof wrote: I've set maven.docs.outputencoding = ISO-8859-1 I've tried to set LANG to fr_FR.ISO-8859-1 or fr_FR.UTF-8 without any result. http://jira.codehaus.org/browse/MPXDOC-184 seems to be similar, but the xml and html generated by xdoc plugin from POM are fine in my site. I attach the generated index.xml. I don't know the encoding that it uses and that produces this issue. When I open it using vi it is well displayed with a [converted] ont bottom line. When I use cat to dump the file I can't read the expected accents (replaced with a square on console). Other POM generated xdoc can be well displayed on my console. I've noticed html2xdoc produces a org.jdom.Document from original HTML. I don't understand how non ascii characters or HTML entities are copied to this new XML, that has default encoding (UTF-8 ?). As maven 1.1b2 uses dom4j-1.4 it cannot use the new setXMLEncoding method introduced in dom4j-1.6. Is there any plan to upgrade this dependency ? I've also noticed xdoc plugin source that it's DTD is expected to include html entities. Generated xdocs don't have reference to any DTD or schema and so cannot include HTML entities. Is this only expected for xdoc plugin 1.10 ? If this is the case, will html2xdoc be upgraded to convert non ascii chars to html entities ? Thanks for any help. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in html2xdoc
merci, mais c'est pas moi qui l'ai ecrit... ;) Stephane Nicoll wrote: Un p à aperçu ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in html2xdoc
Right, but those are already missing in the index.xml file. So I would need the original html file for generating the xml to see why they are missing... -Lukas Stephane Nicoll wrote: On 2/15/06, Lukas Theussl [EMAIL PROTECTED] wrote: Nicolas, Here is the page that I generated from your index.xml: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/examples/ It looks ok to me, or am I missing something? There's still missing characters at the bottom of the page. Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
