[jira] Commented: (MECLIPSE-104) Add the ability to specify source exclusions
[ http://jira.codehaus.org/browse/MECLIPSE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171004#action_171004 ] Richard van der Hoff commented on MECLIPSE-104: --- The problem I am facing is that some of the .java files in my source tree won't build against the dependency versions maven chooses for me. Unfortunately fixing this isn't an option. It would require moving lots of stuff around in CVS which I really don't have time for. The compiler plugin allows me to exclude classes with the tag. It therefore seems to make sense for the eclipse plugin to do so as well. > Add the ability to specify source exclusions > > > Key: MECLIPSE-104 > URL: http://jira.codehaus.org/browse/MECLIPSE-104 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: James Mitchell >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 2.7 > > Attachments: fix-eclipse-classpaths.sh, MECLIPSE-104.patch, > srcExclusions-patch.zip > > > When source files contain scm information (**/.svn/** or **/CVS/**), which is > pretty much a given, there's currently no way to specify that those > directories be excluded except through the GUI. This isn't so much of a > problem except that the next time a change is needed and this plugin is ran, > it will overwrite this exclusion and will force me to exclude it, by hand, > again. > The above case is the driving reason why I decided to get involved and help > out. So, I have written everything (I think) that is needed for this > enhancement including, adding to the javadoc, creating a new test that > verifies this enhancement, and fully testing this with my own projects (many > of them @ Struts). If there is anything else I need to do as far as site > documentation, please tell me where it is and I'll add it. > This is my first patch to Maven. If this sucks, please don't ignore it, just > say 'it sucks, no thanks" and I'll go about working on something else. > Thanks so much for your attention. > -- > James Mitchell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-104) Add the ability to specify source exclusions
[ http://jira.codehaus.org/browse/MECLIPSE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van der Hoff updated MECLIPSE-104: -- Attachment: MECLIPSE-104.patch Here is yet another version of this patch, updated to trunk as of 2009-03-26. > Add the ability to specify source exclusions > > > Key: MECLIPSE-104 > URL: http://jira.codehaus.org/browse/MECLIPSE-104 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: James Mitchell >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 2.7 > > Attachments: fix-eclipse-classpaths.sh, MECLIPSE-104.patch, > MECLIPSE-104.patch, srcExclusions-patch.zip > > > When source files contain scm information (**/.svn/** or **/CVS/**), which is > pretty much a given, there's currently no way to specify that those > directories be excluded except through the GUI. This isn't so much of a > problem except that the next time a change is needed and this plugin is ran, > it will overwrite this exclusion and will force me to exclude it, by hand, > again. > The above case is the driving reason why I decided to get involved and help > out. So, I have written everything (I think) that is needed for this > enhancement including, adding to the javadoc, creating a new test that > verifies this enhancement, and fully testing this with my own projects (many > of them @ Struts). If there is anything else I need to do as far as site > documentation, please tell me where it is and I'll add it. > This is my first patch to Maven. If this sucks, please don't ignore it, just > say 'it sucks, no thanks" and I'll go about working on something else. > Thanks so much for your attention. > -- > James Mitchell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-104) Add the ability to specify source exclusions
[ http://jira.codehaus.org/browse/MECLIPSE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171089#action_171089 ] Richard van der Hoff commented on MECLIPSE-104: --- Yes - just before patching the proposed 2.6 to fix the problem and uploading the patch here. As I mentioned before, I need to exclude some .java files from my build; including only "**/*.java" is therefore insufficient to resolve the issue. > Add the ability to specify source exclusions > > > Key: MECLIPSE-104 > URL: http://jira.codehaus.org/browse/MECLIPSE-104 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: James Mitchell >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 2.7 > > Attachments: fix-eclipse-classpaths.sh, MECLIPSE-104.patch, > MECLIPSE-104.patch, srcExclusions-patch.zip > > > When source files contain scm information (**/.svn/** or **/CVS/**), which is > pretty much a given, there's currently no way to specify that those > directories be excluded except through the GUI. This isn't so much of a > problem except that the next time a change is needed and this plugin is ran, > it will overwrite this exclusion and will force me to exclude it, by hand, > again. > The above case is the driving reason why I decided to get involved and help > out. So, I have written everything (I think) that is needed for this > enhancement including, adding to the javadoc, creating a new test that > verifies this enhancement, and fully testing this with my own projects (many > of them @ Struts). If there is anything else I need to do as far as site > documentation, please tell me where it is and I'll add it. > This is my first patch to Maven. If this sucks, please don't ignore it, just > say 'it sucks, no thanks" and I'll go about working on something else. > Thanks so much for your attention. > -- > James Mitchell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
[ http://jira.codehaus.org/browse/MNG-2221?page=comments#action_66721 ] Richard van der Hoff commented on MNG-2221: --- This must be the same issue as MNG-2297, no? > Multiple Executions of Plugin at Difference Inhertiance levels causes plugin > executions to run multiple times > - > > Key: MNG-2221 > URL: http://jira.codehaus.org/browse/MNG-2221 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Versions: 2.0.4 > Reporter: Stephen Duncan Jr > Priority: Critical > Fix For: 2.0.5 > Attachments: repeat-test.zip > > > Can occur in a variety of ways, but the attached test case shows a parent pom > defining an antrun-execution, and then a child specifying another execution > with a different id. Both executions run twice when running from the child. > I believe this is the same as Kenney Westerhof's comment: > http://jira.codehaus.org/browse/MNG-2054#action_62477 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2297) plugin definitions not merged correctly
[ http://jira.codehaus.org/browse/MNG-2297?page=all ] Richard van der Hoff updated MNG-2297: -- Attachment: maven-project-plugins.patch > plugin definitions not merged correctly > --- > > Key: MNG-2297 > URL: http://jira.codehaus.org/browse/MNG-2297 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0.4 > Reporter: Richard van der Hoff > Priority: Minor > Attachments: maven-project-plugins.patch, maven-project-plugins.patch > > > If both a parent, and a child plugin reference a plugin, the plugin > configuration is not merged correctly; instead, the child build ends up with > two copies of the plugin (with separate configuration and separate > executions). > The attachment contains a testcase demonstrating the problem, and fixes to > ModelUtils.java (against current trunk) to fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-130) Setting forkMode changes user.dir for multimodule projects
Setting forkMode changes user.dir for multimodule projects -- Key: MSUREFIRE-130 URL: http://jira.codehaus.org/browse/MSUREFIRE-130 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Richard van der Hoff Priority: Minor The working directory of tests on a submodule in a multimodule project is different dependeng on whether forkMode is enabled or not. When forkMode==never, the working directory is that of the top-level module; otherwise, it is set to the directory of the submodule. I know this is defined behaviour - but it has been suggested that it is unintuitive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-130) Setting forkMode changes user.dir for multimodule projects
[ http://jira.codehaus.org/browse/MSUREFIRE-130?page=comments#action_66913 ] Richard van der Hoff commented on MSUREFIRE-130: > if we were to do this, then the tests would behave differently based on > whether it were in a multi-module or run from the individual project. They do already, if forkMode==never. > The way it is, the individual project is always consistent, it's only the > fork modes which aren't. I'm not sure that's the case. Anyway, it's certainly true that you can't have it be intuitive both ways. I happen to think that leaving user.dir alone would be the lesser of two evils, but I'm not really that worried about it. > Setting forkMode changes user.dir for multimodule projects > -- > > Key: MSUREFIRE-130 > URL: http://jira.codehaus.org/browse/MSUREFIRE-130 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Richard van der Hoff > Priority: Minor > > > The working directory of tests on a submodule in a multimodule project is > different dependeng on whether forkMode is enabled or not. > When forkMode==never, the working directory is that of the top-level module; > otherwise, it is set to the directory of the submodule. > I know this is defined behaviour - but it has been suggested that it is > unintuitive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_66975 ]
Richard van der Hoff commented on MRELEASE-114:
---
Yes it is, and it's very annoying.
Sounds like a duplicate of MRELEASE-16 to me.
> ${project.artifactId} was replaced with it's value during release:perform
> -
>
> Key: MRELEASE-114
> URL: http://jira.codehaus.org/browse/MRELEASE-114
> Project: Maven 2.x Release Plugin
> Type: Bug
> Environment: Windows XP, Java 1.4.2
> Reporter: Paul Spencer
>
>
> In release:perform, the variable ${project.artifactId} was replaced with it's
> value in the connection and developerConnection tags in the pom. This did NOT
> happen in other place in the pom!
> Before release:
> scm:cvs:pserver:[EMAIL
> PROTECTED]:/bar:${project.artifactId}
> After release:
> scm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom
> BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
> related to the above problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_67151 ] Richard van der Hoff commented on MASSEMBLY-103: The compile-time error is due to source files which have been deleted... They're reduced to zero size by the patch, but not removed. Try: $ find src/main/java -name *.java -size 0 | xargs rm Regarding the patch problem; there have been a few changes to AssemblyMojoTest.java since I made that patch, but it still applies fine for me: $ svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin maven-assembly-plugin-trunk ... $ cd maven-assembly-plugin-trunk $ patch -p1 < ~/tmp/maven-assembly-plugin-filters.v2.patch patching file src/test/java/org/apache/maven/plugin/assembly/AssemblyMojoTest.java Hunk #1 succeeded at 286 (offset 3 lines). patching file src/test/plugin-configs/assembly/depSet-filter-plugin-config.xml patching file src/test/resources/assemblies/dependencySet-filter.xml patching file src/main/mdo/component.mdo patching file src/main/mdo/descriptor.mdo patching file src/main/java/org/apache/maven/plugin/assembly/filter/AssemblyExcludesArtifactFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/filter/ArtifactMatchFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/filter/CompoundArtifactFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/filter/AssemblyIncludesArtifactFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/filter/AssemblyScopeArtifactFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/filter/BaseArtifactFilter.java patching file src/main/java/org/apache/maven/plugin/assembly/AbstractAssemblyMojo.java patching file src/test/java/org/apache/maven/plugin/assembly/filter/ArtifactMatchFilterTest.java > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Type: New Feature > Versions: 2.1 > Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch, > maven-assembly-plugin-filters.v2.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-187) CVS changelog creates bad dates for CVS on linux
[ http://jira.codehaus.org/browse/SCM-187?page=comments#action_67650 ] Richard van der Hoff commented on SCM-187: -- evenisse and I had a fairly lengthy chat about this on #maven last week. It seems that just making this change may well break backwards compatibility with cvsnt. The current behaviour is certainly wrong, as it passes a quoted argument to System.exec(String[]). Under linux, the argument is passed straight through, without further modification, to the OS and thence to the cvs binary. Under Windows, if memory serves correctly, the String[] array is first joined into a single command line, and then split again by the cvs binary - this extra stage of joining/splitting allows the current broken behaviour to go unnoticed. That doesn't detract from the fact that the fix was put in, deliberately, to make the changelog command work with cvsnt. Without a windows development system handy, it's difficult for me to be exactly certain why it is needed. I suspect the problem lies with cvsnt (implying that the fix should stay in maven-scm-provider-cvs, modified to somehow not break linux - a slightly fudgy test of os.name may well be adequate) but it may also be in System.exec (suggesting a workaround is needed in plexus-cli), or somewhere else again. > CVS changelog creates bad dates for CVS on linux > > > Key: SCM-187 > URL: http://jira.codehaus.org/browse/SCM-187 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-cvs > Versions: 1.0-beta-2 > Environment: Linux > Reporter: Jimmy Larsson > Attachments: date_quoting_fix.patch > > > This is related to SCM-177. > SCM-177 presents a patch which fixes timezone problems with the dates sent to > the CVS command, but it also introduces a new bug. > With the current svn source I get commandlines like this when i try to get > changelogs with a startdate set: > cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/cvsroot -q log -d > '">2006-04-20T11:42:45+0200"' -rBRANCH_1_1 > The problem is that the date has two pairs of qoutes. From the comments on > SCM-177 it seems like this is not an issue on windows. I'm running linux and > my cvs command does not accept the date. > I'm not very used to creating patches but I'll try to create one that fixes > my problem and attach it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-215) Add ability to sanitise tag names
Add ability to sanitise tag names - Key: SCM-215 URL: http://jira.codehaus.org/browse/SCM-215 Project: Maven SCM Type: New Feature Components: maven-scm-api Versions: 1.0-beta-3 Reporter: Richard van der Hoff Attachments: maven-scm-tag-sanitation.patch In order to fix MRELEASE-110, the scm provider needs to provide a means of turning a potential tag into a valid one. This patch adds a method to the provider API to allow this; it also provides a suitable implementation for the cvs provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-110) release:prepare generates tags with dots, causing problems with CVS
[ http://jira.codehaus.org/browse/MRELEASE-110?page=all ] Richard van der Hoff updated MRELEASE-110: -- Attachment: maven-release-plugin-cvstag.patch > release:prepare generates tags with dots, causing problems with CVS > --- > > Key: MRELEASE-110 > URL: http://jira.codehaus.org/browse/MRELEASE-110 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: mvn 2.0.4 WinXP > Reporter: Marcel Schutte > Attachments: maven-release-plugin-cvstag.patch > > > When my project has version 01.02 release:prepare will suggest a tag > 'Mavenparent-01.02' even though the scm provider is CVS. This causes the tag > to fail and later on also a failure in release:perform. > The head version before the plugin rewrite had a special case to convert dots > to underscores. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-215) Add ability to sanitise tag names
[ http://jira.codehaus.org/browse/SCM-215?page=comments#action_67722 ] Richard van der Hoff commented on SCM-215: -- Hrm, could do. The main reason I didn't is that I couldn't see where to fit them in. Any suggestions? > Add ability to sanitise tag names > - > > Key: SCM-215 > URL: http://jira.codehaus.org/browse/SCM-215 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Versions: 1.0-beta-3 > Reporter: Richard van der Hoff > Attachments: maven-scm-tag-sanitation.patch > > > In order to fix MRELEASE-110, the scm provider needs to provide a means of > turning a potential tag into a valid one. > This patch adds a method to the provider API to allow this; it also provides > a suitable implementation for the cvs provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-215) Add ability to sanitise tag names
[ http://jira.codehaus.org/browse/SCM-215?page=all ] Richard van der Hoff updated SCM-215: - Attachment: maven-scm-tag-sanitation-tests.pach > Add ability to sanitise tag names > - > > Key: SCM-215 > URL: http://jira.codehaus.org/browse/SCM-215 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Versions: 1.0-beta-3 > Reporter: Richard van der Hoff > Attachments: maven-scm-tag-sanitation-tests.pach, > maven-scm-tag-sanitation.patch > > > In order to fix MRELEASE-110, the scm provider needs to provide a means of > turning a potential tag into a valid one. > This patch adds a method to the provider API to allow this; it also provides > a suitable implementation for the cvs provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-363) Some URLs incorrect when behind httpd with mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-363?page=comments#action_68067 ] Richard van der Hoff commented on CONTINUUM-363: this is a duplicate of CONTINUUM-240, I think > Some URLs incorrect when behind httpd with mod_proxy > > > Key: CONTINUUM-363 > URL: http://jira.codehaus.org/browse/CONTINUUM-363 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0-beta-1 > Reporter: David Blevins > > > Given a mod_proxy setup like: > > [...] > RewriteEngine on > RewriteRule ^/(.*)$ http://localhost:8080/$1 [p] > ProxyPassReverse / http://localhost:8080/ > > All the URLs but the various icon_foo_sml.gif icons will be hardcoded to the > localhost:8080 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-734) Can't use continuum behind https proxy
Can't use continuum behind https proxy
--
Key: CONTINUUM-734
URL: http://jira.codehaus.org/browse/CONTINUUM-734
Project: Continuum
Type: Bug
Components: Web interface
Versions: 1.0.3
Reporter: Richard van der Hoff
As noted in CONTINUUM-240, it's not currentlyy possible to run the continuum
webapp behind an https proxy, as all the links are http://...
My apache setup is something along the lines of:
{code:xml}
SSLEngine on
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost On
{code}
and my jetty config:
{code:xml}
8080
{code}
The links are correct, except that they have s/https/http/.
Why does the webapp need to use absolute links anyway?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_70051 ] Richard van der Hoff commented on MJAR-28: -- Baerrach, have you been able to make any progress on this? Did you get an answer to your questions regarding the best way to fix this? We're suffering the same problem and would like to find a fix :/ http://jira.codehaus.org/browse/MNG-775 might make fixing this the "right" way rather difficult :( > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_72292 ]
Richard van der Hoff commented on MASSEMBLY-67:
---
Is this supposed to work for current versions of the assembly plugin? I've
tried putting an outputFileNameMapping in my dependencySet, but it doesn't seem
to make any difference.
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Mark J. Titorenko
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_72301 ]
Richard van der Hoff commented on MASSEMBLY-67:
---
ah right, thanks. I'll look into rolling my own build of it then...
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Mark J. Titorenko
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-151) Incorrect name for test sources jars
Incorrect name for test sources jars Key: MECLIPSE-151 URL: http://jira.codehaus.org/browse/MECLIPSE-151 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Richard van der Hoff The eclipse plugin currently sets the source attachment of dependencies on test-jars (as created by the test-jar goal of the jar plugin) to the same as that of the main jar. To fix, we need to check the classifier of dependencies when finding sources, and if it is "tests", use "test-sources" rather than "sources" for the classifier on the sources jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-734) Can't use continuum behind https proxy
[ http://jira.codehaus.org/browse/CONTINUUM-734?page=comments#action_74745
]
Richard van der Hoff commented on CONTINUUM-734:
No; the Base URL is used when generating error report emails and so on, but not
when generating the page content.
> Can't use continuum behind https proxy
> --
>
> Key: CONTINUUM-734
> URL: http://jira.codehaus.org/browse/CONTINUUM-734
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.0.3
>Reporter: Richard van der Hoff
> Fix For: 1.1
>
>
> As noted in CONTINUUM-240, it's not currentlyy possible to run the continuum
> webapp behind an https proxy, as all the links are http://...
> My apache setup is something along the lines of:
> {code:xml}
>
> SSLEngine on
> ProxyPass / http://localhost:8080/
> ProxyPassReverse / http://localhost:8080/
> ProxyPreserveHost On
>
> {code}
> and my jetty config:
> {code:xml}
>
>
> 8080
>
>
> {code}
> The links are correct, except that they have s/https/http/.
> Why does the webapp need to use absolute links anyway?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-47) Ability to have an includes/excludes feature on the dependency:unpack goal.
[
http://jira.codehaus.org/browse/MDEP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90593
]
Richard van der Hoff commented on MDEP-47:
--
I suspect this won't be flexible enough for your needs, but when I was trying
to acheive something similar, rather than updating plexus-archiver, I had a
{{FilteringZipUnArchiver extends ZipUnArchiver}} which overrides {{execute()}}
and checks the name of each entry before extracting it.
Just in case the plexus-archiver upgrade is a real blocker, really.
Anyway, this would be handy for me.
> Ability to have an includes/excludes feature on the dependency:unpack goal.
> ---
>
> Key: MDEP-47
> URL: http://jira.codehaus.org/browse/MDEP-47
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
>Reporter: Paul Shemansky
> Assigned To: Brian Fox
>Priority: Minor
> Fix For: 2.0-alpha-4
>
>
> Perhaps there is another solution that I'm overlooking, and if so... I
> apologize, but in the dependency-maven-plugin's dependency:unpack goal, it
> would be quite convenient to have an option to have an includes/excludes
> capability which did pattern matched unpack resolutions. I.E. :
>
>
> *.class
>
>
> *.html
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-162) In a multiproject environment, assembly takes wrong dependencies
[
http://jira.codehaus.org/browse/MASSEMBLY-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91068
]
Richard van der Hoff commented on MASSEMBLY-162:
Sounds like the original issue has been resolved, but replaced with
MASSEMBLY-179.
could it be marked as such?
> In a multiproject environment, assembly takes wrong dependencies
>
>
> Key: MASSEMBLY-162
> URL: http://jira.codehaus.org/browse/MASSEMBLY-162
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: M. van Leeuwen
>Priority: Critical
> Fix For: 2.2
>
>
> With a projectstructure like 'Project/{ejb,war,ear,client}' packaging the
> client as a fat jar-with-dependencies, it works fine using the following
> configuration.
> === etc/fatjar.xml
> fat
> jar
> false
>
> target/classes
> /
>
>
>
> /
> true
> runtime
>
>
>
> === pom.xml ===
>
> 0.3-SNAPSHOT
> 4.0.0
> mygroup
> myapp-client
> My Application
>
>
>
>
>
>
> maven-assembly-plugin
> 2.1
>
>
> etc/fatjar.xml
>
>
> path.to.MainClass
>
>
>
> package
> assembly
>
>
>
>
>
> But when I'm on the level above (packaging all) it just assembles all
> underlying dependencies into my clientjar, and not the dependencies of the
> childproject.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-157) maven assembly plugin, includes/excludes in moduleSet
[
http://jira.codehaus.org/browse/MASSEMBLY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91069
]
Richard van der Hoff commented on MASSEMBLY-157:
if this is fixed, could it be marked as such?
> maven assembly plugin, includes/excludes in moduleSet
> --
>
> Key: MASSEMBLY-157
> URL: http://jira.codehaus.org/browse/MASSEMBLY-157
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Maven 2.0.4, JDK 6.0, assembly plugin
>Reporter: Łukasz Dywicki
>Priority: Minor
> Fix For: 2.2
>
>
> Hello everyone, I've some assembly descriptor with operations in modulesSet,
> but maven ignore my excludes/includes.
> I've got all modules in bin directory, all modules in modules ditectory and
> all modules in libs.
>
>
> package
> false
>
> zip
>
>
>
>
>
> modules/
> false
> false
>
>
> autoguard:autocontrol-core
>
>
>
>
>
>
> bin/
> false
> false
>
>
> autoguard:autocontrol-core
>
>
>
>
>
>
> libs/
> true
> false
>
>
> ${project.groupId}
>
>
>
>
>
>
>
> libs/
> false
> runtime
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-135) Clarify the addition of dependancies in assembly:assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91072 ] Richard van der Hoff commented on MASSEMBLY-135: Gwyn, do you still feel that the documentation is inadequate? I think it's been improved substantially since you first filed this report. Incidentally, you might have more luck googling for "dependency" if you spelt it right ;) > Clarify the addition of dependancies in assembly:assembly > - > > Key: MASSEMBLY-135 > URL: http://jira.codehaus.org/browse/MASSEMBLY-135 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: n/a >Reporter: Gwyn Evans > Fix For: 2.2 > > > It was unclear to me for quite a while that the assembly plugin could pack > dependancies The documentation suggested that it should, by default, do so, > but when trying wth the built-in "bin" descriptor, nothing happened. I > worked around it for a while by having the dependancy plugin copy the jars > into my target folder, until I came back to it today. > What I found was that if I took the built-in 'bin', created my own[1] and > simply added > > > > > then I got the behaviour I wanted. > I'd suggest two changes - (1) some comment (in the descriptor format > description) about how dependancies are not included without the above and > (2) an additional pre-defined descriptior, e.g. "bin-with-dependancies", as > that seems to be a common requirement, judging from the M2 mailing list. > /Gwyn > [1] By the way, I couldn't find any documentation that explained the correct > syntax for this - > http://maven.apache.org/plugins/maven-assembly-plugin/howto.html just uses > & > http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html > mentions be only by trial & error do you find what it should > contain (OK, convention suggests it would , but the description > said files, which I first read as the filepath & was marked as > depreciated. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-148) cannot handle files with same name in different directories. First file copied to all destinations.
[ http://jira.codehaus.org/browse/MASSEMBLY-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van der Hoff updated MASSEMBLY-148: --- Attachment: massembly-148.zip Here's an integration test for this issue. It works fine for me. Walt, are you still seeing this, and if so, can you modify my testcase to make it fail? > cannot handle files with same name in different directories. First > file copied to all destinations. > > > Key: MASSEMBLY-148 > URL: http://jira.codehaus.org/browse/MASSEMBLY-148 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Window XP, j2sdk1.4.2_09 >Reporter: Walt Barrow > Assigned To: Kenney Westerhof > Fix For: 2.2 > > Attachments: massembly-148.zip > > > Using an assembly descriptor with the following element: > > > configuration\pentaho.war\WEB-INF\jboss-web.xml > > jboss\server\default\deploy\pentaho.war\WEB-INF > true > > > > configuration\jboss-portal.sar\portal-server.war\WEB-INF\jboss-web.xml > > jboss\server\default\deploy\jboss-portal.sar\portal-server.war\WEB-INF > jboss-web.xml > true > > > ... the resulting assembly contains two identical copies of jboss-web.xml in > both target locations and both are identical to the first one specified. It > is as if the same file (the first one) is copied to both locations. If I > rename one of the files, then, of course, everything works fine. > The pom.xml I used looks like: > > 4.0.0 > pentaho > afscnPentahoApp > AFSCN Multiproject POM > 1.0 > pom > > components > portlets-jar > portlets-war > > > > c:/PentahoSource/filters/config.properties > > > > maven-assembly-plugin > > solution.xml > > > > > > ... and the directory structure looks like: > Top-Level > -- configuration > configuration\jboss-portal.sar\portal-server.war\WEB-INF\jboss-web.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-148) cannot handle files with same name in different directories. First file copied to all destinations.
[ http://jira.codehaus.org/browse/MASSEMBLY-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91087 ] Richard van der Hoff commented on MASSEMBLY-148: oh, i've just repeated it with assembly-2.1. I think we can assume this is fixed in 2.2. > cannot handle files with same name in different directories. First > file copied to all destinations. > > > Key: MASSEMBLY-148 > URL: http://jira.codehaus.org/browse/MASSEMBLY-148 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Window XP, j2sdk1.4.2_09 >Reporter: Walt Barrow > Assigned To: Kenney Westerhof > Fix For: 2.2 > > Attachments: massembly-148.zip > > > Using an assembly descriptor with the following element: > > > configuration\pentaho.war\WEB-INF\jboss-web.xml > > jboss\server\default\deploy\pentaho.war\WEB-INF > true > > > > configuration\jboss-portal.sar\portal-server.war\WEB-INF\jboss-web.xml > > jboss\server\default\deploy\jboss-portal.sar\portal-server.war\WEB-INF > jboss-web.xml > true > > > ... the resulting assembly contains two identical copies of jboss-web.xml in > both target locations and both are identical to the first one specified. It > is as if the same file (the first one) is copied to both locations. If I > rename one of the files, then, of course, everything works fine. > The pom.xml I used looks like: > > 4.0.0 > pentaho > afscnPentahoApp > AFSCN Multiproject POM > 1.0 > pom > > components > portlets-jar > portlets-war > > > > c:/PentahoSource/filters/config.properties > > > > maven-assembly-plugin > > solution.xml > > > > > > ... and the directory structure looks like: > Top-Level > -- configuration > configuration\jboss-portal.sar\portal-server.war\WEB-INF\jboss-web.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2915) No way to avoid adding artifactId to site urls
No way to avoid adding artifactId to site urls
--
Key: MNG-2915
URL: http://jira.codehaus.org/browse/MNG-2915
Project: Maven 2
Issue Type: Bug
Components: Sites & Reporting
Affects Versions: 2.0.5
Reporter: Richard van der Hoff
Currently, whenever a child pom inherits from a parent (and doesn't override
the relevant settings), both project.url and
project.distributionManagement.site.url have the name of the child artifact
appended.
It would be nice to be able to have something like
:code:
scpexe://host/blah/${project.artifactId}/${project.version}
:code:
and have this inherited to all child poms in the obvious way.
My usecase for this is that we have a single parent pom for all our projects,
with useful settings such as distributionManagement, and I'd like to be able to
deploy their sites to a single directory and have Apache generate me a
directory listing for all the child projects. However, I curently have no way
of releasing the parent project without obliterating the list of child projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-151) Incorrect name for test sources jars
[ http://jira.codehaus.org/browse/MECLIPSE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100853 ] Richard van der Hoff commented on MECLIPSE-151: --- To reiterate what Max said: please do consider this for 2.4, as (a) the bug is a complete nuisance, and if you don't fix it, we'll have to patch it locally again; (b) the patch is pretty small; (c) there are some lovely tests for it... > Incorrect name for test sources jars > > > Key: MECLIPSE-151 > URL: http://jira.codehaus.org/browse/MECLIPSE-151 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Richard van der Hoff >Assignee: fabrizio giustina > Fix For: 2.5 > > Attachments: maven-eclipse-plugin.patch > > > The eclipse plugin currently sets the source attachment of dependencies on > test-jars (as created by the test-jar goal of the jar plugin) to the same as > that of the main jar. > To fix, we need to check the classifier of dependencies when finding sources, > and if it is "tests", use "test-sources" rather than "sources" for the > classifier on the sources jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2915) No way to avoid adding artifactId to site urls
[
http://jira.codehaus.org/browse/MNG-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115385
]
Richard van der Hoff commented on MNG-2915:
---
We actually found a workaround for this problem in our particular usecase.
The main distributionManagement section in our parent-pom has the url ready to
be appended to by child poms, and the parent-pom also has a profile which
overrides it just for that one pom; thus:
{code:xml}
deploying-base-pom-itself
THIS-IS-base-pom
mx-release
scpexe://host/blah/base-pom
{code}
This profile is then enabled for the base pom by creating a file entitled
THIS-IS-base-pom.
I think this might also work for the scm url.
Obviously this becomes a less useful solution for deeper project heirarchies,
but it works pretty well for us.
> No way to avoid adding artifactId to site urls
> --
>
> Key: MNG-2915
> URL: http://jira.codehaus.org/browse/MNG-2915
> Project: Maven 2
> Issue Type: Improvement
> Components: Sites & Reporting
>Affects Versions: 2.0.5
>Reporter: Richard van der Hoff
>Priority: Minor
> Fix For: 2.1
>
>
> Currently, whenever a child pom inherits from a parent (and doesn't override
> the relevant settings), both project.url and
> project.distributionManagement.site.url have the name of the child artifact
> appended.
> It would be nice to be able to have something like
> :code:
> scpexe://host/blah/${project.artifactId}/${project.version}
> :code:
> and have this inherited to all child poms in the obvious way.
> My usecase for this is that we have a single parent pom for all our projects,
> with useful settings such as distributionManagement, and I'd like to be able
> to deploy their sites to a single directory and have Apache generate me a
> directory listing for all the child projects. However, I curently have no way
> of releasing the parent project without obliterating the list of child
> projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard van der Hoff updated MNG-2848:
--
Attachment: MNG-2848.patch
Here's a patch, against maven-core 2.0.8, which makes profile activation via
environment variables work.
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {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
[jira] Commented: (MNG-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118759 ] Richard van der Hoff commented on MNG-2276: --- See MNG-2848 for activating profiles via env vars. Activating profiles via properties defined in other profiles (as would be the case for defining a property in settings.xml) is a whole, more complicated, kettle of fish; i guess mvn 2.1 might look at this sort of thing... > profile activation by property doesn't work with properties defined in > settings. > > > Key: MNG-2276 > URL: http://jira.codehaus.org/browse/MNG-2276 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 2.1 > > > Activating a profile like below doesn't get activated unless the property is > set on the CLI. I need to have the property defined in the settings.xml so > it's always set. > > > prod > > > deploy-ct > > > Further, I noticed that if I set it so that the activation is like: > > > deploy-cttrue > > > The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It > is not active if I use "-Ddeploy-ct=false" but the settings descriptor says > that the existence of the property is only used if value is not set. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119616
]
Richard van der Hoff commented on MNG-2848:
---
Oops, this seems to have broken property passing in mvn exec:java - see MEXEC-41
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: Vincent Siveton
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {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
[jira] Updated: (MNG-3258) the command "mvn -help" should describe the usage of the maven help plugin
[ http://jira.codehaus.org/browse/MNG-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van der Hoff updated MNG-3258: -- Attachment: MNG-3258.patch I couldn't agree more with the fact that you can't drive the help plugin unless you know what you're looking for. How about the attached as a pointer to the relevant docs? > the command "mvn -help" should describe the usage of the maven help plugin > -- > > Key: MNG-3258 > URL: http://jira.codehaus.org/browse/MNG-3258 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7 >Reporter: Eirik Maus > Fix For: 2.0.x > > Attachments: MNG-3258.patch > > > The help system in maven (and any other program as well) is typically what > you use if you can't remember the syntax for a given command. The syntax for > the help plugin is, however no simpler than any other command, and I always > find myself ending up with searching google for info on how to use the help > system to find out how to use, for instance, the dependency plugin. > I have suggested a new goal "mvn help:help" in the help plugin to use for > getting info on how to use the help system. The same info should be printed > when a user types "mvn -help". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126987
]
Richard van der Hoff commented on MNG-2848:
---
Yes, agreed that this seems the most sensible approach for now.
Thanks for sorting this, guys.
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: John Casey
> Fix For: 2.0.9
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {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
[jira] Updated: (MECLIPSE-104) Add the ability to specify source exclusions
[ http://jira.codehaus.org/browse/MECLIPSE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van der Hoff updated MECLIPSE-104: -- Attachment: MECLIPSE-104.patch An updated version of the patch. It's pretty trivial, so it would be nice if it could be applied before it bitrots this time! :) > Add the ability to specify source exclusions > > > Key: MECLIPSE-104 > URL: http://jira.codehaus.org/browse/MECLIPSE-104 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: James Mitchell >Priority: Minor > Attachments: fix-eclipse-classpaths.sh, MECLIPSE-104.patch, > srcExclusions-patch.zip > > > When source files contain scm information (**/.svn/** or **/CVS/**), which is > pretty much a given, there's currently no way to specify that those > directories be excluded except through the GUI. This isn't so much of a > problem except that the next time a change is needed and this plugin is ran, > it will overwrite this exclusion and will force me to exclude it, by hand, > again. > The above case is the driving reason why I decided to get involved and help > out. So, I have written everything (I think) that is needed for this > enhancement including, adding to the javadoc, creating a new test that > verifies this enhancement, and fully testing this with my own projects (many > of them @ Struts). If there is anything else I need to do as far as site > documentation, please tell me where it is and I'll add it. > This is my first patch to Maven. If this sucks, please don't ignore it, just > say 'it sucks, no thanks" and I'll go about working on something else. > Thanks so much for your attention. > -- > James Mitchell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-42) Unit tests fail on Linux
Unit tests fail on Linux Key: MDEP-42 URL: http://jira.codehaus.org/browse/MDEP-42 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Environment: i386-Linux Reporter: Richard van der Hoff Priority: Minor Attachments: timestamps.patch Under Linux, file modification timestamps only have a resolution of one second. This causes several of the unit tests to fail. The attached patch fixes them (hopefully without breaking them on other platforms...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-43) includeClassifiers configuration parameter
includeClassifiers configuration parameter -- Key: MDEP-43 URL: http://jira.codehaus.org/browse/MDEP-43 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Affects Versions: 2.0-alpha-1 Reporter: Richard van der Hoff Priority: Minor Attachments: patch Would it be possible to add an "includeClassifiers" parameter to AbstractDependencyFilterMojo? The attached patch implements this; I've factored the code which would be common to the TypeFilter and ClassifierFilter into a common base class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-44) unpacking/copying of attached artifacts from reactor projects doesn't work
unpacking/copying of attached artifacts from reactor projects doesn't work -- Key: MDEP-44 URL: http://jira.codehaus.org/browse/MDEP-44 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Reporter: Richard van der Hoff Attachments: dependency-issue.zip I have a parent project, which has two modules - "one" and "two". "one" uses assembly:single to attach an assembly to its build. "two" depends upon that assembly, and uses "dependency:unpack-dependencies" to unpack it. This works fine if the projects are built separately - and the assembly is installed in the local repository. However, when using the reactor to build both projects at once, the dependency plugin still looks in the local repository for the assembly, rather than using the artifact which was just built. This either fails, or produces the wrong version of the assembly. I suspect this may be a bug with the reactor mechanism - but I don't really understand how all that works... The attachment demonstrates the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2619) building from the middle pom of a (parent,child,grandchild) heirarchy fails
building from the middle pom of a (parent,child,grandchild) heirarchy fails
---
Key: MNG-2619
URL: http://jira.codehaus.org/browse/MNG-2619
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.4, 2.0.5, 2.1
Reporter: Richard van der Hoff
Attachments: maven-project-middlepom.patch
Given a heirerchy of projects - parent, child, grandchild - with and
links between them in the normal way:
Attempting to start a build from the middle of the heirarchy - ie, the "child"
- causes maven to attempt to download the parent from the repository - even if
the version in the filesystem is correct in terms of {artifact,group,version}.
The problem appears to be that the ProjectBuilder first reads the child pom,
and caches the result (but not the parent pom). The reactor then makes the
ProjectBuilder read the grandchild pom, and hence the child pom (which now
comes from the cache), and the parent pom (which it can't find).
This is much easier demonstrated than explained :/
The attached patch fixes the problem by making sure that all the projects in
the heirarchy (including the parent) are added to the cache. It also includes a
test case to demonstrate the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_78101 ] Richard van der Hoff commented on MASSEMBLY-103: was there any interest in applying this patch? I see it has quite a few votes... > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch, > maven-assembly-plugin-filters.v2.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_78103 ] Richard van der Hoff commented on MASSEMBLY-103: oh, of course now the patch has bit-rotted. Meh, I hate it when that happens. If there /is/ any interest in applying this, let me know and I shall see about updating it. If it's just going to stagnate again, i won't bother and will stick with my custom build of version 2.1 of the plugin. > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch, > maven-assembly-plugin-filters.v2.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-110) release:prepare generates tags with dots, causing problems with CVS
[ http://jira.codehaus.org/browse/MRELEASE-110?page=comments#action_78930 ] Richard van der Hoff commented on MRELEASE-110: --- Thanks. Is there any timescale for this being made into a release version? > release:prepare generates tags with dots, causing problems with CVS > --- > > Key: MRELEASE-110 > URL: http://jira.codehaus.org/browse/MRELEASE-110 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: mvn 2.0.4 WinXP >Reporter: Marcel Schutte > Assigned To: Edwin Punzalan > Fix For: 2.0 > > Attachments: maven-release-plugin-cvstag.patch > > > When my project has version 01.02 release:prepare will suggest a tag > 'Mavenparent-01.02' even though the scm provider is CVS. This causes the tag > to fail and later on also a failure in release:perform. > The head version before the plugin rewrite had a special case to convert dots > to underscores. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_78952 ] Richard van der Hoff commented on MASSEMBLY-103: Right, I guess that's a good solution (though I still maintain mine was more flexible :) ). Thanks! A bit of documentation on the format of and wouldn't go amiss though O:-) See also my comment on MASSEMBLY-90 > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Richard van der Hoff > Assigned To: John Casey > Fix For: 2.2 > > Attachments: maven-assembly-plugin-filters.patch, > maven-assembly-plugin-filters.v2.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_78951 ] Richard van der Hoff commented on MASSEMBLY-90: --- Hrm; I find that if i do :jar: as well as getting all dependencies of type 'jar', I also get all dependencies of type not-'jar' which themselves have a dependency of type jar. Is that really intended behaviour? > add a DependencySet filter based on type > > > Key: MASSEMBLY-90 > URL: http://jira.codehaus.org/browse/MASSEMBLY-90 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Jason Chaffee > Assigned To: John Casey > Fix For: 2.2 > > Attachments: AbstractAssemblyMojo-patch.txt, > AbstractAssemblyMojo.java, AbstractAssemblyMojo.java, > AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java, > AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java, > component.mdo, component.mdo-patch.txt, descriptor.mdo, > descriptor.mdo-patch-.txt > > > It would be nice to create a distribution bundle that contains both jars and > webapps. These would be built by different projects and then an assembly > project would list these in the pom. However, there is no way to filter the > dependencies based on their type. This would be be a pretty easy thing to > add. I have attached a new class, AssemblyTypeArtifactFilter and the > required change to AbstractAsseblyMojo. The DependencySet class needs to be > modified as well to add the type field, but I was not able to find it in the > maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_79025 ]
Richard van der Hoff commented on MASSEMBLY-90:
---
Right, well, that doesn't work any better.
It seems that the pattern is tested against the entire transitive dependency
tree.
On a related note, the following doesn't match anything at all:
{code:xml}
!*:so:*
{code}
It seems that you need at least one positive pattern in an or
block to make this work.
> add a DependencySet filter based on type
>
>
> Key: MASSEMBLY-90
> URL: http://jira.codehaus.org/browse/MASSEMBLY-90
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: Jason Chaffee
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: AbstractAssemblyMojo-patch.txt,
> AbstractAssemblyMojo.java, AbstractAssemblyMojo.java,
> AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java,
> AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java,
> component.mdo, component.mdo-patch.txt, descriptor.mdo,
> descriptor.mdo-patch-.txt
>
>
> It would be nice to create a distribution bundle that contains both jars and
> webapps. These would be built by different projects and then an assembly
> project would list these in the pom. However, there is no way to filter the
> dependencies based on their type. This would be be a pretty easy thing to
> add. I have attached a new class, AssemblyTypeArtifactFilter and the
> required change to AbstractAsseblyMojo. The DependencySet class needs to be
> modified as well to add the type field, but I was not able to find it in the
> maven repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_79028 ]
Richard van der Hoff commented on MASSEMBLY-90:
---
To clarify this a little:
One of my project's dependencies is com.wapmx.etc:libnativeapp:so:1.0-SNAPSHOT.
It depends on com.wapmx.etc:native-app-java:jar:1.0-SNAPSHOT.
1)
In my assembly descriptor, I have:
{code:xml}
*:jar:*
{code}
This should include the dependencies of type jar, but not the so. It includes
everything.
2)
In my assembly descriptor, I have
{code:xml}
!*:so:*
{code}
This should also include the dependencies of type jar, but not the so (I
think!). It includes nothing. Adding an explicit * makes it
work ok, modulo point (1) above.
> add a DependencySet filter based on type
>
>
> Key: MASSEMBLY-90
> URL: http://jira.codehaus.org/browse/MASSEMBLY-90
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: Jason Chaffee
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: AbstractAssemblyMojo-patch.txt,
> AbstractAssemblyMojo.java, AbstractAssemblyMojo.java,
> AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java,
> AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java,
> component.mdo, component.mdo-patch.txt, descriptor.mdo,
> descriptor.mdo-patch-.txt
>
>
> It would be nice to create a distribution bundle that contains both jars and
> webapps. These would be built by different projects and then an assembly
> project would list these in the pom. However, there is no way to filter the
> dependencies based on their type. This would be be a pretty easy thing to
> add. I have attached a new class, AssemblyTypeArtifactFilter and the
> required change to AbstractAsseblyMojo. The DependencySet class needs to be
> modified as well to add the type field, but I was not able to find it in the
> maven repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_79116 ] Richard van der Hoff commented on MASSEMBLY-90: --- Yup, that all seems to be working - thanks! > add a DependencySet filter based on type > > > Key: MASSEMBLY-90 > URL: http://jira.codehaus.org/browse/MASSEMBLY-90 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Jason Chaffee > Assigned To: John Casey > Fix For: 2.2 > > Attachments: AbstractAssemblyMojo-patch.txt, > AbstractAssemblyMojo.java, AbstractAssemblyMojo.java, > AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java, > AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java, > component.mdo, component.mdo-patch.txt, descriptor.mdo, > descriptor.mdo-patch-.txt > > > It would be nice to create a distribution bundle that contains both jars and > webapps. These would be built by different projects and then an assembly > project would list these in the pom. However, there is no way to filter the > dependencies based on their type. This would be be a pretty easy thing to > add. I have attached a new class, AssemblyTypeArtifactFilter and the > required change to AbstractAsseblyMojo. The DependencySet class needs to be > modified as well to add the type field, but I was not able to find it in the > maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-40) Incomplete jar indexes
[ http://jira.codehaus.org/browse/MJAR-40?page=comments#action_79263 ]
Richard van der Hoff commented on MJAR-40:
--
Hrm, it seems I got this wrong in the case where the project doesn't have any
dependencies; it's a long story, but basically the indexing code tries to open
{{target/classes}} as a zip file, and fails.
The list returned by {{project.getRuntimeClasspathElements()}} includes
{{target/classes}}; it's incorrect to add this as a ConfiguredIndexJar to the
archiver.
I can't really be doing with preparing a patch for this - if you don't have any
dependencies, you can disable the 'Class-Path' in the manifest, which works
around the bug.
> Incomplete jar indexes
> --
>
> Key: MJAR-40
> URL: http://jira.codehaus.org/browse/MJAR-40
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: maven-archiver up to version 2.0.6; plexus-archiver up
> to version 1.0-alpha-6
>Reporter: Richard van der Hoff
> Assigned To: John Casey
> Fix For: 2.1
>
> Attachments: jar-index-bug.zip
>
>
> When creating a jar with an index, and a 'Class-Path' in the manifest, the
> index should include a list of all the classes in the other jars too - see
> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Index.
> The attachment contains a testcase which demonstrates a ClassCastException in
> the plexus-archiver; a fix to that, and a fix to the maven-archiver to make
> it actually use the fixed 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
[jira] Updated: (MSOURCES-6) Sources plugin ignores resource includes/excludes
[ http://jira.codehaus.org/browse/MSOURCES-6?page=all ] Richard van der Hoff updated MSOURCES-6: Attachment: maven-source-plugin-2.0.2.patch This doesn't seem to have been fixed in 2.0.2 after all. The other patches seemed to be rather overcomplicated; it seems to me to be better to add things to the Archiver as you iterate over the resources and sources lists, which saves stashing all of their details in a temporary list. Here (maven-source-plugin-2.0.2.patch) is my attempt at a patch; it will apply to both 2.0.2 and current trunk (r490260). It would be great to see this applied and released; it's a bit of a blocker! > Sources plugin ignores resource includes/excludes > - > > Key: MSOURCES-6 > URL: http://jira.codehaus.org/browse/MSOURCES-6 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-source-plugin-2.0.2.patch, > maven-sources-plugin-patches.zip, maven-sources-plugin-patches_v1.1.zip, > patch.txt > > > The sources plugin appears to ignore the and filters on > items. I discovered this because I have a project that needs to > package certain files that appear in the project root; e.g. > ., and then I certain files. > Trouble is, when the source plugin runs, it packages up EVERYTHING - > including the stuff in the "target" (output) directory! This leads to a > source attachment that's much too large. Worse, if you forget to clean > between builds, the size of the source jar will increase exponentially with > each build. > Checking out the source code at > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java?view=markup, > I think the problem is in the addDirectories() method, which is simply > adding resource.getDirectory() and dropping the other information on the > floor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSOURCES-6) Sources plugin ignores resource includes/excludes
[ http://jira.codehaus.org/browse/MSOURCES-6?page=comments#action_83582 ] Richard van der Hoff commented on MSOURCES-6: - Gah there's supposed to be an extra file in there, which i missed off the patch: src/test/resources/unit/custom-configuration/src/main/resources/excluded-file.txt. Otherwise the modification to the unit test doesn't have any effect and everything still passes. > Sources plugin ignores resource includes/excludes > - > > Key: MSOURCES-6 > URL: http://jira.codehaus.org/browse/MSOURCES-6 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-source-plugin-2.0.2.patch, > maven-sources-plugin-patches.zip, maven-sources-plugin-patches_v1.1.zip, > patch.txt > > > The sources plugin appears to ignore the and filters on > items. I discovered this because I have a project that needs to > package certain files that appear in the project root; e.g. > ., and then I certain files. > Trouble is, when the source plugin runs, it packages up EVERYTHING - > including the stuff in the "target" (output) directory! This leads to a > source attachment that's much too large. Worse, if you forget to clean > between builds, the size of the source jar will increase exponentially with > each build. > Checking out the source code at > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java?view=markup, > I think the problem is in the addDirectories() method, which is simply > adding resource.getDirectory() and dropping the other information on the > floor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=comments#action_83945 ] Richard van der Hoff commented on MECLIPSE-48: -- fabrizio, your changes seem to fix this problem nicely for resources, but there's still no means for excluding source files afaict. Are you certain this bug can be closed? > eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > - > > Key: MECLIPSE-48 > URL: http://jira.codehaus.org/browse/MECLIPSE-48 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mark Donszelmann > Assigned To: fabrizio giustina > Fix For: 2.3 > > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSOURCES-6) Sources plugin ignores resource includes/excludes
[ http://jira.codehaus.org/browse/MSOURCES-6?page=all ] Richard van der Hoff updated MSOURCES-6: Attachment: maven-source-plugin-2.0.2-patches-take2.zip My previous patch had a problem which meant that an exception was thrown if src/main/resources directory didn't exist; I've updated the patch to correct this. I've also split the patch into tests and source. > Sources plugin ignores resource includes/excludes > - > > Key: MSOURCES-6 > URL: http://jira.codehaus.org/browse/MSOURCES-6 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-source-plugin-2.0.2-patches-take2.zip, > maven-source-plugin-2.0.2.patch, maven-sources-plugin-patches.zip, > maven-sources-plugin-patches_v1.1.zip, patch.txt > > > The sources plugin appears to ignore the and filters on > items. I discovered this because I have a project that needs to > package certain files that appear in the project root; e.g. > ., and then I certain files. > Trouble is, when the source plugin runs, it packages up EVERYTHING - > including the stuff in the "target" (output) directory! This leads to a > source attachment that's much too large. Worse, if you forget to clean > between builds, the size of the source jar will increase exponentially with > each build. > Checking out the source code at > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java?view=markup, > I think the problem is in the addDirectories() method, which is simply > adding resource.getDirectory() and dropping the other information on the > floor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-151) Incorrect name for test sources jars
[ http://jira.codehaus.org/browse/MECLIPSE-151?page=all ] Richard van der Hoff updated MECLIPSE-151: -- Attachment: maven-eclipse-plugin.patch This also affects version 2.3. Here's a patch, with unit tests, which fixes it. > Incorrect name for test sources jars > > > Key: MECLIPSE-151 > URL: http://jira.codehaus.org/browse/MECLIPSE-151 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Richard van der Hoff > Attachments: maven-eclipse-plugin.patch > > > The eclipse plugin currently sets the source attachment of dependencies on > test-jars (as created by the test-jar goal of the jar plugin) to the same as > that of the main jar. > To fix, we need to check the classifier of dependencies when finding sources, > and if it is "tests", use "test-sources" rather than "sources" for the > classifier on the sources jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=comments#action_85240 ] Richard van der Hoff commented on MECLIPSE-48: -- That's what _I_ said ;) Steffen, if you have a usecase for this, it may be best to file a new issue, with a "related to" link, such that it gets back on the maintainers' radar. > eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > - > > Key: MECLIPSE-48 > URL: http://jira.codehaus.org/browse/MECLIPSE-48 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mark Donszelmann > Assigned To: fabrizio giustina > Fix For: 2.3 > > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-734) Can't use continuum behind https proxy
[
http://jira.codehaus.org/browse/CONTINUUM-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89586
]
Richard van der Hoff commented on CONTINUUM-734:
No.
Various people have got this to work with ProxyPassReverse; however installing
the relevant modules on the proxy was not an option for me.
It may well be fixed for 1.1; I haven't tested.
> Can't use continuum behind https proxy
> --
>
> Key: CONTINUUM-734
> URL: http://jira.codehaus.org/browse/CONTINUUM-734
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.0.3
>Reporter: Richard van der Hoff
> Assigned To: Emmanuel Venisse
> Fix For: 1.1-alpha-1
>
> Attachments: mod_proxy_http.so
>
>
> As noted in CONTINUUM-240, it's not currentlyy possible to run the continuum
> webapp behind an https proxy, as all the links are http://...
> My apache setup is something along the lines of:
> {code:xml}
>
> SSLEngine on
> ProxyPass / http://localhost:8080/
> ProxyPassReverse / http://localhost:8080/
> ProxyPreserveHost On
>
> {code}
> and my jetty config:
> {code:xml}
>
>
> 8080
>
>
> {code}
> The links are correct, except that they have s/https/http/.
> Why does the webapp need to use absolute links anyway?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-734) Can't use continuum behind https proxy
[
http://jira.codehaus.org/browse/CONTINUUM-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89588
]
Richard van der Hoff commented on CONTINUUM-734:
sorry, i mean ProxyHTMLURLMap, not ProxyPassReverse.
> Can't use continuum behind https proxy
> --
>
> Key: CONTINUUM-734
> URL: http://jira.codehaus.org/browse/CONTINUUM-734
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.0.3
>Reporter: Richard van der Hoff
> Assigned To: Emmanuel Venisse
> Fix For: 1.1-alpha-1
>
> Attachments: mod_proxy_http.so
>
>
> As noted in CONTINUUM-240, it's not currentlyy possible to run the continuum
> webapp behind an https proxy, as all the links are http://...
> My apache setup is something along the lines of:
> {code:xml}
>
> SSLEngine on
> ProxyPass / http://localhost:8080/
> ProxyPassReverse / http://localhost:8080/
> ProxyPreserveHost On
>
> {code}
> and my jetty config:
> {code:xml}
>
>
> 8080
>
>
> {code}
> The links are correct, except that they have s/https/http/.
> Why does the webapp need to use absolute links anyway?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-40) Incomplete jar indexes
Incomplete jar indexes -- Key: MJAR-40 URL: http://jira.codehaus.org/browse/MJAR-40 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1 Environment: maven-archiver up to version 2.0.6; plexus-archiver up to version 1.0-alpha-6 Reporter: Richard van der Hoff Attachments: jar-index-bug.zip When creating a jar with an index, and a 'Class-Path' in the manifest, the index should include a list of all the classes in the other jars too - see http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Index. The attachment contains a testcase which demonstrates a ClassCastException in the plexus-archiver; a fix to that, and a fix to the maven-archiver to make it actually use the fixed 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
[jira] Created: (MNG-2297) plugin definitions not merged correctly
plugin definitions not merged correctly --- Key: MNG-2297 URL: http://jira.codehaus.org/browse/MNG-2297 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.4 Reporter: Richard van der Hoff Priority: Minor Attachments: maven-project-plugins.patch If both a parent, and a child plugin reference a plugin, the plugin configuration is not merged correctly; instead, the child build ends up with two copies of the plugin (with separate configuration and separate executions). The attachment contains a testcase demonstrating the problem, and fixes to ModelUtils.java (against current trunk) to fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-88) Use test harness for the assembly plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-88?page=all ] Richard van der Hoff updated MASSEMBLY-88: -- Attachment: maven-assembly-plugin-tests.patch > Use test harness for the assembly plugin > > > Key: MASSEMBLY-88 > URL: http://jira.codehaus.org/browse/MASSEMBLY-88 > Project: Maven 2.x Assembly Plugin > Type: Test > Versions: 2.1 > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Attachments: maven-assembly-plugin-tests.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
More powerful includes/excludes stuff in DependencySets in descriptors -- Key: MASSEMBLY-103 URL: http://jira.codehaus.org/browse/MASSEMBLY-103 Project: Maven 2.x Assembly Plugin Type: New Feature Versions: 2.1 Reporter: Richard van der Hoff Attachments: maven-assembly-plugin-filters.patch A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for more powerful filtering of dependency sets in assembly descriptors. I wanted to take this further, so as to allow quite powerful boolean expressions for the description of dependencies. For example, the assembly extract below will include anything which is not a "zip" in the org.apache.maven.* or org.codehaus.* groups. The attachment contains an implementation of this, and a couple of testcases for the new functionality. false false org.apache.maven.* org.codehaus.* zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_65542 ] Richard van der Hoff commented on MASSEMBLY-103: doh. Now imagine that the xml snippet had "true", and that jira hadn't eaten all the lovely indentation, and that would work much better. > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Type: New Feature > Versions: 2.1 > Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-41) Enable wilcards in dependency set includes/excludes
[ http://jira.codehaus.org/browse/MASSEMBLY-41?page=comments#action_65544 ] Richard van der Hoff commented on MASSEMBLY-41: --- see http://jira.codehaus.org/browse/MASSEMBLY-103 for a solution to this. > Enable wilcards in dependency set includes/excludes > --- > > Key: MASSEMBLY-41 > URL: http://jira.codehaus.org/browse/MASSEMBLY-41 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Filip Vuksanovic > > > Wildcards can't be used in dependency set includes/excludes inside assembly > descriptor. > >my-assembly > > jar > >false > > >/ >true >runtime > > groupId:artifactId > > > > > It should at least support something like groupId:*. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_65545 ] Richard van der Hoff commented on MASSEMBLY-90: --- see http://jira.codehaus.org/browse/MASSEMBLY-103 for another solution to this. > add a DependencySet filter based on type > > > Key: MASSEMBLY-90 > URL: http://jira.codehaus.org/browse/MASSEMBLY-90 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Reporter: Jason Chaffee > Attachments: AbstractAssemblyMojo-patch.txt, AbstractAssemblyMojo.java, > AbstractAssemblyMojo.java, AbstractAssemblyMojo.java, > AssemblyClassifierArtifactFilter.java, AssemblyTypeArtifactFilter.java, > AssemblyTypeArtifactFilter.java, component.mdo, component.mdo-patch.txt, > descriptor.mdo, descriptor.mdo-patch-.txt > > > It would be nice to create a distribution bundle that contains both jars and > webapps. These would be built by different projects and then an assembly > project would list these in the pom. However, there is no way to filter the > dependencies based on their type. This would be be a pretty easy thing to > add. I have attached a new class, AssemblyTypeArtifactFilter and the > required change to AbstractAsseblyMojo. The DependencySet class needs to be > modified as well to add the type field, but I was not able to find it in the > maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=comments#action_65547 ] Richard van der Hoff commented on MASSEMBLY-103: sorry, i've thoroughly messed up that patch. Bear with me and I'll try again. > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Type: New Feature > Versions: 2.1 > Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-103) More powerful includes/excludes stuff in DependencySets in descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-103?page=all ] Richard van der Hoff updated MASSEMBLY-103: --- Attachment: maven-assembly-plugin-filters.v2.patch > More powerful includes/excludes stuff in DependencySets in descriptors > -- > > Key: MASSEMBLY-103 > URL: http://jira.codehaus.org/browse/MASSEMBLY-103 > Project: Maven 2.x Assembly Plugin > Type: New Feature > Versions: 2.1 > Reporter: Richard van der Hoff > Attachments: maven-assembly-plugin-filters.patch, > maven-assembly-plugin-filters.v2.patch > > > A couple of other issues - http://jira.codehaus.org/browse/MASSEMBLY-90, > http://jira.codehaus.org/browse/MASSEMBLY-41 - have pointed out the need for > more powerful filtering of dependency sets in assembly descriptors. I wanted > to take this further, so as to allow quite powerful boolean expressions for > the description of dependencies. For example, the assembly extract below will > include anything which is not a "zip" in the org.apache.maven.* or > org.codehaus.* groups. > The attachment contains an implementation of this, and a couple of testcases > for the new functionality. > > > false > > > false > > > org.apache.maven.* > > > org.codehaus.* > > > > > > > zip > > > > -- 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
