[jira] Created: (MPIR-141) "Release" french translation
"Release" french translation Key: MPIR-141 URL: http://jira.codehaus.org/browse/MPIR-141 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Baptiste MATHUS Priority: Trivial Attachments: mpir-dependencies-release-translation.patch In the dependency report, Release term has been translated "Dégagement". I guess this is quite anappropriate. In my opinion, as snasphot was left as is, the same should be done to "release". Cheers. PS : patch included, though I'm not sure it will be quicker than doing it manually :). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-486) ITs dont compare expected files if the IT is a multi-module project
[
http://jira.codehaus.org/browse/MECLIPSE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar closed MECLIPSE-486.
---
Resolution: Fixed
Fix Version/s: 2.6
Fixed, checked on minotaur as well as windows.
> ITs dont compare expected files if the IT is a multi-module project
> ---
>
> Key: MECLIPSE-486
> URL: http://jira.codehaus.org/browse/MECLIPSE-486
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Multi-projects
>Affects Versions: 2.6
>Reporter: Barrie Treloar
>Assignee: Barrie Treloar
> Fix For: 2.6
>
>
> The comparison of directories is only done in testProject:
> {code:title=AbstractEclipsePluginIT.testProject(String, Properties, String,
> String)}
> // line 250
> compareDirectoryContent( basedir, projectOutputDir, "" );
> compareDirectoryContent( basedir, projectOutputDir, ".settings/" );
> compareDirectoryContent( basedir, projectOutputDir,
> ".externalToolBuilders/" );
> compareDirectoryContent( basedir, projectOutputDir, "META-INF/" );
> {code}
> which only checks the top level basedir.
> I'm changing the tests to locate all "expected" directories under basedir and
> to compare all the files recursively under "expected" to the equivalent level
> in the outputDir.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-30) Compiler fork executable fails when the path has spaces
[
http://jira.codehaus.org/browse/MCOMPILER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147758#action_147758
]
Dan Rollo commented on MCOMPILER-30:
He he. But how cool would that have been if it had worked?! ;)
> Compiler fork executable fails when the path has spaces
> ---
>
> Key: MCOMPILER-30
> URL: http://jira.codehaus.org/browse/MCOMPILER-30
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Carlos Sanchez
> Fix For: 2.0.2
>
>
> JAVA_1_3_HOME=C:\Program Files\Java\jdk1.3.1_18
>
> maven-compiler-plugin
>
> true
> 1.3
> ${JAVA_1_3_HOME}/bin/javac
>
>
> Fails with
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MNG-3580: Attachment: MNG-3580-maven-core.patch Attaching MNG-3580-maven-core.patch This patch adds a JUnit test to the maven-core project that demonstrates one of the NPEs encountered while operating within the IBM JDK. NOTE: This patch does not fix the issue, just adds a Unit test to tickle one of the bugs. > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz > Fix For: 2.0.11 > > Attachments: debug-output.patch, maven.log, > MNG-3580-ibm-jdk-issues.zip, MNG-3580-maven-core.patch, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
[jira] Updated: (MSITE-358) site.xml urls are not always correct
[
http://jira.codehaus.org/browse/MSITE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MSITE-358:
Priority: Blocker (was: Major)
Description:
This is so completely broken that it must be fixed before another release
occurs.
The maven-parent site.xml defines some images as:
{noformat}
${project.name}
http://maven.apache.org/images/apache-maven-project-2.png
http://maven.apache.org/
http://maven.apache.org/images/maven-logo-2.gif
{noformat}
The site plugin somewhere along the line replaces these urls with ../../
repeated based on how far down the inheritence tree you are from maven-parent.
This means you can't stage or deploy a site to a different location than the
maven-parent because all urls will point back to maven-parent's /images. Worse,
every module has its own copy of the css and images so there's no reason for it
to depend on the parent at all.
was:It appears that when trying to deploy or stage a site, the plugin is
calculating the relative path to the images. If the location you stage the site
is not the same number of folders deep as the final deployment, then when you
move the site, the images will all be broken.
Fix Version/s: 2.0-beta-8
Summary: site.xml urls are not always correct (was: skin urls are
not always correct)
> site.xml urls are not always correct
>
>
> Key: MSITE-358
> URL: http://jira.codehaus.org/browse/MSITE-358
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Brian Fox
>Priority: Blocker
> Fix For: 2.0-beta-8
>
>
> This is so completely broken that it must be fixed before another release
> occurs.
> The maven-parent site.xml defines some images as:
> {noformat}
>
> ${project.name}
> http://maven.apache.org/images/apache-maven-project-2.png
> http://maven.apache.org/
>
>
> http://maven.apache.org/images/maven-logo-2.gif
>
> {noformat}
> The site plugin somewhere along the line replaces these urls with ../../
> repeated based on how far down the inheritence tree you are from
> maven-parent. This means you can't stage or deploy a site to a different
> location than the maven-parent because all urls will point back to
> maven-parent's /images. Worse, every module has its own copy of the css and
> images so there's no reason for it to depend on the parent at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-358) skin urls are not always correct
skin urls are not always correct Key: MSITE-358 URL: http://jira.codehaus.org/browse/MSITE-358 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Brian Fox It appears that when trying to deploy or stage a site, the plugin is calculating the relative path to the images. If the location you stage the site is not the same number of folders deep as the final deployment, then when you move the site, the images will all be broken. -- 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-486) ITs dont compare expected files if the IT is a multi-module project
[
http://jira.codehaus.org/browse/MECLIPSE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147723#action_147723
]
Barrie Treloar commented on MECLIPSE-486:
-
{noformat}
pom.xml:
Fixed the phase "test" to not include "projects/**" as this directory
is copied from src/test/resources into target/test-classes
and surefire will attempt to compile any *Test*.java files - which will
fail since they are not in the correct location
relative to their package declaration. See
http://www.nabble.com/Plugins%3A-execution-configuration-does-not-add-to-configuration-td19425025.html
Fixed the run-its profile so that it overrides the excludes inherited
from the "test" phase configuration.
IdeUtils:
Refactored code to create fixSeparator() method.
AbstractEclipsePluginIT:
Changed compareDirectoryContent to no longer accept a directory to use
as check contents.
Instead ${basedir} is searched for EXPECTED_DIRECTORY_NAME ("expected")
and all occurrences
of this directory are used in the comparison processes. This has
simplified checking in
code as you no longer need to specify additional calls for multiple
directories and
made it easier to support multi-module checking as previously only
${basedir}/expected
was checked, module directories where ignored. The actual files checked
are relative to the
parent directory of the matching "expected" directory.
IOExceptions are no longer thrown instead MojoExecutionException are
used mainly by
delegating to IdeUtils.getCanonicalPath() instead of calling
File.getCanonicalPath() directly.
RadPluginIT:
Updated to use new compareDirectoryContent()
src/test/resources/projects/*:
Fixed files that were never previously checked to use the contents of
the actual
maven-eclipse-plugin output. On the assumption that the plugin is
generating the correct
output and nothing in this change set has altered that behaviour.
{noformat}
> ITs dont compare expected files if the IT is a multi-module project
> ---
>
> Key: MECLIPSE-486
> URL: http://jira.codehaus.org/browse/MECLIPSE-486
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Multi-projects
>Affects Versions: 2.6
>Reporter: Barrie Treloar
>Assignee: Barrie Treloar
>
> The comparison of directories is only done in testProject:
> {code:title=AbstractEclipsePluginIT.testProject(String, Properties, String,
> String)}
> // line 250
> compareDirectoryContent( basedir, projectOutputDir, "" );
> compareDirectoryContent( basedir, projectOutputDir, ".settings/" );
> compareDirectoryContent( basedir, projectOutputDir,
> ".externalToolBuilders/" );
> compareDirectoryContent( basedir, projectOutputDir, "META-INF/" );
> {code}
> which only checks the top level basedir.
> I'm changing the tests to locate all "expected" directories under basedir and
> to compare all the files recursively under "expected" to the equivalent level
> in the outputDir.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-357) staging should execute some phase of the lifecycle
staging should execute some phase of the lifecycle -- Key: MSITE-357 URL: http://jira.codehaus.org/browse/MSITE-357 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Brian Fox As much as i hate having to fork the lifecycle, with site:stage, there is no way to generate other artifacts. In my use case, i'm using assembly to generate a zip file (in the enforcer-api project) at pre-site, which works fine if i mvn site or mvn site-deploy, but doesn't get created when you do a site:stage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-331) assembly descriptor doesn't seem to property substitute properties
[
http://jira.codehaus.org/browse/MASSEMBLY-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-331.
Resolution: Fixed
applied with minor modifications. Thanks.
> assembly descriptor doesn't seem to property substitute properties
> --
>
> Key: MASSEMBLY-331
> URL: http://jira.codehaus.org/browse/MASSEMBLY-331
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Jon Osborn
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: massembly-331-source.txt, massembly-331-test.txt
>
>
> For the following assembly.xml:
>
>
> tar.gz
>
> false
>
>
> src/main/resources/appcontent
>
> ${build.environment}/${build.view}/appcontent
>
> **
>
>
>
>
> ${build.environment} and ${build.view} are declared as in parent
> POM. They retain their 'default' value and cannot be overridden from the
> command line using the -D (-Dbuild.environment=UAT) syntax.
> The intent of the properties is to build the tar.gz file with different paths
> based on the two variables.
--
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: (MRESOURCES-8) maven-resources-plugin ignores configuration/resources property (add a new mojo to copy resources)
[
http://jira.codehaus.org/browse/MRESOURCES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147718#action_147718
]
Olivier Lamy commented on MRESOURCES-8:
---
The question is : we call this new mojo copyResources or copy-resources ? :-)
My +1 for copy-resources.
Comments are welcome !
Thanks,
--
Olivier
> maven-resources-plugin ignores configuration/resources property (add a new
> mojo to copy resources)
> --
>
> Key: MRESOURCES-8
> URL: http://jira.codehaus.org/browse/MRESOURCES-8
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.1, 2.2
>Reporter: Leszek Gawron
>Assignee: Olivier Lamy
> Fix For: 2.3
>
> Attachments: example.zip, MRESOURCES-8-workaround.patch, pom.xml
>
>
> I am evaluating maven + eclipse combo. In a trivial POM filtered resources
> exist only in target/classes. If one executes Project -> Clean under eclipse
> this information is lost. If filtered resources would appear as source folder
> they would survive cleaning and not got overriden by unfiltered ones.
> I have been trying to implement a scenario which would allow filtered
> resources to appear as "static" source folder under eclipse.
> The POM explains it best:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.mobilebox.squash.client
> squash-client
> jar
> 1.0-SNAPSHOT
> Maven Quick Start Archetype
> http://maven.apache.org
>
>
>
> maven-resources-plugin
>
>
> prefilter-resources
> generate-resources
>
> resources
>
>
>
> target/generated-resources
>
>
>
> src/main/resource-templates
> true
>
>
>
>
>
>
>
>
> ${ffile}
>
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
>
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> filter.properties
>
>
> thing is this part:
>
>
> src/main/properties
> true
>
>
> is completely ignored. Instead for both maven-resource-plugin executions (the
> one in generate-resources phase and the default one) this config is used:
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
> which of course breaks the whole idea.
> Is this a bug or a design decision. In latter case is there any equivalent
> approach I might take?
--
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-1977) Global dependency exclusions
[ http://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147714#action_147714 ] Barry Kaplan commented on MNG-1977: --- Aliasing would be nice. But I would also like to be able to specify that, for example, junit-3.8.1 should NEVER be downloaded and never be resolved as a dependency for my projects. I don't ever want junit-3.8.1 and junit-4.5 to both be in the same classpath. > Global dependency exclusions > > > Key: MNG-1977 > URL: http://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.0 > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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: (MDOCCK-14) Plugin does not respect generated documentation
[
http://jira.codehaus.org/browse/MDOCCK-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147712#action_147712
]
Dennis Lundberg commented on MDOCCK-14:
---
I'll look into making a release.
> Plugin does not respect generated documentation
> ---
>
> Key: MDOCCK-14
> URL: http://jira.codehaus.org/browse/MDOCCK-14
> Project: Maven 2.x Documentation Checker Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-2
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Benjamin Bentmann
>
> The plugin does not respect generated content (from velocity templates), for
> example the project at:
> http://svn.codehaus.org/mojo/trunk/mojo/was6-maven-plugin/
> generates completely valid documentation - but the plugin fails with:
> [INFO] [docck:check {execution: verify}]
> [INFO] Checking project: WAS6 Maven Plugin
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 12 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [ERROR] The following documentation problems were found:
> o WAS6 Maven Plugin (3 errors, 0 warnings)
> [ERROR] There is no 'usage' file in your site directory (in apt|html|xml
> format).
> [ERROR] There are no example files in your site directory (in apt|html|xml
> format). They should either be called 'example*.(apt|html|xml)' or they
> should be located in the 'examples' directory.
> [ERROR] There is no 'faq' file in your site directory (in apt|fml|html|xml
> format).
--
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: (MSHARED-63) Filtering Resources does not match patterns strictly
[
http://jira.codehaus.org/browse/MSHARED-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147711#action_147711
]
Olivier Lamy commented on MSHARED-63:
-
And simple test/use case ?
Thanks
> Filtering Resources does not match patterns strictly
>
>
> Key: MSHARED-63
> URL: http://jira.codehaus.org/browse/MSHARED-63
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-1
>Reporter: Walter White
>
> When using Maven Filtering, maven-war-plugin, variables within the JSP that
> do not correspond to configured properties are updated as well ie.
> [code]
> ${users.id}
> ${user.id}
> ${adfadfadf.id}
> [/code]
> All of those patterns are matched to the project id which causes the JSP
> throw an exception. Having these properties set at build time lets me
> configure the context.path and links dynamically depending on the
> environment. The problem appears to be associated with the plexus pattern
> matching plugin as it is what decides to match any variable ending in .id
> I suggest that an option is added to configure which patterns are matched and
> if the pattern matching is strict. For example, in my JSPs, it would be
> ideal to only allow @context.path@ and not ${users.id} so the variables
> within the JSP remain just that and configured properties are updated
> accordingly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-181) useRepositoryLayout does not create proper repository layout
[ http://jira.codehaus.org/browse/MDEP-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-181. -- Resolution: Fixed Fix Version/s: 2.1 > useRepositoryLayout does not create proper repository layout > > > Key: MDEP-181 > URL: http://jira.codehaus.org/browse/MDEP-181 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Brian Fox > Fix For: 2.1 > > Attachments: mdep-install-to-local.diff > > > repository created with useRepositoryLayout=true does not contain repository > metadata and does not have artifacts with expanded snapshot versions properly > dealt with. Attached patch changes the code to use ArtifactInstaller to > "install" artifacts to the target directory. -- 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-331) assembly descriptor doesn't seem to property substitute properties
[
http://jira.codehaus.org/browse/MASSEMBLY-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-331:
-
Assignee: John Casey
Fix Version/s: 2.2-beta-3
> assembly descriptor doesn't seem to property substitute properties
> --
>
> Key: MASSEMBLY-331
> URL: http://jira.codehaus.org/browse/MASSEMBLY-331
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Jon Osborn
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: massembly-331-source.txt, massembly-331-test.txt
>
>
> For the following assembly.xml:
>
>
> tar.gz
>
> false
>
>
> src/main/resources/appcontent
>
> ${build.environment}/${build.view}/appcontent
>
> **
>
>
>
>
> ${build.environment} and ${build.view} are declared as in parent
> POM. They retain their 'default' value and cannot be overridden from the
> command line using the -D (-Dbuild.environment=UAT) syntax.
> The intent of the properties is to build the tar.gz file with different paths
> based on the two variables.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-284) regression: line ending setting is not honoured
[ http://jira.codehaus.org/browse/MASSEMBLY-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-284. Assignee: John Casey Resolution: Duplicate dupe of MASSEMBLY-237. This has been verified as fixed by the modification for MASSEMBLY-293. > regression: line ending setting is not honoured > --- > > Key: MASSEMBLY-284 > URL: http://jira.codehaus.org/browse/MASSEMBLY-284 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 >Reporter: Brett Porter >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-3 > > > I generated the assemblies for a project using both 2.1 and 2.2-beta-2 and > found that the version in 2.2 did not respect windows line ending settings: > > target/assembly/work/maven-core-bin/maven/bin > maven/bin > > **/*.bat > > 0755 > dos > > They came out as the platform default -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-237) lineEnding ignored in a child project
[ http://jira.codehaus.org/browse/MASSEMBLY-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-237. Resolution: Fixed Fixed by fix for MASSEMBLY-293. I've added two new integration tests to verify this, one for windows and one for unix line endings. > lineEnding ignored in a child project > - > > Key: MASSEMBLY-237 > URL: http://jira.codehaus.org/browse/MASSEMBLY-237 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: Windows Vista >Reporter: Todor Todorov >Assignee: John Casey >Priority: Minor > Fix For: 2.2-beta-3 > > Attachments: massembly-237.txt, test.zip > > > I have a parent project and a child project. The child project builds an > assembly composed of text files. > > bin > src/main/bin > unix > > *.sh > > > When I build the assembly from the child project , maven adds unix endings, > but when I build it from the parent project, lineEnding is being ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[ http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147588#action_147588 ] joshbeetle edited comment on MNG-3314 at 9/11/08 2:48 PM: -- I'm running Maven 2.0.8, and I see the same behavior that Henrik described. Touching the files does fix the problem. If the snapshot dependencies are coming from a remote repository, then setting the snapshot update policy of the remote repository to never also fixes the issue. See http://maven.apache.org/settings.html#Repositories for an example. The snapshot update policy does not seem to be applied to transitive dependencies. Maven still complains about transitive snapshot dependencies if the files have a timestamp from a previous day. I resolved this by including the transitive snapshots directly in my project dependencies. was (Author: joshbeetle): I'm running Maven 2.0.8, and I see the same behavior that Henrik described. Touching the files does fix the problem. If the snapshot dependencies are coming from a remote repository, then setting the snapshot update policy of the remote repository to never also fixes the issue. See http://maven.apache.org/settings.html#Repositories for an example. > offline build not running, when having SNAPSHOT dependencies > > > Key: MNG-3314 > URL: http://jira.codehaus.org/browse/MNG-3314 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.7 >Reporter: Matthias Weßendorf >Assignee: John Casey >Priority: Critical > Fix For: 2.0.11 > > Attachments: maven-offline-snapshot-failure.log, > maven-offline-snapshot-problem.tar > > > am having troubles with > mvn ... -o > (with maven 2.0.7) > says not able to download (but, really, the file is in my local repo) > The dependency is a -SNAPSHOT (for what's worth) > Luckily, when traveling by train, I had maven 2.0.4 on my box as well. > A change to use 2.0.4 works fine. > So, is this an already know bug in 2.0.7 ? > To my understanding it is a bug, since offline just shouldn't try to get a > newer > SNAPSHOT, perhaps I am wrong. > I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect > just not checking for new stuff. > and... for some reasons, sometimes, > it just downloads a new SNAPSHOT. > That is a pain, when you are "maintaining" the same snapshot on your > box, but the build just goes ahead and actually downloads a version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-181) useRepositoryLayout does not create proper repository layout
[ http://jira.codehaus.org/browse/MDEP-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MDEP-181: Attachment: (was: mdep-install-to-local.diff) > useRepositoryLayout does not create proper repository layout > > > Key: MDEP-181 > URL: http://jira.codehaus.org/browse/MDEP-181 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Brian Fox > Attachments: mdep-install-to-local.diff > > > repository created with useRepositoryLayout=true does not contain repository > metadata and does not have artifacts with expanded snapshot versions properly > dealt with. Attached patch changes the code to use ArtifactInstaller to > "install" artifacts to the target directory. -- 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: (MDEP-181) useRepositoryLayout does not create proper repository layout
[ http://jira.codehaus.org/browse/MDEP-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MDEP-181: Attachment: mdep-install-to-local.diff added unit tests (no other code changes) > useRepositoryLayout does not create proper repository layout > > > Key: MDEP-181 > URL: http://jira.codehaus.org/browse/MDEP-181 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Brian Fox > Attachments: mdep-install-to-local.diff > > > repository created with useRepositoryLayout=true does not contain repository > metadata and does not have artifacts with expanded snapshot versions properly > dealt with. Attached patch changes the code to use ArtifactInstaller to > "install" artifacts to the target directory. -- 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-322) Filtering in filesets in multimodule build does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-322: - Fix Version/s: 2.2-beta-3 > Filtering in filesets in multimodule build does not work > > > Key: MASSEMBLY-322 > URL: http://jira.codehaus.org/browse/MASSEMBLY-322 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 >Reporter: Roman Kitko >Assignee: John Casey > Fix For: 2.2-beta-3 > > > I have multimodule build. One child is using > > MyDir > /bin/ > 0755 > true > > This works fine when I build just this child. But when child is being built > in multimodule build , files are not filtered. > I am sure(using -X) in single module build and in multi module build, same > version(2.2-beta-2) of asembly plugin is used. > Workaround is to again use individual ... like in 2.2-beta-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-340) Filtering doesn't work for multimodule assembly builds
[
http://jira.codehaus.org/browse/MASSEMBLY-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-340:
-
Fix Version/s: 2.2-beta-3
> Filtering doesn't work for multimodule assembly builds
> --
>
> Key: MASSEMBLY-340
> URL: http://jira.codehaus.org/browse/MASSEMBLY-340
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Edd Steel
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
>
> I have a script with the following lines
> REM ${project.version}
> java -jar ${artifact.artifactId}-${artifact.version}.${artifact.packaging}
> in one of my modules ("Module A"). The assembly plugin is bound to the
> package phase in the Module A POM.
> If I run "mvn clean install" in Module A's directory, the resulting installed
> bundle has filtered the script correctly.
> If I run "mvn clean install" in the parent POM, of which Module A is a
> module, Module A is built and installed, and the bundle installed has the
> script without filtering.
> Relevant debug output:
> [DEBUG] After assembly is interpolated:
> ...
>
> scripts
> unix
> true
>
>
> *.sh
>
> 0750
>
>
> scripts
> dos
> true
>
>
> *.cmd
> *.bat
>
> 0750
>
>
> ...
> [DEBUG] Adding directory file-set in: D:\projects\project\module-a\scripts to
> archive location:
> [DEBUG] FileSet[] dir perms: 40755 file perms: 100644 lineEndings: unix
> [DEBUG] The archive base directory is 'null'
> [INFO] No files selected for line-ending conversion. Skipping: scripts
> [DEBUG] Adding file-set from directory: 'D:\projects\project\module-a\scripts'
> assembly output directory is: ''
> [DEBUG] Adding directory file-set in: D:\projects\project\module-a\scripts to
> archive location:
> [DEBUG] FileSet[] dir perms: 40755 file perms: 100644 lineEndings: dos
> [DEBUG] The archive base directory is 'null'
> [INFO] No files selected for line-ending conversion. Skipping: scripts
> I don't know if that last [INFO] line is a clue?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-340) Filtering doesn't work for multimodule assembly builds
[
http://jira.codehaus.org/browse/MASSEMBLY-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-340.
Resolution: Duplicate
> Filtering doesn't work for multimodule assembly builds
> --
>
> Key: MASSEMBLY-340
> URL: http://jira.codehaus.org/browse/MASSEMBLY-340
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Edd Steel
>Assignee: John Casey
>
> I have a script with the following lines
> REM ${project.version}
> java -jar ${artifact.artifactId}-${artifact.version}.${artifact.packaging}
> in one of my modules ("Module A"). The assembly plugin is bound to the
> package phase in the Module A POM.
> If I run "mvn clean install" in Module A's directory, the resulting installed
> bundle has filtered the script correctly.
> If I run "mvn clean install" in the parent POM, of which Module A is a
> module, Module A is built and installed, and the bundle installed has the
> script without filtering.
> Relevant debug output:
> [DEBUG] After assembly is interpolated:
> ...
>
> scripts
> unix
> true
>
>
> *.sh
>
> 0750
>
>
> scripts
> dos
> true
>
>
> *.cmd
> *.bat
>
> 0750
>
>
> ...
> [DEBUG] Adding directory file-set in: D:\projects\project\module-a\scripts to
> archive location:
> [DEBUG] FileSet[] dir perms: 40755 file perms: 100644 lineEndings: unix
> [DEBUG] The archive base directory is 'null'
> [INFO] No files selected for line-ending conversion. Skipping: scripts
> [DEBUG] Adding file-set from directory: 'D:\projects\project\module-a\scripts'
> assembly output directory is: ''
> [DEBUG] Adding directory file-set in: D:\projects\project\module-a\scripts to
> archive location:
> [DEBUG] FileSet[] dir perms: 40755 file perms: 100644 lineEndings: dos
> [DEBUG] The archive base directory is 'null'
> [INFO] No files selected for line-ending conversion. Skipping: scripts
> I don't know if that last [INFO] line is a clue?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-322) Filtering in filesets in multimodule build does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-322. Resolution: Duplicate > Filtering in filesets in multimodule build does not work > > > Key: MASSEMBLY-322 > URL: http://jira.codehaus.org/browse/MASSEMBLY-322 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 >Reporter: Roman Kitko >Assignee: John Casey > > I have multimodule build. One child is using > > MyDir > /bin/ > 0755 > true > > This works fine when I build just this child. But when child is being built > in multimodule build , files are not filtered. > I am sure(using -X) in single module build and in multi module build, same > version(2.2-beta-2) of asembly plugin is used. > Workaround is to again use individual ... like in 2.2-beta-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-293) not filtered in multimodule build, but are
[ http://jira.codehaus.org/browse/MASSEMBLY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-293. Resolution: Fixed > not filtered in multimodule build, but are > - > > Key: MASSEMBLY-293 > URL: http://jira.codehaus.org/browse/MASSEMBLY-293 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Windows XP >Reporter: Torsten Reinhard >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: install.xml, update-db2.sh > > > Filtering doesn´t work in a multimodule build if I use instead of > - if I build the module separately, it works > Shouldn´t the behaviour be the same? I have not looked into the code, but I > expect one thing is collection the files (however the filelist is expressed), > the other is filtering them. It seems, as the separation of functionality is > mixed in here? > See the attached file(s) as example. -- 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-3580) FATAL ERROR and NPE on start
[
http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147696#action_147696
]
Benjamin Bentmann commented on MNG-3580:
bq. Attaching a project with a simple case that shows that the IBM JDK fails
while the SUN JDK works.
OK, for this particular example, I believe the only one to blame is the POM
author ;-). The buid fails because {{tricky-1.1.pom}} is simply corrupt:
According to its XML declaration, the file encoding is UTF-8. However, the
octet sequence \xF8 \x6C formed by the characters "øl" is no valid UTF-8 input.
The IBM JDKs before 1.6 seem to employ a strict decoder and hence abort file
reading with an exception.
Reproducing the NPE is the remaining challenge...
> FATAL ERROR and NPE on start
>
>
> Key: MNG-3580
> URL: http://jira.codehaus.org/browse/MNG-3580
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10
> 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64
> jvmxa6460-20080415_18762 (JIT enabled, AOT enabled)
> J9VM - 20080415_018762_LHdSMr
> JIT - r9_20080415_1520
> GC - 20080415_AA)
> JCL - 20080412_01
>Reporter: Erik Putrycz
> Fix For: 2.0.11
>
> Attachments: debug-output.patch, maven.log,
> MNG-3580-ibm-jdk-issues.zip, MNG-3580.patch
>
>
> Any mvn command does give me the following error message
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Business Rules Extractor
> [INFO] Business Rules Extractor core functions
> [INFO] COBOL Parser and ANTLR Tools
> [INFO] Business Rules Extractor data model
> [INFO] Documentation Extractor module
> [INFO] Extractor module
> [INFO] Business Rules Navigator
> WAGON_VERSION: 1.0-beta-2
> [INFO]
>
> [INFO] Building Business Rules Extractor
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164)
> at
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366)
> at
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168)
> at
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253)
> at
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main
[jira] Closed: (MSHARED-55) NLP IF no fileset directory specified.
[ http://jira.codehaus.org/browse/MSHARED-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MSHARED-55. Assignee: Benjamin Bentmann Resolution: Won't Fix > NLP IF no fileset directory specified. > -- > > Key: MSHARED-55 > URL: http://jira.codehaus.org/browse/MSHARED-55 > Project: Maven Shared Components > Issue Type: Bug > Components: file-management >Affects Versions: file-management 1.2 > Environment: all >Reporter: Petar Tahchiev >Assignee: Benjamin Bentmann > Attachments: massembly-342.txt, mshared55-ver.1.txt, > mshared55-ver1-testcase.txt > > > Hi guys I have created a patch for the MASSEMBLY-342 that should be applied > to FileSetManager. This patch fixes a but that can arise if you make > assemblies and in your assembly-descriptor you have filesets that don't > specify directory. > For further info please look here: > http://jira.codehaus.org/browse/MASSEMBLY-342 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCLEAN-29) Maven clean plugin doesn't filter resources from exclude list
[
http://jira.codehaus.org/browse/MCLEAN-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MCLEAN-29.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.3
Fixed in [r694394|http://svn.apache.org/viewvc?view=rev&revision=694394].
> Maven clean plugin doesn't filter resources from exclude list
> -
>
> Key: MCLEAN-29
> URL: http://jira.codehaus.org/browse/MCLEAN-29
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vladimir Sosnin
>Assignee: Benjamin Bentmann
> Fix For: 2.3
>
> Attachments: clean-exclude.zip, dont-delete-excluded-file-test.patch,
> dont-delete-excluded-file.patch
>
>
> For example you want to delete content of folder but want to keep folder
> itself and it's SCM (e.g. SVN) information. Following configuration for
> "maven-maven-clean" plugin deletes all plain files under ".svn" directory and
> simply keeps empty subdirs. Thus, making update command impossible.
> {code:xml}
>
> ...
>
>
> maven-clean-plugin
>
> true
>
>
> logic/src/test/generated/resources
>
> .svn/**/*
>
>
> **/*
>
> false
>
>
>
>
>
>
> {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: (MCLEAN-29) Maven clean plugin doesn't filter resources from exclude list
[
http://jira.codehaus.org/browse/MCLEAN-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCLEAN-29:
Affects Version/s: 2.2
> Maven clean plugin doesn't filter resources from exclude list
> -
>
> Key: MCLEAN-29
> URL: http://jira.codehaus.org/browse/MCLEAN-29
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vladimir Sosnin
> Attachments: clean-exclude.zip, dont-delete-excluded-file-test.patch,
> dont-delete-excluded-file.patch
>
>
> For example you want to delete content of folder but want to keep folder
> itself and it's SCM (e.g. SVN) information. Following configuration for
> "maven-maven-clean" plugin deletes all plain files under ".svn" directory and
> simply keeps empty subdirs. Thus, making update command impossible.
> {code:xml}
>
> ...
>
>
> maven-clean-plugin
>
> true
>
>
> logic/src/test/generated/resources
>
> .svn/**/*
>
>
> **/*
>
> false
>
>
>
>
>
>
> {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-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MNG-3580: Attachment: MNG-3580-ibm-jdk-issues.zip Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works. This example needs more work to show the same NPE's found in other more complex projects. I'll attach another example when I get a use-case that is repeatable. > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz > Fix For: 2.0.11 > > Attachments: debug-output.patch, maven.log, > MNG-3580-ibm-jdk-issues.zip, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) > at java.lang.refl
[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147686#action_147686
]
Michael Johns commented on SCM-406:
---
I have a little color I can add to this discussion. We too use Maven, but I'm
99% sure this has nothing to do with it. Here's what I've done:
# Ran a release in Maven; failed with the error everyone else is seeing (svn:
File '...' already exists) 2. In a command prompt on our build box, changed to
the project's working directory that was created by the Maven build. From
there, ran a "svn --non-interactive copy -m . "
manually (same command that Maven runs, save for an explicit message rather
than --file). Got the same error.
# Queried the working copy to see if any files were changed. No files were
changed, but about 10 new files were present (relics from the aborted build).
# Deleted the new files and ran the command again. Failed again with same
error.
# Ran an update on my working copy. No changes happened (no new files, deleted
files, or changed files), but something happened because...
# Ran the command again, and it worked.
Some things to note:
* We have a multi-module project.
* We're on Windows Server 2003.
* I installed SVN using various methods (msi, unzip), and they all fail. We
have 1.5.2 with the Apache 2.0 bindings.
* This problem doesn't happen with SVN 1.5.0, but it does happen with 1.5.1.
To me, this most definitely appears to be a SVN bug. I've also posted this to
the subversion users mailing list since it's really more relevant to them. But
I figured I'd cross-post it here to help exonerate Maven as the culprit.
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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-181) useRepositoryLayout does not create proper repository layout
useRepositoryLayout does not create proper repository layout Key: MDEP-181 URL: http://jira.codehaus.org/browse/MDEP-181 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.1 Reporter: Igor Fedorenko Assignee: Brian Fox Attachments: mdep-install-to-local.diff repository created with useRepositoryLayout=true does not contain repository metadata and does not have artifacts with expanded snapshot versions properly dealt with. Attached patch changes the code to use ArtifactInstaller to "install" artifacts to the target directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-264) Filtering in Assembly Generates Blank Files in the Archive
[ http://jira.codehaus.org/browse/MASSEMBLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-264. Assignee: John Casey Resolution: Cannot Reproduce reopen this if you find a way to reproduce it, and have a test project that will express the problem. > Filtering in Assembly Generates Blank Files in the Archive > -- > > Key: MASSEMBLY-264 > URL: http://jira.codehaus.org/browse/MASSEMBLY-264 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Neill Alexander >Assignee: John Casey > Fix For: 2.2-beta-3 > > Attachments: maven-assembly-plugin-bug-test.tar.gz > > > When filers are filtered during assembly, the result is an empty file in the > archive (see output from unzip below): > $ unzip -l assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Archive: assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Length Date TimeName > > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/test.ini > --- > 0 3 files > This appears to be a result of some recent changes to the > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java > file (changeset 591556) which deletes the files from the temporary > directory. The problem with this is that the archive object has a reference > to the filtered files in the temporary directory. When the call to > archive.createArchive( ) is made it can't find the filtered files, and > therefore they end up empty in the archive. > The attached archive contains a test maven project you can run which will > demonstrate this bug. Run 'mvn clean assembly:assembly' and check out the > contents of target/assembly-bug-1.0.0-SNAPSHOT-buggy.zip > The simply fix is simply to roll-back the 'finally' clause added as part of > 591556 to > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java. > Whether or not it is the best fix, I don't know (hence the absence of a > 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: (MNG-3751) Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository
Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository --- Key: MNG-3751 URL: http://jira.codehaus.org/browse/MNG-3751 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies, Reactor and workspace Affects Versions: 2.0.9, 2.0.8 Environment: Mac OS X 10.5.4, Windows XP SPx, CentOS 5.2 Reporter: Stephen Evanchik Attachments: full-dependency-tree.txt, master-compile-run.txt, maven-test.tar.gz Summary: Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository I cannot build either a leaf project (sub1-module1) or the master project (master) until I 'mvn install' the sub-modules (sub-module). I believe that dependency modules found only in the reactor should be added to: [DEBUG] (f) classpathElements = [/Users/evanchsa/src/maven-test/subproject1/sub1-module1/target/classes] Detailed setup: I have a multi-module project that is laid out in the following POM inheritance (this is not the filesystem layout): master + sub1-master - sub1-module1 - sub1-module2 + sub2-master - sub2-module1 - sub2-module2 Sub-modules are type "jar" and 1 "war" and there are dependencies within the sub-modules as follows (using mvn dependency:tree): 1. sub1-module1 - Depends on no other modules 2. sub1-module2 - test-group:sub1-module2:jar:0.0.1 \- test-group:sub1-module1:jar:0.0.1:compile 3. sub2-module1 - test-group:sub2-module1:jar:0.0.1 \- test-group:sub1-module2:jar:0.0.1:compile \- test-group:sub1-module1:jar:0.0.1:compile 4. sub2-module2 (this is the WAR) - test-group:sub2-module2:jar:0.0.1 \- test-group:sub2-module1:jar:0.0.1:compile \- test-group:sub1-module2:jar:0.0.1:compile \- test-group:sub1-module1:jar:0.0.1:compile Project filesystem layout: build/master/pom.xml subproject1/sub1-master/pom.xml subproject1/sub1-module1/pom.xml subproject1/sub1-module2/pom.xml subproject2/sub2-master/pom.xml subproject2/sub2-module1/pom.xml subproject2/sub2-module2/pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-226) Make XML based parsers better handle whitespace
[
http://jira.codehaus.org/browse/DOXIA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated DOXIA-226:
--
Fix Version/s: 1.0-beta-1
> Make XML based parsers better handle whitespace
> ---
>
> Key: DOXIA-226
> URL: http://jira.codehaus.org/browse/DOXIA-226
> Project: Maven Doxia
> Issue Type: Improvement
>Reporter: Benjamin Bentmann
> Fix For: 1.0-beta-1
>
>
> Regarding whitespace in XML documents, one needs to consider the following
> aspects:
> - ignorable whitespace, i.e. view "{{ }}" and
> "{{}}" as equivalent
> - collapsible whitespace, i.e. view "{{Text Text}}" and "{{Text
> Text}}" as equivalent
> - trimmable whitespace, i.e. view "{{ Text }}" and "{{Text}}"
> as equivalent
> Those distinctions require a DTD/XSD in combination with a validating parser
> and/or application-specific knowledge. For robustness, doxia parsers for
> XML-based formats should not depend on the existence of a schema definition
> such that they reliably deliver events into the sinks. Hence I suggest to
> hard-code the required logic for proper whitespace handling into each parser.
> Currently, whitespace handling is rather static, e.g. {{XhtmlBaseParser}}
> pushes all input whitespace into the sink. This might cause troubles with
> sinks that are not expected to receive ignorable whitespace. To address this
> issue, it seems helpful if {{AbstractXmlParser}} provided a default
> implementation of {{handleText()}} that subclasses can simply control via
> state flags instead of implementing {{handleText()}} from scratch in each
> parser. Copy&Paste - which caused DOXIA-225 - needs to be avoided.
> More precisely, I image the following changes:
> - Have {{AbstractXmlParser}} maintain a stack of tuples (ignorable,
> collapsible, trimmable) where each tuple describes the whitespace handling
> for the currently parsed element
> - Have {{AbstractXmlParser}} push/pop a tuple from this stack before/after
> calling {{handleStartTag()}}/{{handleEndTag()}}
> - Have {{AbstractXmlParser}} provide setters to allow subclasses to control
> the desired whitespace handling in their {{handleStartTag()}} implementation
> - Have {{AbstractXmlParser}} implement {{handleText()}} where it evalutes the
> top-most tuple from the stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-251) The AbstractXmlParser should take care of EOL
[
http://jira.codehaus.org/browse/DOXIA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-251.
-
Resolution: Duplicate
See DOXIA-226 instead of
> The AbstractXmlParser should take care of EOL
> -
>
> Key: DOXIA-251
> URL: http://jira.codehaus.org/browse/DOXIA-251
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-beta-1
>
>
> Take the following snippet:
> {noformat}
>
> EOL
>
> EOL
>
> ...
> {noformat}
> The AbstractXmlParser #parseXml() calls handleText( parser, sink ) for all EOL
--
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: (MDOCCK-14) Plugin does not respect generated documentation
[
http://jira.codehaus.org/browse/MDOCCK-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147679#action_147679
]
David J. M. Karlsen commented on MDOCCK-14:
---
Oh - I went through the issues but didn't notice that one - could 1.0-beta-3 be
released soon - it's been over a year since last rel.
> Plugin does not respect generated documentation
> ---
>
> Key: MDOCCK-14
> URL: http://jira.codehaus.org/browse/MDOCCK-14
> Project: Maven 2.x Documentation Checker Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-2
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Benjamin Bentmann
>
> The plugin does not respect generated content (from velocity templates), for
> example the project at:
> http://svn.codehaus.org/mojo/trunk/mojo/was6-maven-plugin/
> generates completely valid documentation - but the plugin fails with:
> [INFO] [docck:check {execution: verify}]
> [INFO] Checking project: WAS6 Maven Plugin
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 12 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [ERROR] The following documentation problems were found:
> o WAS6 Maven Plugin (3 errors, 0 warnings)
> [ERROR] There is no 'usage' file in your site directory (in apt|html|xml
> format).
> [ERROR] There are no example files in your site directory (in apt|html|xml
> format). They should either be called 'example*.(apt|html|xml)' or they
> should be located in the 'examples' directory.
> [ERROR] There is no 'faq' file in your site directory (in apt|fml|html|xml
> format).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHARED-64) FileSetManager.delete() does not delete empty directories if they contained symlink that was deleted
[
http://jira.codehaus.org/browse/MSHARED-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHARED-64.
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: file-management 1.2.1
Fixed in [r694311|http://svn.apache.org/viewvc?view=rev&revision=694311].
> FileSetManager.delete() does not delete empty directories if they contained
> symlink that was deleted
>
>
> Key: MSHARED-64
> URL: http://jira.codehaus.org/browse/MSHARED-64
> Project: Maven Shared Components
> Issue Type: Bug
> Components: file-management
>Affects Versions: file-management 1.2
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: file-management 1.2.1
>
>
> For the directory structure
> {noformat}
> ./
> dir/
> symlink
> {noformat}
> and the file set
> {code:xml}
>
>
> dir/**
>
> false
>
> {code}
> the directory {{dir}} won't be deleted although all its contents
> ({{symlink}}) have been deleted.
--
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: (MSHARED-64) FileSetManager.delete() does not delete empty directories if they contained symlink that was deleted
FileSetManager.delete() does not delete empty directories if they contained
symlink that was deleted
Key: MSHARED-64
URL: http://jira.codehaus.org/browse/MSHARED-64
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2
Reporter: Benjamin Bentmann
Priority: Minor
For the directory structure
{noformat}
./
dir/
symlink
{noformat}
and the file set
{code:xml}
dir/**
false
{code}
the directory {{dir}} won't be deleted although all its contents ({{symlink}})
have been deleted.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-30) Compiler fork executable fails when the path has spaces
[
http://jira.codehaus.org/browse/MCOMPILER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147672#action_147672
]
Philip Schwarz commented on MCOMPILER-30:
-
Apologies to everyone, the previous comment was a false alarm (loser error): I
was asking Maven to run a solaris jdk on a Windows box!!!
> Compiler fork executable fails when the path has spaces
> ---
>
> Key: MCOMPILER-30
> URL: http://jira.codehaus.org/browse/MCOMPILER-30
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Carlos Sanchez
> Fix For: 2.0.2
>
>
> JAVA_1_3_HOME=C:\Program Files\Java\jdk1.3.1_18
>
> maven-compiler-plugin
>
> true
> 1.3
> ${JAVA_1_3_HOME}/bin/javac
>
>
> Fails with
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-140) Add anchors to sections to be able to link them directly
Add anchors to sections to be able to link them directly Key: MPIR-140 URL: http://jira.codehaus.org/browse/MPIR-140 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependencies Affects Versions: 2.1 Reporter: Baptiste MATHUS Hi, It's somewhat a pity that a particular section of the dependency report could not be linked directly. For example, if I'm interested in the dependency tree part of the report, each time I (re)load the page, I'll have to scroll down to find what I'm looking for. (I seem to understand that this takes place in the maven-reporting-impl/AbstractMavenRenderer.startSection() method.) Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-30) Compiler fork executable fails when the path has spaces
[ http://jira.codehaus.org/browse/MCOMPILER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147671#action_147671 ] Philip Schwarz commented on MCOMPILER-30: - I am using Maven 2.0.9 and I have the problem even though there are no spaces in the path to the JDK : org.apache.maven.plugins maven-compiler-plugin 2.0.2 true true 1.5 1.5 1.5 C:/Views/KFL_1_0/vendors/etc/solaris/jdk1.5.0_05/bin/javac 128m 512m [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: 'C:\Views\KFL_1_0\vendors\etc\solaris\jdk1.5.0_05\bin\javac' is not recognized as an internal or external command, operable program or batch file. Failure executing javac, but could not parse the error: 'C:\Views\KFL_1_0\vendors\etc\solaris\jdk1.5.0_05\bin\javac' is not recognized as an internal or external command, operable program or batch file. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Compilation failure Failure executing javac, but could not parse the error: 'C:\Views\KFL_1_0\vendors\etc\solaris\jdk1.5.0_05\bin\javac' is not recognized as an internal or external command, operable program or batch file. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure Failure executing javac, but could not parse the error: 'C:\Views\KFL_1_0\vendors\etc\solaris\jdk1.5.0_05\bin\javac' is not recognized as an internal or external command, operable program or batch file. at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Sep 11 15:15:57 BST 2008 [INFO] Final Memory: 2M/9M [INFO] > Compiler fork executable fails when the path has spaces > --- > > Key: MCOMPILER-30 > URL: http://jira.codehaus.org/browse/MCOMPILER-30 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Carlos Sanchez > Fix For: 2.0.2 > > > JAVA_1_3_HOME=C:\Program Files\Java\jdk1.3.1_18 > > maven-compiler-plugin > > true >
[jira] Closed: (MDOCCK-14) Plugin does not respect generated documentation
[
http://jira.codehaus.org/browse/MDOCCK-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MDOCCK-14.
---
Assignee: Benjamin Bentmann
Resolution: Duplicate
> Plugin does not respect generated documentation
> ---
>
> Key: MDOCCK-14
> URL: http://jira.codehaus.org/browse/MDOCCK-14
> Project: Maven 2.x Documentation Checker Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-2
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Benjamin Bentmann
>
> The plugin does not respect generated content (from velocity templates), for
> example the project at:
> http://svn.codehaus.org/mojo/trunk/mojo/was6-maven-plugin/
> generates completely valid documentation - but the plugin fails with:
> [INFO] [docck:check {execution: verify}]
> [INFO] Checking project: WAS6 Maven Plugin
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 12 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [ERROR] The following documentation problems were found:
> o WAS6 Maven Plugin (3 errors, 0 warnings)
> [ERROR] There is no 'usage' file in your site directory (in apt|html|xml
> format).
> [ERROR] There are no example files in your site directory (in apt|html|xml
> format). They should either be called 'example*.(apt|html|xml)' or they
> should be located in the 'examples' directory.
> [ERROR] There is no 'faq' file in your site directory (in apt|fml|html|xml
> format).
--
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: (MSHARED-63) Filtering Resources does not match patterns strictly
Filtering Resources does not match patterns strictly
Key: MSHARED-63
URL: http://jira.codehaus.org/browse/MSHARED-63
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.0-beta-1
Reporter: Walter White
When using Maven Filtering, maven-war-plugin, variables within the JSP that do
not correspond to configured properties are updated as well ie.
[code]
${users.id}
${user.id}
${adfadfadf.id}
[/code]
All of those patterns are matched to the project id which causes the JSP throw
an exception. Having these properties set at build time lets me configure the
context.path and links dynamically depending on the environment. The problem
appears to be associated with the plexus pattern matching plugin as it is what
decides to match any variable ending in .id
I suggest that an option is added to configure which patterns are matched and
if the pattern matching is strict. For example, in my JSPs, it would be ideal
to only allow @context.path@ and not ${users.id} so the variables within the
JSP remain just that and configured properties are updated accordingly.
--
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] Reopened: (DOXIA-251) The AbstractXmlParser should take care of EOL
[
http://jira.codehaus.org/browse/DOXIA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton reopened DOXIA-251:
---
Need to review this commit to be sure
> The AbstractXmlParser should take care of EOL
> -
>
> Key: DOXIA-251
> URL: http://jira.codehaus.org/browse/DOXIA-251
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-beta-1
>
>
> Take the following snippet:
> {noformat}
>
> EOL
>
> EOL
>
> ...
> {noformat}
> The AbstractXmlParser #parseXml() calls handleText( parser, sink ) for all EOL
--
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: (MJAVADOC-126) Add the ability to load the stylesheet from a jar (resource)
[ http://jira.codehaus.org/browse/MJAVADOC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147657#action_147657 ] Julien Eluard commented on MJAVADOC-126: This feature seems to work only when the parent of project configured references resourcesArtifact artifact as module. In provided sample if I remove the modules section of root pom.xml, then run mvn clean javadoc:javadoc under test folder files are not correctly copied. Is this the intended behavior? > Add the ability to load the stylesheet from a jar (resource) > > > Key: MJAVADOC-126 > URL: http://jira.codehaus.org/browse/MJAVADOC-126 > Project: Maven 2.x Javadoc Plugin > Issue Type: Wish >Affects Versions: 2.2 >Reporter: Julien S >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.5 > > Attachments: > 20080520-maven-javadoc-plugin-external-resources-integration-tests.zip, > 20080520-maven-javadoc-plugin-external-resources.patch, > 20080530-maven-javadoc-plugin-external-resources-integration-tests.zip, > 20080530-maven-javadoc-plugin-external-resources.patch > > > Currently, the stylesheetfile has to be given as a path on the filesystem, > which makes sharing quite difficult. > It would be nice to be able to retrieve it from a jar (like the checkstyle > and the pmd plugins). -- 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: (MJAVADOC-216) Stylesheet file loaded from classpath
[ http://jira.codehaus.org/browse/MJAVADOC-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147652#action_147652 ] Julien Eluard commented on MJAVADOC-216: The thing is I don't want to rely on file path to load the stylesheet because ultimately my stylesheet will be stored in a parent dependency. When using 'maven' as stylesheet property (http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#stylesheet) maven-javadoc-plugin loads from classpath org/apache/maven/plugin/javadoc/css/stylesheet.css but I can't provide my own stylesheet.css file. > Stylesheet file loaded from classpath > - > > Key: MJAVADOC-216 > URL: http://jira.codehaus.org/browse/MJAVADOC-216 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: Julien Eluard >Priority: Minor > Attachments: custom-stylesheet.zip > > > stylesheetfile can only be loaded from a file path. To allow common > stylesheet definition it would be nice to load stylesheetfile from classpath. > Such a feature could be provided by extending the stylesheet type "maven" by > allowing to provide your own stylesheet.css and not only the default maven > one. -- 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: (MJAVADOC-216) Stylesheet file loaded from classpath
[
http://jira.codehaus.org/browse/MJAVADOC-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147650#action_147650
]
Vincent Siveton commented on MJAVADOC-216:
--
According your test case, you need to call:
{noformat}
mvn javadoc:javadoc
-Dstylesheetfile=${basedir}\src\resources\org\apache\maven\pugin\javadoc\css\stylesheet.css
{noformat}
See MJAVADOC-126 about resourcesArtifacts
Could you confirm that I could close this issue as not bug?
> Stylesheet file loaded from classpath
> -
>
> Key: MJAVADOC-216
> URL: http://jira.codehaus.org/browse/MJAVADOC-216
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Reporter: Julien Eluard
>Priority: Minor
> Attachments: custom-stylesheet.zip
>
>
> stylesheetfile can only be loaded from a file path. To allow common
> stylesheet definition it would be nice to load stylesheetfile from classpath.
> Such a feature could be provided by extending the stylesheet type "maven" by
> allowing to provide your own stylesheet.css and not only the default maven
> one.
--
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: (MJAVADOC-216) Stylesheet file loaded from classpath
[ http://jira.codehaus.org/browse/MJAVADOC-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147647#action_147647 ] Julien Eluard commented on MJAVADOC-216: I was not aware of the resourcesArtifacts feature. What is the behaviour? Will all files from artifacts' src/resources be copied under reportOutputDirectory? > Stylesheet file loaded from classpath > - > > Key: MJAVADOC-216 > URL: http://jira.codehaus.org/browse/MJAVADOC-216 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: Julien Eluard >Priority: Minor > Attachments: custom-stylesheet.zip > > > stylesheetfile can only be loaded from a file path. To allow common > stylesheet definition it would be nice to load stylesheetfile from classpath. > Such a feature could be provided by extending the stylesheet type "maven" by > allowing to provide your own stylesheet.css and not only the default maven > one. -- 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: (MJAVADOC-216) Stylesheet file loaded from classpath
[ http://jira.codehaus.org/browse/MJAVADOC-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Eluard updated MJAVADOC-216: --- Attachment: custom-stylesheet.zip Test case > Stylesheet file loaded from classpath > - > > Key: MJAVADOC-216 > URL: http://jira.codehaus.org/browse/MJAVADOC-216 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: Julien Eluard >Priority: Minor > Attachments: custom-stylesheet.zip > > > stylesheetfile can only be loaded from a file path. To allow common > stylesheet definition it would be nice to load stylesheetfile from classpath. > Such a feature could be provided by extending the stylesheet type "maven" by > allowing to provide your own stylesheet.css and not only the default maven > one. -- 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: (MNGSITE-4) broken links on http://maven.apache.org/plugins
[ http://jira.codehaus.org/browse/MNGSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147638#action_147638 ] Jonathan Ramsey commented on MNGSITE-4: --- Issue MDOAP-14 committed in [r678078|http://svn.apache.org/viewvc?view=rev&revision=678078] fixed the broken link http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html by removing it from index.apt. This fix was included in version 1.0 of maven-doap-plugin, released on 01 Aug 2008. Issue MVERIFIER-2 committed in [r554361|http://svn.apache.org/viewvc?view=rev&revision=554361] fixed the broken link http://maven.apache.org/plugins/maven-verifier-plugin/faq.html by adding faq.fml. This fix is marked for inclusion in version 1.0 of maven-verifier-plugin, but hasn't been released yet. Once maven-verifier-plugin 1.0 has been released, all the links in this issue will have been fixed. > broken links on http://maven.apache.org/plugins > --- > > Key: MNGSITE-4 > URL: http://jira.codehaus.org/browse/MNGSITE-4 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Tom Huybrechts > > a list of broken links on the maven site > http://maven.apache.org/plugins/maven-repository-plugin/faq.html > http://maven.apache.org/plugins/maven-war-plugin/faq.html > http://maven.apache.org/plugins/maven-dependency-plugin/faq.html > http://maven.apache.org/plugins/maven-docck-plugin/taglist.html > http://maven.apache.org/plugins/maven-repository-plugin/usage.html > http://maven.apache.org/plugins/maven-jxr-plugin/faq.html > http://maven.apache.org/plugins/maven-checkstyle-plugin/dependencies.html > http://maven.apache.org/plugins/maven-verifier-plugin/faq.html > http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html > http://maven.apache.org/plugins/maven-ejb-plugin/usage.html > http://maven.apache.org/plugins/maven-ejb-plugin/faq.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: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147634#action_147634
]
Olivier Lamy commented on MRESOURCES-29:
yup have a look here [http://svn.apache.org/viewvc?view=rev&revision=694005]
> An escape mechanism for property interpolation is missing.
> --
>
> Key: MRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRESOURCES-29
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Hendrik Schreiber
>Assignee: Olivier Lamy
> Fix For: 2.3
>
>
> It would be great, if there was a mechanism that let's you escape a property
> so that it is not replaced by the filtering machism. E.g. in a log4j.xml
> configuration file you might want to preserve ${user.home}, but replace some
> other property like ${log.dir}. Currently there is no convenient way to
> achieve that.
> Alternatively to escaping, it would be helpful, if one could choose the token
> format. So, if one could say, only honor @token@ and not ${token} (or the
> other way around) one could easily work around the escape problem.
> Workaround for the problem mentioned above:
> replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
> start=${and end=$} in the property file
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147630#action_147630
]
Maik Ebert commented on MRESOURCES-29:
--
Will this also be documented on the plugin homepage?
> An escape mechanism for property interpolation is missing.
> --
>
> Key: MRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRESOURCES-29
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Hendrik Schreiber
>Assignee: Olivier Lamy
> Fix For: 2.3
>
>
> It would be great, if there was a mechanism that let's you escape a property
> so that it is not replaced by the filtering machism. E.g. in a log4j.xml
> configuration file you might want to preserve ${user.home}, but replace some
> other property like ${log.dir}. Currently there is no convenient way to
> achieve that.
> Alternatively to escaping, it would be helpful, if one could choose the token
> format. So, if one could say, only honor @token@ and not ${token} (or the
> other way around) one could easily work around the escape problem.
> Workaround for the problem mentioned above:
> replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
> start=${and end=$} in the property file
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
