[jira] (MNG-5726) Update OS Activation To Allow Wildcards In OS Version
Andy Lehane created MNG-5726:
Summary: Update OS Activation To Allow Wildcards In OS Version
Key: MNG-5726
URL: https://jira.codehaus.org/browse/MNG-5726
Project: Maven
Issue Type: Improvement
Components: Profiles
Affects Versions: 3.2.3, 3.1.1
Environment: RHEL/CentOs
Reporter: Andy Lehane
Priority: Minor
Attachments: maven-os-version-patch-3.2.3.zip
I'm attempting to use maven to build a legacy project that requires different
dependecies based on the operating system version, i.e:
- version 1.0 of a platform specific library for Red Hat Linux 5
- version 1.1 of a platform specific library for Red Hat Linux 6
- version 1.4a of a platform specific library for Windows and
- version 1.3b of (a platform specific library for Solaris.
I can configure my pom file to get activate specific profiles for RHEL, Win and
Solaris but cannot distinguish between Red Hat 5 and 6 unless I use the full
version string, which is of the form 2.6.32-504.1.3.el6.x86_64.
As this Linux version will change whenever patch updates are installed, this
will make maintaining the pom/project akward.
To solve this, it would be good to be able to specify wildcard's in the os
version tag. I have taken a look at the range checking (for example, as applied
to the JdkVersion), but don't think this method would be sufficient, as the
specific part of the Red Hat version number we require is buried over half way
into the version string (i.e. el6 of the version 2.6.32-504.1.3.el6.x86_64).
It would be nice to be able to have something like:
{code}
profile
idlinux-rhel5/id
activation
activeByDefaultfalse/activeByDefault
os
familyunix/family
nameLinux/name
version*el5*/version
/os
/activation
properties
.
{code}
I've taken a look at the OperatingSystemProfileActivator code and have created
a patch that will use ^ to signify that the text is a regular expression, for
example:
{code}
version^.*(el5).*/version
{code}
I've also kept the ! notation, so the following can also be used:
{code}
version!^.*(el5).*/version
{code}
The patch added contains a unit test for the OperatingSystemProfileActivator in
the maven-model-builder project (warning: it's a nasty test but I couldn't find
a nicer way of being able to reliably manuplate the OS Version).
I've also patch the OperatingSystemProfileActivator class in the maven-compat
project but have not been able to write a unit test for that class.
Can this updated be considered for implementation/inclusion please?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-93) Make IndexingContext and actual underlying Lucene index separated
Tamás Cservenák created MINDEXER-93: --- Summary: Make IndexingContext and actual underlying Lucene index separated Key: MINDEXER-93 URL: https://jira.codehaus.org/browse/MINDEXER-93 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Make IndexingContext and actual underlying Lucene index separated, to be able to make multiple contexts share same index. Currently, there is no way to make it, still, the change should be fairly simple, as context should basically just filter for repoId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-386) Wildcard does not work wiht null classifier
Kristian Rosenvold created MSHARED-386: -- Summary: Wildcard does not work wiht null classifier Key: MSHARED-386 URL: https://jira.codehaus.org/browse/MSHARED-386 Project: Maven Shared Components Issue Type: Bug Components: maven-common-artifact-filters Reporter: Kristian Rosenvold See MASSEMBLY-607 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-386) Wildcard does not work with null classifier
[ https://jira.codehaus.org/browse/MSHARED-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-386: --- Summary: Wildcard does not work with null classifier (was: Wildcard does not work wiht null classifier) Wildcard does not work with null classifier --- Key: MSHARED-386 URL: https://jira.codehaus.org/browse/MSHARED-386 Project: Maven Shared Components Issue Type: Bug Components: maven-common-artifact-filters Reporter: Kristian Rosenvold See MASSEMBLY-607 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-724) Can't include unpacked subsets twice (a variant of unpackedSubsetsTwice IT)
[
https://jira.codehaus.org/browse/MASSEMBLY-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-724.
Resolution: Fixed
Fix Version/s: 2.5.2
Assignee: Kristian Rosenvold
This was fixed for 2.5.2 and is in some sense a duplicate of other issues
Can't include unpacked subsets twice (a variant of unpackedSubsetsTwice IT)
---
Key: MASSEMBLY-724
URL: https://jira.codehaus.org/browse/MASSEMBLY-724
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5
Environment: Any
Reporter: Dawid Weiss
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.5.2
Attachments: dependencySet-unpackedSubsetsTwice.zip
This is a variation of unpackedSubsetsTwice IT; the only difference is that
we want to unpack the saame dependency twice, into the same folder (with
different include/ exclude patterns). The second dependency is skipped with a
message:
{code}
[WARNING] Archive:
C:\_tmp\dependencySet-unpackedSubsetsTwice\child1\target\child1-1.0-SNAPSHOT.jar
has already been add
ed. Skipping.
{code}
The reason for doing this is that you can have multiple dependency set
inclusions, each specifying its own fileMode, for example.
I've modified dependencySet-unpackedSubsetsTwice IT slightly, but it's pretty
simple to reproduce.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-724) Can't include unpacked subsets twice (a variant of unpackedSubsetsTwice IT)
[
https://jira.codehaus.org/browse/MASSEMBLY-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356869#comment-356869
]
Dawid Weiss commented on MASSEMBLY-724:
---
I confirm, works in 2.5.2. Thanks.
Can't include unpacked subsets twice (a variant of unpackedSubsetsTwice IT)
---
Key: MASSEMBLY-724
URL: https://jira.codehaus.org/browse/MASSEMBLY-724
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5
Environment: Any
Reporter: Dawid Weiss
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.5.2
Attachments: dependencySet-unpackedSubsetsTwice.zip
This is a variation of unpackedSubsetsTwice IT; the only difference is that
we want to unpack the saame dependency twice, into the same folder (with
different include/ exclude patterns). The second dependency is skipped with a
message:
{code}
[WARNING] Archive:
C:\_tmp\dependencySet-unpackedSubsetsTwice\child1\target\child1-1.0-SNAPSHOT.jar
has already been add
ed. Skipping.
{code}
The reason for doing this is that you can have multiple dependency set
inclusions, each specifying its own fileMode, for example.
I've modified dependencySet-unpackedSubsetsTwice IT slightly, but it's pretty
simple to reproduce.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-603) ${maven.build.timestamp} placeholder is not filtered
[
https://jira.codehaus.org/browse/MASSEMBLY-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356881#comment-356881
]
Kristian Rosenvold commented on MASSEMBLY-603:
--
This is an interesting issue because the interpolation context created in maven
core is not used inside the assembly plugin, which is basically the root cause
of this problem.
Since the context setup is duplicated (and slightly different!) inside assembly
plugin, we run into problems like this.
The good solution to this would of course be to somehow inherit the
interpolator from maven core. The bad would be to simply expand the duplication
to include the missing values. The suggested workaround causes maven core to
interpolate the expression into a value that is used by the plugin, which also
works :)
${maven.build.timestamp} placeholder is not filtered
Key: MASSEMBLY-603
URL: https://jira.codehaus.org/browse/MASSEMBLY-603
Project: Maven Assembly Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.3, 2.4
Reporter: Igor Bljahhin
Priority: Minor
Attachments: assembly-issue.zip
When filtering files in assembly plugin most of placeholders are replaced
with values,
but Maven's property maven.build.timestamp (described here
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html in
Special Variables section) is not substituted with value.
Run mvn clean package in the test project and you will get
target/assembly-issue-0.0.1-SNAPSHOT-dist.zip archive. Open index.html from
archive and you will see that property project.version was replaced during
assembly, but maven.build.timestamp was left untouched.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-395) Module dependencies not included
[ https://jira.codehaus.org/browse/MASSEMBLY-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356892#comment-356892 ] Jaan Vajakas commented on MASSEMBLY-395: Thank you! Module dependencies not included - Key: MASSEMBLY-395 URL: https://jira.codehaus.org/browse/MASSEMBLY-395 Project: Maven Assembly Plugin Issue Type: Bug Components: moduleSet Affects Versions: 2.2-beta-3 Environment: Maven version: 2.0.9 Java version: 1.5.0_09 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Jaan Vajakas Assignee: Kristian Rosenvold Fix For: 2.5.1 Attachments: my-app.assembly-plugin-2.2.zip, my-app.zip Maven assebly plugin 2.2-beta-3 does not include module dependencies, even when the explicit includeDependenciestrue/includeDependencies is used in assembly descriptor. Maven assebly plugin 2.2-beta-2 did not have this issue. See the attached project: running mvn package for the parent project my-app creates a ZIP that contains only my-app-module1-1.0-SNAPSHOT.jar. If assembly plugin 2.2-beta-2 is used (i.e. if one replaces 2.2-beta-3 with 2.2-beta-2 in pom.xml of my-app) then the ZIP also contains my-app-module2-1.0-SNAPSHOT.jar and junit-3.8.1.jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Reeves updated MNG-5102: - Attachment: daddy-repaintio-tiles.zip Tiles example by Tony Lampada, converted to work with repaintio version of the plugin (which is the currently supported version) Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven Issue Type: Wish Components: FDPFC, POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: Issues to be reviewed for 4.x Attachments: daddy3.zip, daddy-repaintio-tiles.zip, maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Reeves updated MNG-5102: - Comment: was deleted (was: Tiles example by Tony Lampada, converted to work with repaintio version of the plugin (which is the currently supported version)) Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven Issue Type: Wish Components: FDPFC, POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: Issues to be reviewed for 4.x Attachments: daddy3.zip, maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Reeves updated MNG-5102: - Attachment: (was: daddy-repaintio-tiles.zip) Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven Issue Type: Wish Components: FDPFC, POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: Issues to be reviewed for 4.x Attachments: daddy3.zip, maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
Igor Fedorenko created MNG-5727:
---
Summary: unexpected InvalidArtifactRTException from
ProjectBuilder#build
Key: MNG-5727
URL: https://jira.codehaus.org/browse/MNG-5727
Project: Maven
Issue Type: Bug
Reporter: Igor Fedorenko
Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
InvalidArtifactRTException below if project pom.xml has managed dependency
without version. Although the pom is invalid, I expected to get
ProjectBuildingException that includes location of problematic dependency,
similar to what I get during command line build.
{code}
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.apache.maven.its:a:null:jar}: The version cannot be empty.
at
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
at
org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:123)
at
org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
at
org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
at
org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
at
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
...
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-734) Control timestamps on archived files
Leonid Ilyevsky created MASSEMBLY-734: - Summary: Control timestamps on archived files Key: MASSEMBLY-734 URL: https://jira.codehaus.org/browse/MASSEMBLY-734 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.5.1, 2.5.2 Environment: Linux, java 8 Reporter: Leonid Ilyevsky Need to have some control on the creation time stamp of the files included in the archive. It may be very important on the filtered files. For example, I have a script that is filtered based on the project version. Let say, the script itself does not change, but the project version changes. On the next deployment, in the production place where the archive is unpacked, the script is different, but its time stamp is old (it matches the time of the source file). So, when I do ls -l, it gives me an impression that the script was not updated, while it actually was. Even for the files that are not filtered, I may want to touch all files when archiving, so that when I unpack, I clearly see that the files are updated. The plain tar command has an option to do what I described. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPXDOC-193) Under IBM JDK 1.3 the maximum number of generated pages is 32.
[ https://jira.codehaus.org/browse/MPXDOC-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPXDOC-193. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Under IBM JDK 1.3 the maximum number of generated pages is 32. -- Key: MPXDOC-193 URL: https://jira.codehaus.org/browse/MPXDOC-193 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.8, 1.9, 1.9.1 Environment: Windows XP-SP2, Maven 1.0.2, Xerces 1.4.4 Reporter: Vincent Hindriksen Under IBM JDK 1.3 the maximum number of generated pages is 32. Page 33 and up are just copies of the xml-files. This is probably a bug in Xerces, but I don't know how to reproduce it without Xdocs. Reproducing is easy. Just create 33 identical xml-files and see that 1 of them is not compiled. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJNLP-28) Signing jars should remove old signatures
[ https://jira.codehaus.org/browse/MPJNLP-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJNLP-28. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Signing jars should remove old signatures - Key: MPJNLP-28 URL: https://jira.codehaus.org/browse/MPJNLP-28 Project: Maven 1.x JNLP Plugin Issue Type: Bug Affects Versions: 1.4.1 Reporter: Geoffrey De Smet Using jdk webstart 1.5: When signing a dependend jar that is already signed (for example acegic-security-0.8.2.jar), the new jar has 2 .RSA and .SF files (but each class is only signed once). But webstart can't handle this (it should but it doesn't) and it says that not all jars are signed by the same certificate. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPRELEASE-2) convert-snapshots does not change pom
[ https://jira.codehaus.org/browse/MPRELEASE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPRELEASE-2. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. convert-snapshots does not change pom - Key: MPRELEASE-2 URL: https://jira.codehaus.org/browse/MPRELEASE-2 Project: Maven 1.x Release Plugin Issue Type: Bug Environment: maven-rc1, win2k Reporter: Oliver Noelle Invoking convert-snapshots-auto seems to touch my project.xml and creates a project.xml.backup, but the SNAPSHOT within the version tag remains the same. Invoking convert-snapshots interactively correctly identifies the SNAPSHOT versions and asks for updating it, but as with -auto does not change anything in the end... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMULTIPROJECT-51) Mixing different maven.build.dir settings in multiproject fails
[ https://jira.codehaus.org/browse/MPMULTIPROJECT-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMULTIPROJECT-51. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Mixing different maven.build.dir settings in multiproject fails --- Key: MPMULTIPROJECT-51 URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-51 Project: Maven 1.x Multi-Project Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Martijn Dashorst If two projects have different maven.build.dir settings, the multiproject will assume that the artifacts of project A are actually in the maven.build.dir directory of project B (or vice versa). Project A, project.properties maven.build.dir=build Project B, project.properties maven.build.dir=target Project B depends on Project A Using the multiproject plugin for say multiproject:install will fail. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPAPPSERVER-2) App server plugin docs are out of date
[ https://jira.codehaus.org/browse/MPAPPSERVER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPAPPSERVER-2. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. App server plugin docs are out of date -- Key: MPAPPSERVER-2 URL: https://jira.codehaus.org/browse/MPAPPSERVER-2 Project: Maven 1.x AppServer Plugin Issue Type: Bug Reporter: Ben Walding Attachments: appserver.patch, jetty-4.x.jelly Original Estimate: 1 hour Remaining Estimate: 1 hour The app server docs should be updated to match the plugin. They are a mess of J2EE plugin references -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJNLP-24) jnlp:generate-keystore Fails with IOException in IBMJDK142
[ https://jira.codehaus.org/browse/MPJNLP-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJNLP-24. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. jnlp:generate-keystore Fails with IOException in IBMJDK142 -- Key: MPJNLP-24 URL: https://jira.codehaus.org/browse/MPJNLP-24 Project: Maven 1.x JNLP Plugin Issue Type: Bug Affects Versions: 1.4.1 Environment: Windows XP / IBMJDK142 Reporter: Neil Crow When building with IBMJDK142, the error below occurs. The build goes through when I change to j2sdk1.4.1_05 from Sun. C:\java\IBM-Eclipse\eclipse\workspace\STRATE_GATEWAY\GATEWAY_GUI_WEBmaven -e clean war:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 build:start: clean:clean: [echo] clean:deleting JNLP KeyStore clean: war:init: jnlp:init: jnlp:generate-keystore: [genkey] Generating Key for Gateway BUILD FAILED Execute failed: java.io.IOException: CreateProcess: keytool -genkey -alias Gatew ay -dname CN=Gateway ,OU=Java Team ,O=STRATE ,L=Illovo ,S=Fricker Road ,C=South Africa -keystore C:\java\IBM-Eclipse\eclipse\workspace\STRATE_GATEWAY\GATEWAY_ GUI_WEB/GatewayKeystore -storepass password -storetype jks -keypass password -va lidity 720 error=2 at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:371) at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:250) at org.apache.tools.ant.taskdefs.GenerateKey.execute(GenerateKey.java:40 9) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai nGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.PreGoalTag$1.firePreGoal(PreGoalTag.java:87) at com.werken.werkz.Goal.firePreGoalCallbacks(Goal.java:691) at com.werken.werkz.Goal.fire(Goal.java:616) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 634) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.io.IOException: CreateProcess: keytool -genkey -alias Gateway -d name CN=Gateway ,OU=Java Team ,O=STRATE ,L=Illovo ,S=Fricker Road ,C=South Afri ca -keystore C:\java\IBM-Eclipse\eclipse\workspace\STRATE_GATEWAY\GATEWAY_GUI_W EB/GatewayKeystore -storepass password -storetype jks -keypass password -validit y 720 error=2 at java.lang.Win32Process.create(Native Method) at java.lang.Win32Process.init(Win32Process.java:98) at java.lang.Runtime.execInternal(Native Method) at
[jira] (MPJNLP-26) Add Shortcut support for jnlp plug-in
[ https://jira.codehaus.org/browse/MPJNLP-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJNLP-26. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Add Shortcut support for jnlp plug-in - Key: MPJNLP-26 URL: https://jira.codehaus.org/browse/MPJNLP-26 Project: Maven 1.x JNLP Plugin Issue Type: Bug Environment: JDK 1.5 Reporter: Jeff Campbell JNLP Plug-in NEEDS to have a shortcut property. With JDK 1.5, Java Web Start NO LONGER automatically prompts the user to add a short cut. So, you have to manually edit the jnlp file everytime (after running maven jnlp) to make sure you add the following the XML in the information/ section of the code. shortcut online=false desktop/ /shortcut This should be a EASY EASY fix -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPXDOC-143) Apache copyright statement in xdocs generated by Maven
[ https://jira.codehaus.org/browse/MPXDOC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPXDOC-143. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Apache copyright statement in xdocs generated by Maven -- Key: MPXDOC-143 URL: https://jira.codehaus.org/browse/MPXDOC-143 Project: Maven 1.x XDoc Plugin Issue Type: Bug Reporter: Guy Rixon Priority: Minor In xdocs generated by Maven - typically the standard project reports - there is a copyright statement in favour of the Apache Software Foundation. IANAL, but this can't be right: the supplier of an authoring system doesn't get to assert copyright over documents made with that system. The copyright is only in the xdoc XML and doesn't get propagated to the HTML on the deployed web-site. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJAR-56) Per package package name invalid in manifest
[
https://jira.codehaus.org/browse/MPJAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJAR-56.
---
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Per package package name invalid in manifest
Key: MPJAR-56
URL: https://jira.codehaus.org/browse/MPJAR-56
Project: Maven 1.x Jar Plugin
Issue Type: Bug
Affects Versions: 1.8.1
Environment: Windows XP, Maven 1.1 release, JDK 1.4, 1.5 and 1.6
Reporter: Josselin Pujo
Priority: Minor
Package versionning has been moved from the Jar level to the package level in
Maven 1.1, wich is better for jar merging tools.
But the package name generated by maven is generated by the following rule:
util:replace var=packagePath oldChar=. newChar=/
value=${pom.package}/
wich does not add the final / to the package name.
Replacing
util:replace var=packagePath oldChar=. newChar=/
value=${pom.package}/
ant:section name=${packagePath}
With
util:replace var=packagePath oldChar=. newChar=/
value=${pom.package}/
ant:section name=${packagePath}/
Solves the problem.
Best regards,
Josselin Pujo
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPRELEASE-8) Message is shown even when there are no snapshot dependencies
[ https://jira.codehaus.org/browse/MPRELEASE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPRELEASE-8. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Message is shown even when there are no snapshot dependencies - Key: MPRELEASE-8 URL: https://jira.codehaus.org/browse/MPRELEASE-8 Project: Maven 1.x Release Plugin Issue Type: Bug Reporter: Carlos Sanchez Priority: Trivial Maven asks even if there are no snapshot dependencies There are 0 snapshot dependencies, would you like to update them to use timestamped versions? [yes] -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-21) Exception in thread main java.io.FileNotFoundException: jcoverage.ser (No such file or directory)
[ https://jira.codehaus.org/browse/MPJCOVERAGE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-21. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Exception in thread main java.io.FileNotFoundException: jcoverage.ser (No such file or directory) --- Key: MPJCOVERAGE-21 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-21 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Affects Versions: 1.0.7 Reporter: Håvard Bjåstad We have several projects that run fine, but with two of our projects we get the following output: jcoverage:html-report: [echo] Copying 2 source directories into one for jcoverage jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY [report] Exception in thread main java.io.FileNotFoundException: jcoverage.ser (No such file or directory) [report]at java.io.FileInputStream.open(Native Method) [report]at java.io.FileInputStream.init(FileInputStream.java:106) [report]at com.jcoverage.coverage.reporting.xml.Main.main(Main.java:106) org.apache.commons.jelly.JellyTagException: /home/havard/.maven/cache/maven-jcoverage-plugin-1.0.7/plugin.jelly:193:91: report org.apache.tools.ant.BuildException Maybe the problem is that these projects have two source directories, and jcoverage can't handle that? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPREPO-7) repository:* goals build wrong SSH command line
[
https://jira.codehaus.org/browse/MPREPO-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPREPO-7.
---
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
repository:* goals build wrong SSH command line
---
Key: MPREPO-7
URL: https://jira.codehaus.org/browse/MPREPO-7
Project: Maven 1.x Repository Plugin
Issue Type: Bug
Environment: Windows XP, JRE 1.4.2, Maven 1.0, Ant 1.5.3 / 1.6.2
Reporter: Dmitry Andrianov
maven-repository-plugin-1.2
define:tag name=exec
...
exec dir=. executable=${maven.ssh.executable}
arg line='${maven.repo.central} -l ${maven.username} ${command}'/
/exec
/define:tag
This means SSH command line will look like
SSH host -l user command
But manpage for any SSH I know says -lusername goes BEFORE hostname. And
although it still works on UNIXes, it does not work with SecureCRT
implementation of command line ssh client.
If I put -lusername before hostname, everything start working.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPECLIPSE-125) M1: If using JAR override, new sources feature does not work.
[ https://jira.codehaus.org/browse/MPECLIPSE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPECLIPSE-125. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. M1: If using JAR override, new sources feature does not work. - Key: MPECLIPSE-125 URL: https://jira.codehaus.org/browse/MPECLIPSE-125 Project: Maven 1.x Eclipse Plugin Issue Type: Bug Affects Versions: 1.11 Reporter: Jamie Bisotti I'm using SNMP4J, version 1.7.2. This project does not currently reside in any public repositories, so we have it in a 'lib' directory in our SCM and use a jar override to pick it up. I downloaded the source for it and placed it in my local repository. When I run maven eclipse, it never even attempts to look for this source. Seems like overridden dependencies are ignored. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPTEST-73) test:test goal results in double invocation of java:compile goal
[ https://jira.codehaus.org/browse/MPTEST-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPTEST-73. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. test:test goal results in double invocation of java:compile goal Key: MPTEST-73 URL: https://jira.codehaus.org/browse/MPTEST-73 Project: Maven 1.x Test Plugin Issue Type: Bug Affects Versions: 1.8.2 Environment: All environments Reporter: Alex Volanis The test:test goal has been modified to conditionally invoke test:compile via attainGoal(test:compile). This was previously done with the prereqs attribute. Doing so caused the java:compile and all pre/post goals associated to fire twice. You can witness this behaviour even when compiling MAven 1.1 from source. It seems unnecessary to do this for the test:test goal which conditionally skips the tests when test:compile also conditionally skips compiling. Making the same operation for test:single which intentionally omits the check for maven.test.skip makes a lot of sense. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPSCM-84) Intermittent failure with almost unhelpful message
[ https://jira.codehaus.org/browse/MPSCM-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPSCM-84. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Intermittent failure with almost unhelpful message -- Key: MPSCM-84 URL: https://jira.codehaus.org/browse/MPSCM-84 Project: Maven 1.x SCM Plugin Issue Type: Bug Affects Versions: 1.6 Environment: winxp Reporter: dion gillard [echo] Updating from SCM BUILD FAILED File.. file:/C:/Documents and Settings/db2admin/.maven/cache/maven-multiproject-plugin-1.5/plugin.jelly Element... maven:reactor Line.. 227 Column 64 Unable to obtain goal [scm:update] -- file:/C:/Documents and Settings/db2admin/.maven/cache/maven-scm-plugin-1.6/plugin.jelly:169:44: scm:update Error starting container Total time : 9 minutes 36 seconds Finished at : Friday, 11 August 2006 10:29:43 AM Error starting container doesn't help the user determine a solution to the problem. I have yet to be able to recreate this with -e as it's an intermittent issue. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJAR-44) linefeeds in pom fields result in corrupt jar manifest
[ https://jira.codehaus.org/browse/MPJAR-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJAR-44. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. linefeeds in pom fields result in corrupt jar manifest -- Key: MPJAR-44 URL: https://jira.codehaus.org/browse/MPJAR-44 Project: Maven 1.x Jar Plugin Issue Type: Bug Reporter: Brett Porter (originally filed by Timo Santasalo ) When the plugin creates manifest using data from pom, certain fields (such as shortDescription, I didn't test others but I see no reason why this issue won't affect them as well) doesn't seem to be properly filtered of disallowed characters, such as linefeeds. For example, the following piece of pom: shortDescription blah blah blah blah /shortDescription ...becomes in manifest something like this: Specification-Title: blah blah blah blah ...resulting in corrupted manifest. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCLOVER-47) Clover report is not generated when using Maven AspectJ plugin
[ https://jira.codehaus.org/browse/MPCLOVER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCLOVER-47. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Clover report is not generated when using Maven AspectJ plugin -- Key: MPCLOVER-47 URL: https://jira.codehaus.org/browse/MPCLOVER-47 Project: Maven 1.x Clover Plugin Issue Type: Bug Affects Versions: 1.10 Environment: Maven 1.0.2 on Windows XP Reporter: Glauber Vinícius Ferreira Priority: Blocker Attachments: aspectjtest.zip, Introduction Example.zip When I am using AspectJ plugin with this lines in my maven.xml file: preGoal name=java:compile attainGoal name=aspectj/ /preGoal the Clover report is not generated. The following message is presented: clover:report: [echo] No Clover database found, skipping report generation The folder target\clover\database stays empty. -- When I am using AspectJ plugin with this lines in my maven.xml file: preGoal name=java:compile attainGoal name=aspectj:compile/ /preGoal an empty Clover report is generated, although there is one test in the project. The following message is presented: [clover-report] No coverage data found for 'C:\eclipse\workspace\Introduction Example\target\clover\database\clover_coverage.db'. The file clover_coverage.db is created at folder target\clover\database -- When I am using AspectJ plugin with no preGoal for java:compile the Clover report is generated properly. -- The MPCLOVER-27 issue reports this same problem, but did not provide data to reproduce it. Thank you. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHANGELOG-54) invalid characters in CVS changelog cause build failure
[ https://jira.codehaus.org/browse/MPCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-54. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. invalid characters in CVS changelog cause build failure --- Key: MPCHANGELOG-54 URL: https://jira.codehaus.org/browse/MPCHANGELOG-54 Project: Maven 1.x Changelog Plugin Issue Type: Bug Affects Versions: 1.7.1 Reporter: Julian Dunn Per my message to maven-users: --- Some of our developers periodically check in code and write CVS commit messages containing invalid characters. For example, people will put in Ctrl-V+C accidentally, which causes our continuous build to fail with: BUILD FAILED File.. /home/jdunn/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly Element... x:parse Line.. 120 Column 48 Error on line 12 of document file:/home/jdunn/devel/util/target/changelog.xml :An invalid XML character (Unicode: 0x16) was found in the CDATA section. Nestedexception: An invalid XML character (Unicode: 0x16) was found in the CDATA section. Total time: 19 seconds Finished at: Fri Jan 28 16:55:21 EST 2005 --- -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMULTIPROJECT-11) multiproject:artifact builds do not use local project artifacts for dependencies
[
https://jira.codehaus.org/browse/MPMULTIPROJECT-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMULTIPROJECT-11.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
multiproject:artifact builds do not use local project artifacts for
dependencies
Key: MPMULTIPROJECT-11
URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-11
Project: Maven 1.x Multi-Project Plugin
Issue Type: Bug
Environment: WinXP
Reporter: John Fallows
Suppose I have a multiproject with 3 subprojects, called api, ri and
tck, each with a current version of 1.0-b1-SNAPSHOT.
The dependencies are setup as follows:
ri-1.0-b1-SNAPSHOT - api-1.0-b1-SNAPSHOT
tck-1.0-b1-SNAPSHOT - api-1.0-b1-SNAPSHOT
When I use multiproject plugin to build, the dependencies are not picked up
as expected.
maven multiproject:artifact
Starting the reactor...
Our processing order:
api
ri
tck
+
| Executing multiproject:artifact-callback api
| Memory: 4M/6M
+
...
[echo] Running jar:jar for api
...
+
| Executing multiproject:artifact-callback Oracle EL RI
| Memory: 7M/9M
+
BUILD FAILED
File.. [maven.repo.local]/plugins/maven-multiproject-plugin-1.0/
Element... maven:reactor
Line.. 191
Column 9
The build cannot continue because of the following unsatisfied dependency:
api-1.0-b1-SNAPSHOT.jar
This is happening because the api artifact is not present in the local maven
repository and cannot therefore be resolved by the ri project.
It would be much more convenient if this multiproject:artifact goal worked
without needing to install artifacts into the local repository.
The reactor has already figured out the build order based on the dependency
chain, so it is already quite clear which project dependencies are satisfied
by other projects being built during the same multiproject:artifact execution.
These specific dependencies could be overridden by multiproject during a
subproject build, and instead point to the local target area of the
corresponding peer project.
So, for example, the ri subproject ${pom} processed by
multiproject:artifact-callback could be modified to point to
${basedir}/../api/target/api-1.0-SNAPSHOT.jar for the api dependency,
instead of pointing at the local maven repository.
This would have 3 distinct advantages.
1. multiproject:artifact builds would succeed when the local maven repository
does not contain the peer subproject dependencies.
2. multiproject:artifact builds would succeed when the local maven repository
contains stale peer subproject dependencies previously downloaded from the
remote maven repository.
3. multiproject:artifact builds would succeed even for peer subproject
SNAPSHOT dependencies which would otherwise be overwritten in the local maven
repository when the stale api SNAPSHOT jar is re-downloaded from the remote
maven repository, during the build of the ri subproject.
Note. This strategy would also allow multiproject:install to work for
1.0-b1-SNAPSHOT version, without forcing an offline build. Requiring the
build to be offline in this case is inconvenient because other dependencies
cannot be downloaded on demand to the local maven repository.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJCOVERAGE-19) Incosequent file/class structure in reports
[ https://jira.codehaus.org/browse/MPJCOVERAGE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-19. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Incosequent file/class structure in reports --- Key: MPJCOVERAGE-19 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-19 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Affects Versions: 1.0.8 Reporter: Daniel Frey The JCoverage plugin produces results for inner/anonymous classes. I.e. I have got a class called ClassOne, which has an anonymouls inner class. The two classes are displayed in the coverage report as ClassOnewith 44% and ClassOne$1 with 0% tested, which is correct. However, the underlining reference to the html-file is in both cases the same. This is not consequent. The summary pages contain separate references to inner and outer classes. If this should really be so, there should be two html-files to display the two scopes correctly. I personly think that it would be more convenient to have one file (as it is) and consequently there should only be one link in the summary (to the file, not the class(es)). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPECLIPSE-76) AspectJ nature and source not set when generating eclipse project
[ https://jira.codehaus.org/browse/MPECLIPSE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPECLIPSE-76. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. AspectJ nature and source not set when generating eclipse project - Key: MPECLIPSE-76 URL: https://jira.codehaus.org/browse/MPECLIPSE-76 Project: Maven 1.x Eclipse Plugin Issue Type: Bug Reporter: Bert van Brakel Attachments: eclipse-plugin-patch.txt When generating eclipse .classpath and .project files when aspects are part of the maven build, the aspect nature and source directory aren't included. I have a patch which seems to work on my box, I'll see if I can attach it -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLATEX-1) Docs should include maven.latex.docs
[ https://jira.codehaus.org/browse/MPLATEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPLATEX-1. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Docs should include maven.latex.docs Key: MPLATEX-1 URL: https://jira.codehaus.org/browse/MPLATEX-1 Project: Maven 1.x Latex Plugin Issue Type: Bug Environment: All platforms Reporter: Nelson Arape Priority: Minor Original Estimate: 1 day Remaining Estimate: 1 day The property maven.latex.docs is necesary for this plugin, but it is missing form the documentation. The decription should say something like this: files list used for the generation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHECKSTYLE-11) Checkstyle plugin can throw an OutOfMemory exception
[
https://jira.codehaus.org/browse/MPCHECKSTYLE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPCHECKSTYLE-11.
--
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Checkstyle plugin can throw an OutOfMemory exception
Key: MPCHECKSTYLE-11
URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-11
Project: Maven 1.x Checkstyle Plugin
Issue Type: Bug
Reporter: Tim O'Brien
Priority: Minor
Trying to run checkstyle against code that does compile can cause an
OutOfMemory exception. For projects that happen to have code that doesn't
compile, the causes site:generate to fail.
Sure, this is an exceptional condition. Projects shouldn't be running around
with code that doesn't compile, but what are issue tracking systems for if
not for people to find exceptional conditions and enter them in. In other
words, this may not be a bug, but from my perspective anything that causes a
Maven user to see an OutOfMemoryException is interesting enough to put into
Jira.
The offending code was this:
if (!(pObject instanceof java.lang.String)) {
throw new EncoderException(Parameter supplied to
+ Soundex
+ encode is not of type
java.lang.String);
}
You'll note that there is a instead of the final + operator.
I opened a bug on checkstyle's SourceForge site, and oburns replied that
checkstyle expects compilable code for input. Should the pluing verify that
the code can compile by calling javac or something?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPEAR-46) Unknown artifact type[java-source]
[ https://jira.codehaus.org/browse/MPEAR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPEAR-46. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Unknown artifact type[java-source] --- Key: MPEAR-46 URL: https://jira.codehaus.org/browse/MPEAR-46 Project: Maven 1.x Ear Plugin Issue Type: Bug Environment: Windows Eclipse 3.1 Reporter: Tom Bollwitt Priority: Trivial Fix For: 1.9.1 When a POM (parent or dependency) includes java source jar dependencies they are not ignored and an error is thrown. dependency groupIdmygroup/groupId artifactIdartifact2/artifactId version1.0/version typejava-source/type /dependency When running 'package' or ear:ear I am getting the following error: [INFO] [ear:generate-application-xml] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to initialize ear modules Embedded error: Unknown artifact type[java-source] [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to initialize ear modules at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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.MojoExecutionException: Failed to initialize ear modules at org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:151) at org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:110) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown artifact type[java-source] at org.apache.maven.plugin.ear.ArtifactTypeMappingService.getStandardType(ArtifactTypeMappingService.java:153) at org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:60) at org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:144) ... 19 more [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed Aug 30 11:49:59 CDT 2006 [INFO] Final Memory: 4M/7M I added scopetest/scope to the java-source dependency and was able to work around this issue. The scope is missleading and therefore the desired behavior would be to not require scoping the java-source dependency. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHANGELOG-88) CVS with non standard port
[ https://jira.codehaus.org/browse/MPCHANGELOG-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-88. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. CVS with non standard port -- Key: MPCHANGELOG-88 URL: https://jira.codehaus.org/browse/MPCHANGELOG-88 Project: Maven 1.x Changelog Plugin Issue Type: Bug Environment: Windows XP build machine with Linux CVS server Reporter: Nicky Sandhu This is my project.xml snippet for repository definition. Note that i had to use separator scm: instead of scm| even though the separator being used in | repository connectionscm:cvs|pserver|user@server:5454|/usr/local/cvsroot|eContracts/connection developerConnectionscm:cvs|pserver|user@server:5454|/usr/local/cvsroot|eContracts/developerConnection !-- connectionscm|cvs|pserver|user@server:5454|/usr/local/cvsroot|eContracts/connection developerConnectionscm|cvs|pserver|user@server:5454|/usr/local/cvsroot|eContracts/developerConnection -- url/url /repository I did create .cvspass using maven maven -Dpassword= changelog:create-cvspass which got be a line in the .cvspass file looking like this (replaced actual values) :pserver:user@server:5454:/usr/local/cvsroot A0^y4 Now running maven maven-changelog-plugin:report __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: maven-changelog-plugin:report: [echo] Generating the changelog report Error processing command org.netbeans.lib.cvsclient.connection.AuthenticationException: Authentication failed. Response from server was: error 0 :/u. at org.netbeans.lib.cvsclient.connection.PServerConnection.openConnection(PServerConnection.java:238) at org.netbeans.lib.cvsclient.connection.PServerConnection.open(PServerConnection.java:326) at org.apache.maven.cvslib.CvsConnection.connect(CvsConnection.java:124) at org.apache.maven.cvslib.CvsConnection.processCommand(CvsConnection.java:467) at org.apache.maven.cvslib.CvsChangeLogGenerator.getEntries(CvsChangeLogGenerator.java:136) at org.apache.maven.changelog.ChangeLog.generateSets(ChangeLog.java:460) at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:395) 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.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:92) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jira] (MPREPO-8) spaces in maven.repo.central.directory not escaped for remote ssh
[
https://jira.codehaus.org/browse/MPREPO-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPREPO-8.
---
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
spaces in maven.repo.central.directory not escaped for remote ssh
-
Key: MPREPO-8
URL: https://jira.codehaus.org/browse/MPREPO-8
Project: Maven 1.x Repository Plugin
Issue Type: Bug
Affects Versions: 1.2
Environment: unix
Reporter: David Smiley
Original Estimate: 15 minutes
Remaining Estimate: 15 minutes
in plugin.jelly, goal repository:copy-artifact should escape the ${directory}
before repository:exec gets it. Prefixing spaces with a back-slash would do
it.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPSCM-43) scm:prepare-release doesn't work correctly with xml entities in POM
[
https://jira.codehaus.org/browse/MPSCM-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPSCM-43.
---
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
scm:prepare-release doesn't work correctly with xml entities in POM
---
Key: MPSCM-43
URL: https://jira.codehaus.org/browse/MPSCM-43
Project: Maven 1.x SCM Plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Martijn Dashorst
We use some XML entities in our project.xml in order to make the maintenance
of the several multiprojects easier.
in our main project directory we have defined an entity file,
project-entities.xml containing several xml entities:
!ENTITY reports
reports
reportmaven-junit-report-plugin/report
reportmaven-javadoc-plugin/report
reportmaven-jxr-plugin/report
reportmaven-checkstyle-plugin/report
/reports
Each sub project extending the main project's POM defines a DOCTYPE entry
pointing to the project-entities.xml file. The reason for defining the
reports in a entity instead of in the main projects POM is that the reports
for the main project are multiproject reports, and the subproject reports are
all equal.
?xml version=1.0 encoding=UTF-8?
!DOCTYPE project [
!ENTITY % project-entities SYSTEM
file:../mainproject/project-entities.xml %project-entities;
]
project
extend${basedir}/../mainproject/project.xml/extend
idsubproject/id
reports;
/project
When I use scm:prepare-release, the reports; entity is in the new
project.xml expanded to the contents in the project-entities.xml file *and*
the entity it self still remains in the subproject's project.xml. Also, the
reference to the project-entities in the DOCTYPE definition is gone:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE project
project
extend${basedir}/../mainproject/project.xml/extend
idsubproject/id
reports
reportmaven-junit-report-plugin/report
reportmaven-javadoc-plugin/report
reportmaven-jxr-plugin/report
reportmaven-checkstyle-plugin/report
/reportsreports;
/project
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLATKA-2) Jmeter Conversion not bringing over parameter names or values
[ https://jira.codehaus.org/browse/MPLATKA-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPLATKA-2. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Jmeter Conversion not bringing over parameter names or values - Key: MPLATKA-2 URL: https://jira.codehaus.org/browse/MPLATKA-2 Project: Maven 1.x Latka Plugin Issue Type: Bug Environment: WinXP with maven plugin 1.4 Reporter: Lee Rodgers Priority: Critical When I run the conversion command: maven -Djmeterfile=examplefile.jmx lotka:jmeter-convert it will run successfully. But when I attept to run maven lotka after I moved the suite file to the correct spot it fails because it is not passing parameters into the page. when I looked at the suite file I can see that it created a parameter for each paramter but it did not include any of the parameter names or any of the values as below: param paramName /paramName paramValue /paramValue /param param paramName /paramName paramValue /paramValue /param param paramName /paramName paramValue /paramValue /param This is a problem that is keeping me from using this as my functional testing tool. Is there a fix for it out there already. Is anyone else having this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJUNITREPORT-5) running cactus before junit report causes exception
[ https://jira.codehaus.org/browse/MPJUNITREPORT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJUNITREPORT-5. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. running cactus before junit report causes exception --- Key: MPJUNITREPORT-5 URL: https://jira.codehaus.org/browse/MPJUNITREPORT-5 Project: Maven 1.x JUnit Report Plugin Issue Type: Bug Reporter: Brett Porter BUILD FAILED File.. file:/home/cruise/.maven/plugins/maven-multiproject-plugin-1.2/plugin.jelly Element... maven:reactor Line.. 92 Column 9 Unable to obtain goal [site] -- file:/home/cruise/.maven/plugins/maven-xdoc-plugin-1.6/plugin.jelly:125:55: j:include could not include jelly script: file:/home/cruise/.maven/plugins/maven-junit-report-plugin-1.5/plugin-resources/junit.jsl. Reason: org.apache.commons.jelly.JellyTagException: file:/home/cruise/.maven/plugins/maven-junit-report-plugin-1.5/plugin-resources/junit.jsl:12:16: jsl:stylesheet file:/home/cruise/.maven/plugins/maven-junit-report-plugin-1.5/plugin-resources/junit.jsl:196:56: junit:displayImage java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPTEST-53) Tests breaks when run under maven due to missing resources
[
https://jira.codehaus.org/browse/MPTEST-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPTEST-53.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Tests breaks when run under maven due to missing resources
--
Key: MPTEST-53
URL: https://jira.codehaus.org/browse/MPTEST-53
Project: Maven 1.x Test Plugin
Issue Type: Bug
Environment: # BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.4.2_02
file.encoding=Cp1252
java.ext.dirs=C:\j2sdk1.4.2_02\jre\lib\ext
java.class.path=c:\PROGRA~1\apache-maven\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=c:\PROGRA~1\apache-maven\lib\endorsed\xerces-2.4.0.jar;c:\PROGRA~1\apache-maven\lib\endorsed\xml-api
s-1.0.b2.jar;C:\j2sdk1.4.2_02\jre\lib\rt.jar;C:\j2sdk1.4.2_02\jre\lib\i18n.jar;C:\j2sdk1.4.2_02\jre\lib\sunrsasign.jar;C
:\j2sdk1.4.2_02\jre\lib\jsse.jar;C:\j2sdk1.4.2_02\jre\lib\jce.jar;C:\j2sdk1.4.2_02\jre\lib\charsets.jar;C:\j2sdk1.4.2_02
\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.1
maven-announcement-plugin-1.3
maven-ant-plugin-1.8.1
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4.1
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.2
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5.1
maven-checkstyle-plugin-2.5
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.6
maven-dashboard-plugin-1.6
maven-developer-activity-plugin-1.5.1
maven-dist-plugin-1.6.1
maven-docbook-plugin-1.2
maven-ear-plugin-1.6
maven-eclipse-plugin-1.9
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5.1
maven-findbugs-plugin-0.8.4
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.2
maven-html2xdoc-plugin-1.3.1
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5.1
maven-jalopy-plugin-1.3.1
maven-jar-plugin-1.6.1
maven-java-plugin-1.5
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.7
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.9
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3.1
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.2
maven-jnlp-plugin-1.4.1
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.2
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.4
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.2.1
maven-plugin-plugin-1.5.2
maven-pmd-plugin-1.6
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4.1
maven-repository-plugin-1.2
maven-scm-plugin-1.4.1
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.2
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6.1
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Exception reading build.properties: C:\Documents and
Settings\emattsson\build.properties (The system cannot find the fil
e specified)
Home Build properties: {}
Reporter: Erik Ramfelt
Attachments: debug.output
I got a project with unit tests that require a bunch of resources in the
classpath. When I run the tests through maven, then the test cant find the
resources at all.
The tests works when I run them with:
* maven-clover-plugin, the test are successful.
* maven test:ui - The tests works with the Swing test app when it is
started from maven.
It does not work when I run
* maven test
Ive verified that the goal test:test-resources copies the resource files to
the target path target/test-classes. So I cant understand why i cant get
the goal test to work when the other does.
(Ive also setup eclipse so it works, and tried the meven-ide to synchronize
the changes from the eclipse project properties to the maven project-xml
file. And it still doesnt work.)
Maven test output (maven test)
--
test:test:
[junit] Running
[jira] (MPCHANGELOG-14) changelog should make use of 'state' value from CVS to indicate the type of change
[ https://jira.codehaus.org/browse/MPCHANGELOG-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-14. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. changelog should make use of 'state' value from CVS to indicate the type of change -- Key: MPCHANGELOG-14 URL: https://jira.codehaus.org/browse/MPCHANGELOG-14 Project: Maven 1.x Changelog Plugin Issue Type: Bug Reporter: Norbert Pabis Priority: Minor Changelog should make use of 'state' value from CVS to indicate the type of change. For example when file is deleted it has state 'dead' so it should be marked with icon or color or any other way that this file is removed. The link to view the file should not be generated in that case. I don't know about other versioning systems but CVS has this 'state' feature. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ https://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPANNOUNCEMENT-21. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Plugin causes site to fail during processing of xdoc plugin's downloads.jelly - Key: MPANNOUNCEMENT-21 URL: https://jira.codehaus.org/browse/MPANNOUNCEMENT-21 Project: Maven 1.x Announcement Plugin Issue Type: Bug Affects Versions: 1.4.1 Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 Reporter: dion gillard Priority: Critical The xdoc plugin calls attainGoal name=announcement:generate-all/ during it's generation of reports from the POM. This causes announcement:check-version to run and fail, if a project has a currentVersion not listed in the versions stanza. This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPSTRUTS-1) taskdef class org.apache.maven.struts.Struts10WarValidator cannot be found
[ https://jira.codehaus.org/browse/MPSTRUTS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPSTRUTS-1. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. taskdef class org.apache.maven.struts.Struts10WarValidator cannot be found -- Key: MPSTRUTS-1 URL: https://jira.codehaus.org/browse/MPSTRUTS-1 Project: Maven 1.x Struts Plugin Issue Type: Bug Components: default Environment: Windows XP, Maven 1.0, Java 1.4.2., Eclipse 3.0 Reporter: Ricardo Gladwell I've set the struts goal as a post-goal for the war:war goal. However, build always fails with: BUILD FAILED File.. C:\Documents and Settings\rglad\.maven\cache\maven-struts-plugin-1.3\plugin.jelly Element... taskdef Line.. 32 Column 71 taskdef class org.apache.maven.struts.Struts10WarValidator cannot be found -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPRELEASE-17) copy-dependencies does not work for type ejb-client
[ https://jira.codehaus.org/browse/MPRELEASE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPRELEASE-17. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. copy-dependencies does not work for type ejb-client --- Key: MPRELEASE-17 URL: https://jira.codehaus.org/browse/MPRELEASE-17 Project: Maven 1.x Release Plugin Issue Type: Bug Affects Versions: 1.5 Environment: maven 1.1 beta 2 Reporter: Fredrik Vraalsen Attachments: mprelease-handle-ejb-client-type.patch copy-dependencies does not work for dependencies of type ejb-client. The attached patch contains a workaround for plugin.jelly, but there may be better ways of handling this. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMULTIPROJECT-34) inconsistency mess building time-stamed snapshots
[ https://jira.codehaus.org/browse/MPMULTIPROJECT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMULTIPROJECT-34. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. inconsistency mess building time-stamed snapshots - Key: MPMULTIPROJECT-34 URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-34 Project: Maven 1.x Multi-Project Plugin Issue Type: Bug Affects Versions: 1.2 Reporter: Jörg Schaible Priority: Critical Building time-stamped snapshots with multiproject:install-snapshot (same applies to multiproject:deploy-snapshot) results in unreliable versions if you use versioned snapshots. The install-snapshot goal will build artifacts without the version information using just -SNAPSHOT and renames them to a timed version, but any dependent artifact will use later on -version-SNAPSHOT in its dependencies, that were not even build and may be downloaded in an buggy version from an internal repo. Example (cut down to the interesting parts): == % === $ maven multiproject:install-snapshot __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 Starting the reactor... Our processing order: nanocontainer nanocontainer-servlet nanocontainer-nanoweb nanocontainer-sample-nanoweb + | Executing multiproject:install-snapshot-callback nanocontainer | Memory: 8M/11M + build:start: multiproject:install-snapshot-callback: [echo] Running jar:install-snapshot for nanocontainer jar:snapshot: [echo] Building snapshot JAR: nanocontainer-20040609.071430 ... jar:jar: [jar] Building jar: C:\Work\Apps\Codehaus\pico\java\nanocontainer\target\nanocontainer-20040609.071430.jar jar:install-snapshot: [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars + | Executing multiproject:install-snapshot-callback nanocontainer-servlet | Memory: 12M/14M + Attempting to download nanocontainer-1.0-beta-1-SNAPSHOT.jar. ... build:end: build:start: multiproject:install-snapshot-callback: [echo] Running jar:install-snapshot for nanocontainer-servlet jar:snapshot: [echo] Building snapshot JAR: nanocontainer-servlet-20040609.071505 ... jar:jar: [jar] Building jar: C:\Work\Apps\Codehaus\pico\java\servlet\target\nanocontainer-servlet-20040609.071505.jar jar:install-snapshot: [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars + | Executing multiproject:install-snapshot-callback nanocontainer-nanoweb | Memory: 14M/18M + Attempting to download nanocontainer-servlet-1.0-beta-1-SNAPSHOT.jar. . Attempting to download nanocontainer-1.0-beta-1-SNAPSHOT.jar. build:end: build:start: multiproject:install-snapshot-callback: [echo] Running jar:install-snapshot for nanocontainer-nanoweb jar:snapshot: [echo] Building snapshot JAR: nanocontainer-nanoweb-20040609.071603 ... jar:jar: [jar] Building jar: C:\Work\Apps\Codehaus\pico\java\nanoweb\target\nanocontainer-nanoweb-20040609.071603.jar jar:install-snapshot: [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars [copy] Copying 1 file to C:\Dokumente und Einstellungen\jos\.maven\repository\nanocontainer\jars + | Executing multiproject:install-snapshot-callback nanocontainer-sample-nanoweb | Memory: 12M/20M + Attempting to download nanocontainer-1.0-beta-1-SNAPSHOT.jar. Attempting to download nanocontainer-servlet-1.0-beta-1-SNAPSHOT.jar. Attempting to download nanocontainer-nanoweb-1.0-beta-1-SNAPSHOT.jar. . build:end: build:start: multiproject:install-snapshot-callback: [echo] Running war:install-snapshot for nanocontainer-sample-nanoweb ... war:webapp: [echo] Assembling webapp nanocontainer-sample-nanoweb [mkdir] Created dir: C:\Work\Apps\Codehaus\pico\java\sample-nanoweb\target\nanocontainer-sample-nanoweb\WEB-INF\tld [copy] Copying 1 file to C:\Work\Apps\Codehaus\pico\java\sample-nanoweb\target\nanocontainer-sample-nanoweb\WEB-INF war:war: [echo] Building
[jira] (MPJAR-25) improve mapping of manifest entries, share code with ejb
[ https://jira.codehaus.org/browse/MPJAR-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJAR-25. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. improve mapping of manifest entries, share code with ejb Key: MPJAR-25 URL: https://jira.codehaus.org/browse/MPJAR-25 Project: Maven 1.x Jar Plugin Issue Type: Bug Reporter: Brett Porter Priority: Minor currently, the Specification-* and Implementation-* fields are mapped to fields from the POM that might not properly represent what their contents should be (and Specification-Version has been removed as pom.currentVersion is not always a valid value for this field). See MPJAR-7 for more info. Additionally, the code is the same between JAR and EJB. This should be refactored out in some way, perhaps by having EJB use the JAR task to generate the JAR and manifest. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDEVACTIVITY-8) Case sensitive comparison is used on developer id when reporting on SVN activity
[ https://jira.codehaus.org/browse/MPDEVACTIVITY-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPDEVACTIVITY-8. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Case sensitive comparison is used on developer id when reporting on SVN activity Key: MPDEVACTIVITY-8 URL: https://jira.codehaus.org/browse/MPDEVACTIVITY-8 Project: Maven 1.x Developer Activity Plugin Issue Type: Bug Affects Versions: 1.6.1 Environment: Windows, SVN Reporter: Joe Littlejohn Priority: Minor When reporting on developer activity, the plugin appears to only include changes where the author id matches exactly (case sensitive match) with a developer id defined in the developers section of the project xml. Since Subversion author id is not case sensitive, users can commit with any case in the author id (e.g. _jsmith == JSmith == JSMITH_). The developer activity plugin should presumably pick up all these changes. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJUNITREPORT-1) junit/cactus error output should be displayed in the report
[ https://jira.codehaus.org/browse/MPJUNITREPORT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJUNITREPORT-1. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. junit/cactus error output should be displayed in the report --- Key: MPJUNITREPORT-1 URL: https://jira.codehaus.org/browse/MPJUNITREPORT-1 Project: Maven 1.x JUnit Report Plugin Issue Type: Bug Reporter: Daniel Rabe Priority: Minor -Original Message- From: Vincent Massol [mailto:vmas...@pivolis.com] Sent: Saturday, November 08, 2003 5:45 AM To: 'Maven Users List' Cc: dr...@opentext.com Subject: RE: Getting cactus error output into the report Ok, I've had a better look. I was right. The cactus.jsl is an exact copy of the junit-report's junit.jsl file which does not display stack trace. So I'd say you should open a bug report against the junit-report plugin and I'll make sure that I update Cactus's cactus.jsl file. Thanks -Vincent -Original Message- From: Vincent Massol [mailto:vmas...@pivolis.com] Sent: 08 November 2003 12:27 To: 'Maven Users List' Cc: dr...@opentext.com Subject: RE: Getting cactus error output into the report Oops. Actually this may not be true. I had forgotten there was a cactus.jsl file in the cactus plugin. I'll have a look and fix this. Thanks -Vincent -Original Message- From: Vincent Massol [mailto:vmas...@pivolis.com] Sent: 08 November 2003 11:56 To: 'Maven Users List' Cc: dr...@opentext.com Subject: RE: Getting cactus error output into the report Hi Daniel, It looks like it's a limitation of the Maven junit-report plugin. Could you post a JIRA improvement report for the junit-report plugin. Although I haven't tested it, I believe you'll also not see stack trace information for pure junit tests when using Maven. Thanks -Vincent -Original Message- From: Daniel Rabe [mailto:dr...@opentext.com] Sent: 04 November 2003 01:34 To: 'us...@maven.apache.org' Subject: Getting cactus error output into the report I'm using maven with the cactus plugin on Windows XP. If one of my cactus tests gets an error (it throws an exception), a stack trace is emitted into the .txt and .xml files in target/test-cactus-reports/tomcat5x. However, the report that's generated by the cactus plugin only shows the exception message. It would really be helpful to have the actual stack trace in the report. Is there any way I can configure maven and/or the cactus plugin to do this? Thanks, Daniel Rabe -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPHTMLXDOC-3) Nested pre tags not converted to source tags
[ https://jira.codehaus.org/browse/MPHTMLXDOC-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPHTMLXDOC-3. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Nested pre tags not converted to source tags Key: MPHTMLXDOC-3 URL: https://jira.codehaus.org/browse/MPHTMLXDOC-3 Project: Maven 1.x Html2XDoc Plugin Issue Type: Bug Environment: All Reporter: Chuck Daniels pre tags are only converted to source tags when they appear at the top level of the html document. Nested pre tags are not converted. For example, a pre block within a list item is not converted to a source block. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCASTOR-11) automated builds hang when castor warnings are on
[ https://jira.codehaus.org/browse/MPCASTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCASTOR-11. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. automated builds hang when castor warnings are on - Key: MPCASTOR-11 URL: https://jira.codehaus.org/browse/MPCASTOR-11 Project: Maven 1.x Castor Plugin Issue Type: Bug Environment: running from anthill pro 2.5 on solaris Reporter: jake pezaro Priority: Minor enabling castor warnings causes castor to prompt the user when overwriting generated source files. in situations where the source directory cannot be cleaned (eg when running the clover report plugin) this causes the automated build to hang. this can be worked aroud by turning the warnings off, however this causes castor overwrite files with name clashes. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-26) maven.jcoverage.instrumentation.excludes does not work
[
https://jira.codehaus.org/browse/MPJCOVERAGE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJCOVERAGE-26.
-
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
maven.jcoverage.instrumentation.excludes does not work
--
Key: MPJCOVERAGE-26
URL: https://jira.codehaus.org/browse/MPJCOVERAGE-26
Project: Maven 1.x JCoverage Plugin
Issue Type: Bug
Affects Versions: 1.0.9
Reporter: thierry lach
Setting the instrumentation excludes causes jcoverage to fail with classes
not found exceptions.
To correct, change the following in plugin.jelly from
ant:copy todir=${maven.jcoverage.instrumentation}
ant:fileset dir=${maven.build.dest}
ant:exclude name=**/*.class /
ant:exclude name=${maven.jcoverage.instrumentation.excludes} /
/ant:fileset
/ant:copy
to
ant:copy todir=${maven.jcoverage.instrumentation}
ant:fileset dir=${maven.build.dest}
ant:exclude name=**/*.class /
ant:include name=${maven.jcoverage.instrumentation.excludes} /
/ant:fileset
/ant:copy
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIDEA-29) maven.idea.generated.source should take absolute paths
[
https://jira.codehaus.org/browse/MPIDEA-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIDEA-29.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
maven.idea.generated.source should take absolute paths
--
Key: MPIDEA-29
URL: https://jira.codehaus.org/browse/MPIDEA-29
Project: Maven 1.x IDEA Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: Geoffrey De Smet
Priority: Minor
Attachments: module.jelly.20050615
I tried doing:
maven.idea.generated.source=${maven.jaxb.build.dir}
But my maven.jaxb.build.dir is an absolute path and the idea plugin considers
maven.idea.generated.source to a list of relative to the build directory
paths.
I could do maven.idea.generated.source=jaxb but it seems more consistant to
the rest of maven to use absolute paths (except for includes which use a
relative path) if I am not mistaken.
Orginally my generated-java was even under my src folder (bad practice but
sometimes a necessary evil),
which made it harder to configure as the path is relative to the target
folder.
Patch attached
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMULTIPROJECT-53) Multiproject:site-deploy copying files twice
[ https://jira.codehaus.org/browse/MPMULTIPROJECT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMULTIPROJECT-53. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Multiproject:site-deploy copying files twice Key: MPMULTIPROJECT-53 URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-53 Project: Maven 1.x Multi-Project Plugin Issue Type: Bug Affects Versions: 1.4.1 Environment: Maven 1.1 beta1, Win 2K Reporter: Jeff Jensen After the Checkstyle run, seemingly as part of building reactor projects, it copies some files for each subproject, which is unexpected to me. While this can seem trivial, the file copy time is half the build time: [snip] [echo] Generating the Checkstyle... checkstyle:init: checkstyle:report: checkstyle:run: [echo] Using file:C:/devroot/healthmatch/Development/healthmatchmaven/../healthmatchbatch /src/conf/checkstyle/checkstyle.xml for checkstyle ... [echo] Now building reactor projects: [HealthMatch, HealthMatch Batch] [copy] Copying 11550 files to C:\devroot\healthmatch\builds\healthmatchmultiproject\docs\multiproject\heal thmatch [copy] Copying 225 files to C:\devroot\healthmatch\builds\healthmatchmultiproject\docs\multiproject\heal thmatchbatch multiproject:projects-init: multiproject:site-init: [snip] Then, when everything is all done, the site:fsdeploy does the copy, as expected (and deleting all the previously copied files first!): [snip] site:init: site:local-deploy-init: [echo] site clean = true siteDirectory = c:/devroot/healthmatch/sites/healthmatchmultiproject site:fsdeploy: [echo] Cleaning destination first [delete] Deleting directory C:\devroot\healthmatch\sites\healthmatchmultiproject [mkdir] Created dir: C:\devroot\healthmatch\sites\healthmatchmultiproject [copy] Copying 15835 files to C:\devroot\healthmatch\sites\healthmatchmultiproject BUILD SUCCESSFUL [snip] In this build process, the file copy time takes a very long time with almost 16,000 files! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPXDOC-101) large blocks of source code disappear in IE 6
[ https://jira.codehaus.org/browse/MPXDOC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPXDOC-101. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. large blocks of source code disappear in IE 6 - Key: MPXDOC-101 URL: https://jira.codehaus.org/browse/MPXDOC-101 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.7 Reporter: Brett Porter In both the new and classic theme, any large blocks of source code (eg Javadoc report for maven-xdoc-plugin) have sections of text missing in IE 6, and it appears/disappears depending on scrolling. This must be something in maven-base.css that is incompatible (or perhaps in site.jsl itself). This is likely an IE bug, but hopefully we can work around it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-28) Instrumentation fails on windows due to command line arg length.
[ https://jira.codehaus.org/browse/MPJCOVERAGE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-28. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Instrumentation fails on windows due to command line arg length. Key: MPJCOVERAGE-28 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-28 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Affects Versions: 1.0.9 Environment: Windows XP Professional Version 2002, SP 2, Java 1.4.1, Maven 1.02, Pentium IV 2.26 GHZ, 1 GB Ram Reporter: Achim Westermann When starting with a clean project jcoverage fails when compiling the test classes to it's maven.jcoverage.dir with tons of cannot resolve symbol errors. The underlying error has already happend before. Instrumentation failed: [instrument] [ERROR] java.io.IOException: CreateProcess: C:\j2sdk1.4.1\jre\bin\java.exe -classpath C:\Dokumente und Einstellungen\westermann\.maven\repository\jcoverage\jars\jcoverage-1.0.5.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\bcel\jars\bcel-5.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\urbanophile\jars\java-getopt-1.0.9.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\log4j\jars\log4j-1.2.8.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\oro\jars\oro-2.0.7.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\junit\jars\junit-3.8.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xercesImpl-2.6.2.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xmlParserAPIs-2.2.1.jar com.jcoverage.coverage.Instrument -d C:\build\jcoverage\classes -basedir C:\build\classes org\opencms\workplace\CmsWorkplace.class org\opencms\main\CmsRuntimeException.class org\opencms\file\TestSiblings$1.class com\opencms\workplace\CmsRepla? This leads to the fact that the classes required by the test sources which should be the instrumented ones are not in maven.jcoverage.dir thus missing from jcoverage classpath. Occurrance: Only on Windows, not on RH Linux 7.3. Assumption: On Windows the maximum command line length is exceeded. I have experienced similar behaviour in build-systems with makefile before. Look at the trainling '?' - The argument seems to have been truncated. The error hits back to the current process at the process creation for the instrumentation task. Suggestion: A) Perhaps use files for the arguments and a new -file argument to the com.jcoverage.coverage.Instrument class. Or lay open the underlying fork argument of the ANT javac task: Without forking this would not happen. The fallback could be possible memory problems. B) Fail the goal immediately when instrumentation fails. Errors that result are hard to find. Thanks for jcoverage, Achim -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPHIBERNATE-16) hibernate:schema-update does not delete tables
[ https://jira.codehaus.org/browse/MPHIBERNATE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPHIBERNATE-16. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. hibernate:schema-update does not delete tables -- Key: MPHIBERNATE-16 URL: https://jira.codehaus.org/browse/MPHIBERNATE-16 Project: Maven 1.x Hibernate Plugin Issue Type: Bug Affects Versions: 1.3 Environment: WinXP(SP2), JDK 5.0, Maven 1.0.2 Reporter: Jamie Bisotti The first time hibernate:schema-update is run, it works fine. However, if the *.hbm.xml files are modified so that one of the original tables no longer exists, a subsequent run of hibernate:schema-update does not remove that table. Seems like an update should make sure the DB's schema exactly matches what is specified by the *.hbm.xml files. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHANGELOG-38) changelog does not work with cvsnt
[ https://jira.codehaus.org/browse/MPCHANGELOG-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-38. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. changelog does not work with cvsnt -- Key: MPCHANGELOG-38 URL: https://jira.codehaus.org/browse/MPCHANGELOG-38 Project: Maven 1.x Changelog Plugin Issue Type: Bug Affects Versions: 1.5 Environment: CVSNT 2.0.26 Reporter: Archimedes Trajano Attachments: output C:\Projects\pensionsmaven maven-changelog-plugin:report __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc3-SNAPSHOT build:start: maven-changelog-plugin:report: [echo] Generating the changelog report Server is not supporting gzip-file-contents request ChangeLog found: 0 entries BUILD SUCCESSFUL Total time: 5 seconds Finished at: Tue May 04 19:27:12 CEST 2004 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBOSS-7) jboss:deploy-exploded-warfile no worky
[
https://jira.codehaus.org/browse/MPJBOSS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJBOSS-7.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
jboss:deploy-exploded-warfile no worky
--
Key: MPJBOSS-7
URL: https://jira.codehaus.org/browse/MPJBOSS-7
Project: Maven 1.x JBoss Plugin
Issue Type: Bug
Environment: Any
Reporter: Jim Crossley
Priority: Minor
Fix For: 1.6
Original Estimate: 1 day
Remaining Estimate: 1 day
It is often convenient to deploy an exploded warfile to jboss so that jsp
changes don't require a redeploy.
JBoss requires that the exploded directory name have a J2EE suffix, e.g.
.war, .ear, etc. Because the exploded directory and the war file are both
created in the target directory, they cannot have the same name.
I propose that the exploded warfile go in target/exploded/${id}.war/ so that
both it and target/${id}.war (the actual war) can peacefully coexist. That
way, both jboss:deploy-warfile and jboss:deploy-exploded-warfile will work
correctly out of the box.
I'll try to submit a patch soon (s/b trivial).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJUNITDOCLET-2) JUnitdoclet plugin does not support java 1.4 sources (assert Statement)
[ https://jira.codehaus.org/browse/MPJUNITDOCLET-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJUNITDOCLET-2. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. JUnitdoclet plugin does not support java 1.4 sources (assert Statement) --- Key: MPJUNITDOCLET-2 URL: https://jira.codehaus.org/browse/MPJUNITDOCLET-2 Project: Maven 1.x JUnitDoclet Plugin Issue Type: Bug Environment: Java Sources 1.4 (assert); Maven 1.0 Reporter: Joachim Bader Attachments: maven.junitdoclet-source.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes JUnitdoclet complains if the assert Statement (Java 1.4) is used. There is no property in the JUnitdoclet plugin to control the javadoc source property. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJAR-43) incorrect artifact relative path for inherited subproject pom
[
https://jira.codehaus.org/browse/MPJAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJAR-43.
---
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
incorrect artifact relative path for inherited subproject pom
-
Key: MPJAR-43
URL: https://jira.codehaus.org/browse/MPJAR-43
Project: Maven 1.x Jar Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: gax
Original Estimate: 1 day
Remaining Estimate: 1 day
call to artifact:install-snapshot in
goal name=jar:install-snapshot
uses an relative path that the artifact plugin doest resolve correctly when
inheritance or subprojects are involved and the current directory changes:
see line 448
http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java?view=annotate
I have resolved my problem by changeing the jar:install-snapshot goal with
---snip line 250 of plugin.jelly---
!-- == --
!-- I N S T A L L S N A P S H O T --
!-- == --
goal
name=jar:install-snapshot prereqs=jar:jar
description=Install a snapshot jar in the local repository
maven:makeAbsolutePath path=${maven.build.dir}/${maven.final.name}.jar
basedir=${basedir}
var=realArtifactPath/
ant:echojar path=${realArtifactPath}/ant:echo
ant:echobasedir=${basedir}/ant:echo
!--artifact:install-snapshot
artifact=${maven.build.dir}/${maven.final.name}.jar
type=jar
project=${pom}
/--
artifact:install-snapshot
artifact=${realArtifactPath}
type=jar
project=${pom}
/
/goal
---end snip line 250 of plugin.jelly---
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPXDOC-196) Tables with a width of 100% are incorrectly displayed in IE 5
[ https://jira.codehaus.org/browse/MPXDOC-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPXDOC-196. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Tables with a width of 100% are incorrectly displayed in IE 5 - Key: MPXDOC-196 URL: https://jira.codehaus.org/browse/MPXDOC-196 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.9.2 Environment: Win2K Pro + IE5 Reporter: Arnaud Heritier Priority: Minor Attachments: screenshot-1.jpg Using the maven-stylus style, the width of the table is 100% of the screen and not 100% of the available space. Thus the content of the page is moved after the menu. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPXDOC-111) br/ is transformed into br/br
[ https://jira.codehaus.org/browse/MPXDOC-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPXDOC-111. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. br/ is transformed into br/br --- Key: MPXDOC-111 URL: https://jira.codehaus.org/browse/MPXDOC-111 Project: Maven 1.x XDoc Plugin Issue Type: Bug Reporter: Carlos Sanchez This causes two line breaks (at least in IE 6) For example (at http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7view=auto) section name=Installing p To install or update the plugin do the following:br/ codemaven plugin:download -DgroupId=maven -DartifactId=maven-aspectj-plugin -Dversion=lt;versiongt;/code /p /section is transformed into (at http://maven.apache.org/reference/plugins/aspectj/) div class=section a name=Installing/ah2Installing/h2 p To install or update the plugin do the following:br/br codemaven plugin:download -DgroupId=maven -DartifactId=maven-aspectj-plugin -Dversion=lt;versiongt;/code /p /div -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPPLUGIN-30) Plugins on a per-user basis
[
https://jira.codehaus.org/browse/MPPLUGIN-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPPLUGIN-30.
--
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Plugins on a per-user basis
---
Key: MPPLUGIN-30
URL: https://jira.codehaus.org/browse/MPPLUGIN-30
Project: Maven 1.x Plugin Plugin
Issue Type: Bug
Affects Versions: 1.5
Environment: Linux (Debian), Maven 1.1
Reporter: Rodrigo S. de Castro
Attachments: maven-plugin-plugin-installation.patch
Problem:
When I try to compile Geronimo, it fails when trying to install its plugin
into the $MAVEN_HOME directory, since it is a shared installation in
/usr/local/maven-1.1. It does not install the plugins on a per-user basis to
my maven local directory (~/.maven). Is this the intended behaviour?
Analysis:
In the org.apache.maven.plugin.PluginManager class, which is called for
plugin:install-now, the plugin is installed in the user plugins dir, as we
may check through the following code:
if ( cache )
{
FileUtils.copyFileToDirectory( file, userPluginsDir );
cacheManager.registerPlugin( pluginName, housing );
housing.parse( cacheManager );
cacheManager.saveCache( unpackedPluginsDir );
}
Since I am not sure if the behaviour was intentional, I would like to know
your opinion about that.
From the point of view that there is an inconsistent behaviour, I will attach
a patch that changes plugin:install to do the same as plugin:install-now:
install in the user directory. With this patch, current repository version of
Apache Geronimo works properly.
Concerning plugin removal, the code already check both directories (global
and user), as you may check here (plugin/plugin.jelly):
define:tag name=uninstall
ant:delete verbose=false failonerror=false
ant:fileset dir=${maven.plugin.dir}
ant:include name=${name}-*.jar /
/ant:fileset
ant:fileset dir=${maven.plugin.user.dir}
ant:include name=${name}-*.jar /
/ant:fileset
/ant:delete
Thank you!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMULTIPROJECT-15) multiproject : order of processing of javadoc and compile when xdoclet is needed
[ https://jira.codehaus.org/browse/MPMULTIPROJECT-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMULTIPROJECT-15. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. multiproject : order of processing of javadoc and compile when xdoclet is needed Key: MPMULTIPROJECT-15 URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-15 Project: Maven 1.x Multi-Project Plugin Issue Type: Bug Environment: Linux 2.4.21 Reporter: Andy Jefferson When running the multiproject plugin, it runs a clean on all sub-projects and then runs the javadoc report. The problem comes up when your project needs to run xdoclet to generate interface classes. Since you are doing the javadoc step before any compile, these xdoclet-generated classes dont show up in the javadoc, and you get a pile of unresolved messages out of the javadoc command. Solution is to do reorder multiproject to do a compile first (and since most people just add xdoclet as a preGoal to compile, xdoclet will be run) - or maybe you define compile as a preGoal to javadoc ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJNLP-27) Unable to specify expressions for maven.jnlp.description
[
https://jira.codehaus.org/browse/MPJNLP-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJNLP-27.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Unable to specify expressions for maven.jnlp.description
Key: MPJNLP-27
URL: https://jira.codehaus.org/browse/MPJNLP-27
Project: Maven 1.x JNLP Plugin
Issue Type: Bug
Affects Versions: 1.4.1
Environment: Windows XP
Reporter: Bjorn Martensson
I tried to assign a variable like this:
maven.jnlp.description=${projectDescription}
When I did maven jnlp I got the following error:
BUILD FAILED
File.. C:\Documents and
Settings\Bjorn\.maven\cache\maven-jnlp-plugin-1.4.1\plugin.jelly
Element... maven:property
Line.. 60
Column 90
org.apache.commons.jelly.expression.ConstantExpression
Total time: 9 seconds
Finished at: Sat Jul 23 12:58:49 BST 2005
I modified the plugin in my local repository and came up with the following
solution:
1. Uncomment the default value for maven.jnlp.description in the
plugin.properties file. (Why was it commented out?)
2. Delete line 60 from the plugin.jelly file (line 60: maven:property
name=maven.jnlp.description defaultValue=${pom.description}/ )
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIDEA-49) idea:module fails on project:type of ejb
[ https://jira.codehaus.org/browse/MPIDEA-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIDEA-49. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. idea:module fails on project:type of ejb Key: MPIDEA-49 URL: https://jira.codehaus.org/browse/MPIDEA-49 Project: Maven 1.x IDEA Plugin Issue Type: Bug Affects Versions: 1.6 Environment: Maven 1.0.2 maven-multiproject-plugin-1.5.jar maven-idea-plugin-1.6.jar Reporter: Jimmy Wan My general project structure is something like this: Toplevel project with no artifacts. Tier 2 children of toplevel project are subprojects that inherit from the toplevel project and are of 2 types (jar or ejb). Tier 3 children of tier 2 projects are subprojects of tier 2 projects and are all of type jar. The idea:multiproject task fails and generates a truncated module file as seen below. v1.5 of the IDEA plugin does not have this problem, but fails in other ways that also makes it unsuitable for me. Output: [CUT-REMOVED ARTIFACT DOWNLOAD OUTPUT] [echo] DEPRECATED: the use of dependency-handle is deprecated. Please use maven:get/set to modify properties of the multiproject plugin build:start: idea:init: war:load: [echo] DEPRECATED: war:load is deprecated, please use maven:get tags idea:module: [echo] Creating c:\repo\Products\Wolverine\WorkflowServices/WolverineWorkflowServices.iml ... BUILD FAILED File.. C:\Documents and Settings\jwan.21TECHNOLOGIES\.maven\cache\maven-idea-plugin-1.6\plugin.jelly Element... j:import Line.. 78 Column 79 file:/C:/Documents and Settings/jwan.21TECHNOLOGIES/.maven/cache/maven-idea-plugin-1.6/plugin-resources/templates/v4/module.jelly:41:106: maven:makeRelativePath You must define an attribute called 'path' for this tag. Total time: 3 seconds Finished at: Fri Oct 06 11:42:00 CDT 2006 Generated Module file: ?xml version=1.0 encoding=UTF-8? module version=4 relativePaths=true type=J2EE_EJB_MODULE component name=EjbModuleBuildComponent setting name=EXPLODED_URL value=file:// /setting setting name=EXPLODED_ENABLED value=false /setting setting name=JAR_URL value=file://$MODULE_DIR$/target/IRRELEVANT INFO.jar /setting setting name=JAR_ENABLED value=true /setting /component component name=EjbModuleProperties -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMULTIPROJECT-71) CLONE -goal multiproject:create-nav seems to have lost pom.id
[
https://jira.codehaus.org/browse/MPMULTIPROJECT-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMULTIPROJECT-71.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
CLONE -goal multiproject:create-nav seems to have lost pom.id
-
Key: MPMULTIPROJECT-71
URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-71
Project: Maven 1.x Multi-Project Plugin
Issue Type: Bug
Affects Versions: 1.4.1
Environment: maven 1.0.2 but with a couple of plugins upgraded to
latest HEAD.
Reporter: Rupert Smith
Attachments: test.zip
Today I have upgraded the checkstyle plugin to 3.0 from 2.6
This seems to have downloaded a couple of libraries and I now have a strange
behaviour for multiproject.
I have also upgraded PMD to 1.8-SNAPSHOT but the following issue appeared
before:
When I run maven multiproject:site, the reactor goes through all
sub-projects ok BUT when it reaches the call to attainGoal
name=multiproject:create-nav/, it seems to lose the pom.id and declares
that I must exclude the (the top level project (see line 140 in th
eplugin.jelly).
, which is the pom.id, is replaced by the LAST project contained in the
variable ${multiprojects}.
the pom.id seems to have changed between the line just BEFORE the call to
multiproject:create-nav and the FIRST line inside create-nav.
If I modify the code to add some log:
echoPOM.id before calling create-nav ${pom.id}/echo
attainGoal name=multiproject:create-nav/
...
goal name=multiproject:create-nav
prereqs=multiproject:site-init
echoPOM.id INSIDE create-nav ${pom.id} and multi ${multiprojects}/echo
j:forEach var=reactorProject items=${multiprojects}
echoPOM.id INSIDE LOOP create-nav ${pom.id} and current
${reactorProject.id}/echo
j:if test=${reactorProject.id == pom.id}
fail message=You must exclude ${pom.id} (the top level project)
from the subproject set/
/j:if
/j:forEach
The pom.id has changed between the first 2 echos. it then matches the last
reactorProject.id and th ewhole process fails.
I do not understand why the pom.id is changed somewhere in
multiproject:site-init...
My current workaround is to change the fail to a simple echo so that the
process can finish (but it does not generate a proper navigation.xml)
There is obviously something wrong introduced by the latest download of a
couple of plugin, I still have maven 1.0.2
Is there a way I could list all plugins and version? I would post it here...
Thanks for looking into it.
Benoit
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJNLP-29) Native library support?
[ https://jira.codehaus.org/browse/MPJNLP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJNLP-29. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Native library support? --- Key: MPJNLP-29 URL: https://jira.codehaus.org/browse/MPJNLP-29 Project: Maven 1.x JNLP Plugin Issue Type: Bug Environment: Ubuntu Linux, x86_64, ibm 150 jre. Reporter: Andy Brook I havent seen any examples of how native libraries are supported. My scenario is an SWT application that uses the SWT jar from eclipse, v3.1.1 now has the .so / .dll at the root of a JAR with java classes underneath. If it doesnt support this yet will it? At the moment, the plugin does the lions share of signing, I just have to modify the template and hard code an additional nativelib tag. It would be ideal If in addition to $dependencies in the velocity template, there was a $nativeDependencies. This would then allow the SWT jar above to be referenced. I see there is some code relating to native library processing that is currently commented out. What I would like to avoid is having to extract native libraries such that the plugin can resign them again, using SWT as the example, the jar has already been signed, I just need to refer to it as a native lib. One way is to extend the dependencies tag to have a natives section and in addition to specifying absolute libraries (.so / .dll ) for .jar wrapping/signing, the ideal would be to use the same descriptor as the includes giving: dependencies includes includecommons-logging:commons-logging/include includecommons-cli:commons-cli/include includeorg.eclipse.core:boot/include includeorg.eclipse.core:runtime/include includeorg.eclipse:swt/include includeorg.eclipse.swt:win32-x86/include includeorg.eclipse:jface/include includeorg.eclipse.jface:text/include includelog4j:log4j/include includemyco:myapp/include /includes !-- excludes exclude/exclude excludes-- nativeIncludes includeorg.eclipse.swt:win32-x86/include !-- this contains java classses and the native libraries -- /nativeIncludes /dependencies -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-36) Coverage report showing more than 100% coverage for few packages/classes
[ https://jira.codehaus.org/browse/MPJCOVERAGE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-36. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Coverage report showing more than 100% coverage for few packages/classes Key: MPJCOVERAGE-36 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-36 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Affects Versions: 1.0.5 Reporter: Yogesh The Coverage report is showing more than 100% coverage for few packages. Some of the files are indicating coverage of over 140%. I am not able to debug the issue so far. I have report generated for two projects and I merge their jcoverage.ser files with the one generted on server after Junit execution. The report statistics appeared correct some time back and look very doubtful to me now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLATEX-2) not useable with win32, cygwin
[
https://jira.codehaus.org/browse/MPLATEX-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPLATEX-2.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
not useable with win32, cygwin
--
Key: MPLATEX-2
URL: https://jira.codehaus.org/browse/MPLATEX-2
Project: Maven 1.x Latex Plugin
Issue Type: Bug
Environment: win32, cygwin
Reporter: Thomas Diesler
The de.prima.shire.anttex.LaTeX task passes filenames to the pdflatex command
unchanged. pdflatex interprets them as control sequences.
I tried various alternative path formats in the ant call - no success. The
problem seems to lie within de.prima.shire.anttex.LaTeX. Who owns that
source? I could not find it.
cheers
-tomsk
---
latex:generate:
[echo] scanning: D:\projects\drools/src/latex/
[echo] Generating from
D:\projects\drools\target\latex\manual\drools-guide.tex
Delete is not set: Use default-values!
[latex] Running LaTeX now!
[latex] latexfile =
D:\projects\drools\target\latex\manual\drools-guide.tex
[latex] bibtexfile =
D:\projects\drools\target\latex\manual\drools-guide.tex
[latex] latexdir = D:\projects\drools\target\latex\manual
[latex] verbose= true
[latex] bibtex = true
[latex] bibtex = true
[latex] clean = false
[latex] delete = org.apache.tools.ant.taskdefs.Delete@5ccedd
[latex] running command: pdflatex pdflatex
\nonstopmode\input{D:\projects\drools\target\latex\manual\drools-guide.tex}
[latex] This is pdfTeX, Version 3.14159-1.00b-pretest-20020211 (Web2c
7.3.7x)
[latex] {c:/Programme/TeXLive/texmf-var/pdftex/config/pdftex.cfg}
[latex] LaTeX2e 2001/06/01
[latex] Loading CZ hyphenation patterns: Pavel Sevecek, v3, 1995
[latex] Loading SK hyphenation patterns: Jana Chlebikova, 1992
[latex] Babel v3.7h and hyphenation patterns for english, dumylang,
nohyphenation, cz
[latex] ech, slovak, german, ngerman, spanish, catalan, french,
ukenglish, italian, dut
[latex] ch, polish, portuguese, loaded.
[latex]
[latex] ! Undefined control sequence.
[latex] argument D:\projects
[latex]\drools \target \latex \manual \drools
-guide.tex
[latex] * ...rools\target\latex\manual\drools-guide.tex}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJCOVERAGE-29) Does not respect setting of maven.jcoverage.merge.outputDir
[
https://jira.codehaus.org/browse/MPJCOVERAGE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJCOVERAGE-29.
-
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Does not respect setting of maven.jcoverage.merge.outputDir
---
Key: MPJCOVERAGE-29
URL: https://jira.codehaus.org/browse/MPJCOVERAGE-29
Project: Maven 1.x JCoverage Plugin
Issue Type: Bug
Reporter: Jeff Jensen
Setting maven.jcoverage.merge.outputDir has no effect - the tool always
writes jcoverage.ser to ${basedir}.
In the meantime, this is a work-around:
Add this to the maven.xml file, and it will delete the file with the clean
goal:
preGoal name=clean:clean
ant:delete file=${basedir}/jcoverage.ser /
/preGoal
This is a problem as a built file is written to a source dir, and must be
deleted on each build.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJBOSS-24) 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files
[ https://jira.codehaus.org/browse/MPJBOSS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJBOSS-24. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files Key: MPJBOSS-24 URL: https://jira.codehaus.org/browse/MPJBOSS-24 Project: Maven 1.x JBoss Plugin Issue Type: Bug Reporter: Manisha Sur 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files . so before running 'maven jboss:start' , they should be corrected. while maven 1.0.2 generated correct bat files. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-32) Coverage report has bad formatting
[
https://jira.codehaus.org/browse/MPJCOVERAGE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJCOVERAGE-32.
-
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Coverage report has bad formatting
--
Key: MPJCOVERAGE-32
URL: https://jira.codehaus.org/browse/MPJCOVERAGE-32
Project: Maven 1.x JCoverage Plugin
Issue Type: Bug
Affects Versions: 1.0.9
Environment: Maven 1.0.2
Reporter: thierry lach
This code
protected AbstractDataPump() {
this(null, null);
}
appears in the jcoverage report as
protected AbstractDataPump() {
this(null, class=keywordnull);
}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPCHECKSTYLE-25) Checkstyle does not perform on all source directories when generating source files
[ https://jira.codehaus.org/browse/MPCHECKSTYLE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHECKSTYLE-25. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Checkstyle does not perform on all source directories when generating source files -- Key: MPCHECKSTYLE-25 URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-25 Project: Maven 1.x Checkstyle Plugin Issue Type: Bug Reporter: Guillaume Nodet Attachments: plugin.jelly The plugin should use the maven.compile.src.set instead of pom.build.sourceDirectory -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHANGELOG-20) CDATA text in commit messages causes failure of changelog plugin
[ https://jira.codehaus.org/browse/MPCHANGELOG-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-20. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. CDATA text in commit messages causes failure of changelog plugin Key: MPCHANGELOG-20 URL: https://jira.codehaus.org/browse/MPCHANGELOG-20 Project: Maven 1.x Changelog Plugin Issue Type: Bug Environment: N/A Reporter: dion gillard Original Estimate: 1 day Remaining Estimate: 1 day See the msg in the following changelog excerpt changelog-entry date2002-09-18/date time17:45:35/time author![CDATA[Marcus Brito]] -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJNLP-22) signing jars removes manifest properties such as main-class
[
https://jira.codehaus.org/browse/MPJNLP-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJNLP-22.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
signing jars removes manifest properties such as main-class
---
Key: MPJNLP-22
URL: https://jira.codehaus.org/browse/MPJNLP-22
Project: Maven 1.x JNLP Plugin
Issue Type: Bug
Affects Versions: 1.4.1
Reporter: Geoffrey De Smet
Priority: Minor
signing jars removes manifest properties such as main-class, class-path, ...
spec versions etc probably too.
Also the maven.jnlp.mainclass is not defaulted correctly as documented
maven.jnlp.mainclass=${maven.jar.mainclass}
Extra issue for docs:
maven.jnlp.signjar.store
maven.jnlp.signjar.storepass
are not optional for the jnlp:generate-keystore
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJCOVERAGE-15) FileNotFoundException after project clean goal run.
[ https://jira.codehaus.org/browse/MPJCOVERAGE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-15. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. FileNotFoundException after project clean goal run. --- Key: MPJCOVERAGE-15 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-15 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Environment: Maven 1.0, Java 1.4.2_05, Windows XP Reporter: Ricardo Gladwell Attachments: CoverageReport.java, maven-jcoverage-plugin-1.0.9-PATCHED-MPJCOVERAGE-15.jar, stacktrace.txt I get a FileNotFoundException running the jcoverage goal after a clean goal has been run. See attached stacktrace. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPGENAPP-25) Memory leak
[
https://jira.codehaus.org/browse/MPGENAPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPGENAPP-25.
--
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
Memory leak
---
Key: MPGENAPP-25
URL: https://jira.codehaus.org/browse/MPGENAPP-25
Project: Maven 1.x Application Generation Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: maven 1.1 beta 3
Reporter: Arnaud Heritier
When the bootstrap is launched we test all the plugins.
Before to test the genapp plugin we have :
{code}
[exec] +
[exec] | Test Genapp Plugin - Templates Test
[exec] | Memory: 84M/89M
[exec] +
{code}
After we have :
{code}
[exec] +
[exec] | Test Maven Gump Plugin
[exec] | Memory: 119M/197M
[exec] +
{code}
We lost 30M of memory
I don't know if this is a problem in the plugin or in the test itself.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPSCM-85) scm:update now no longer uses cached authorisation
[ https://jira.codehaus.org/browse/MPSCM-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPSCM-85. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. scm:update now no longer uses cached authorisation -- Key: MPSCM-85 URL: https://jira.codehaus.org/browse/MPSCM-85 Project: Maven 1.x SCM Plugin Issue Type: Bug Affects Versions: 1.6 Environment: winxp, maven 1.1-beta-3, cvsnt as the cvs client Reporter: dion gillard In maven 1.1-beta-2, we could use an scm url like this: scm:cvs:pserver:dion@cvsserver:/cvs:InterfacesWeb and scm:update would happily run. With v1.6, we now need to specify a password in the url, e.g. scm:cvs:pserver:dion:password@cvsserver:/cvs:InterfacesWeb This regression is insecure and forces us to either provide the password in the url, or set up anonymous read access to the repository (which we do not want to do for security reasons). It also means that the changelog plugin can not be used, as it expects the cvs url to have 6 tokens: BUILD FAILED File.. file:/C:/Documents and Settings/db2admin/.maven/cache/maven-changelog-plugin-1.9.1/plugin.jelly Element... changelog:changelog Line.. 134 Column 15 cvs repository connection string doesn't contain six tokens Total time : 55 seconds Finished at : Friday, 11 August 2006 11:30:22 AM -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPPDF-60) Menu names never appear in the document
[ https://jira.codehaus.org/browse/MPPDF-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPPDF-60. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Menu names never appear in the document --- Key: MPPDF-60 URL: https://jira.codehaus.org/browse/MPPDF-60 Project: Maven 1.x PDF Plugin Issue Type: Bug Affects Versions: 2.5.1 Reporter: Wendy Smoak Attachments: MPPDF-60-20070603-1851.patch The generated PDF does not contain the integer numbered section names, which come from menu name=... in navigation.xml. The PDF only contains the sub sections, such as 1.1, 1.2, 2.1, 3.1, which come from item name=... .href=... / in navigation.xml. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMULTIPROJECT-70) Multiproject plugin not using dependencies when maven.jar.override = on
[ https://jira.codehaus.org/browse/MPMULTIPROJECT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMULTIPROJECT-70. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Multiproject plugin not using dependencies when maven.jar.override = on --- Key: MPMULTIPROJECT-70 URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-70 Project: Maven 1.x Multi-Project Plugin Issue Type: Bug Environment: Windows 2000 Professional. Maven 1.1. Beta 3. Reporter: Matthew Purland Attachments: jira.zip When using the multiproject plugin with a project with multiple projects, dependencies defined in projectbase.xml, and all projects that have a project.xml file extend from projectbase.xml. If maven.jar.override = on is specified and the correct overridden jar artifactId is present then when running the test goal for a project from within multiproject, dependencies are given to unit tests that are run. Please see attached zip file for more detailed information. When using attached file, please place the contents of local_repo into your local repository for a successful test run/workaround to provide proof of working vs. nonworking. The only workaround I've found is to take the jars that are depended upon and place them into the local repository and depend on them as regular dependencies and take out maven.jar.override. However, this doesn't necessarily solve the problem that if you have a vendor jar that you can't place in ibiblio or a remote repository without setting up a maven repository server such as proximity or continuum. I will try to provide a test in the future. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLATKA-1) latka:jmeter-convert loses information from the jmeter config
[ https://jira.codehaus.org/browse/MPLATKA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPLATKA-1. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. latka:jmeter-convert loses information from the jmeter config - Key: MPLATKA-1 URL: https://jira.codehaus.org/browse/MPLATKA-1 Project: Maven 1.x Latka Plugin Issue Type: Bug Environment: Windows XP Reporter: Daniel Rabe Install JMeter 1.9.1. Use JMeter to open and run their example in ./docs/demos/SimpleTestPlan.jmx. Note that it sets up HTTP defaults to http://jakarta.apache.org. Note that the test suite runs successfully. Now use latka:jmeter-convert to convert this to a latka script. Result: The generated latka script doesn't contain any of the HTTP information, so it is effectively useless. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPTEST-45) maven test plugin 1.6.2 test throws a ClassNotFound exception in a subtier level project
[
https://jira.codehaus.org/browse/MPTEST-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPTEST-45.
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
maven test plugin 1.6.2 test throws a ClassNotFound exception in a subtier
level project
Key: MPTEST-45
URL: https://jira.codehaus.org/browse/MPTEST-45
Project: Maven 1.x Test Plugin
Issue Type: Bug
Environment: Solaris 9, maven 1.0, sun jdk 1.4.2_03
Reporter: Daniel Flesner
Attachments: maven.log
when running a sub level project the test:compile somehow gets confused and
doesn't include the unitTestincludes. hence, the test fails with a class
not found on the Test class itself. the exact same project.xml file works
fine in rc2. the debug output from 1.0:
---
test:compile:
[available] [DEBUG] class X was not found
[available] [VERBOSE] Unable to load class X to set property classPresent
[javac] [DEBUG] fileset: Setup scanner in dir
/home/dflesner/ct/dev/ims/components/authn/components/authn-cmd/test/java
with patternSet{ includes: [**/*Command.java] excludes: [**/package.html] }
---the same output from rc2---
test:compile:
[javac] [DEBUG] fileset: Setup scanner in dir
/home/dflesner/ct/dev/ims/components/authn/components/authn-cmd/test/java
with patternSet{ includes: [] excludes: [**/package.html] }
[javac] [VERBOSE] com/rsa/authn/LoginCommandTest.java added as
com/rsa/authn/LoginCommandTest.class doesn't exist.
[javac] [VERBOSE] com/rsa/authn/LogoutCommandTest.java added as
com/rsa/authn/LogoutCommandTest.class doesn't exist.
[javac] Compiling 2 source files to
/home/dflesner/ct/dev/ims/components/authn/components/authn-cmd/target/test-classes
---
notice the includes is different. the includes is actually the src
modifications not the test includes?
my project.xml excerpt
---
build
sourceDirectory../../src/java/sourceDirectory
resources
resource
directorysrc/java//directory
includes
include**/*.properties/include
/includes
/resource
/resources
sourceModifications
sourceModification
classNameX/className
includes
include**/*Command.java/include
/includes
/sourceModification
/sourceModifications
unitTestSourceDirectorytest/java/unitTestSourceDirectory
unitTest
includes
include**/*Test.java/include
/includes
/unitTest
/build
---the actual error in the test log
Null Test: Caused an ERROR
com.rsa.authn.LoginCommandTest
java.lang.ClassNotFoundException: com.rsa.authn.LoginCommandTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPJAVADOC-79) plugin generates wrong javadoc JAR name
[ https://jira.codehaus.org/browse/MPJAVADOC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJAVADOC-79. --- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. plugin generates wrong javadoc JAR name --- Key: MPJAVADOC-79 URL: https://jira.codehaus.org/browse/MPJAVADOC-79 Project: Maven 1.x Javadoc Plugin Issue Type: Bug Affects Versions: 1.8 Reporter: O. Bigalk Priority: Minor Attachments: plugin.jelly.diff maven javadoc:jar generates a JAR file named foo-x.y_javadoc.jar but the maven-eclipse-plugin tries to link to foo-x.y.javadoc.jar It is very easy to fix this in maven-javadoc-plugin/plugin.jelly The diff is atached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPECLIPSE-100) No ability to configure the JRE specified in generated .classpath file
[ https://jira.codehaus.org/browse/MPECLIPSE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPECLIPSE-100. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. No ability to configure the JRE specified in generated .classpath file -- Key: MPECLIPSE-100 URL: https://jira.codehaus.org/browse/MPECLIPSE-100 Project: Maven 1.x Eclipse Plugin Issue Type: Bug Affects Versions: 1.9 Reporter: Ken Weiner Attachments: eclipse-plugin-patch.txt The generated .classpath file always sets the JRE to the default JRE in Eclipse as follows: classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ There needs to be a way to override this so one can specify an alternate like so: classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/sun-jdk-1.4.2.08/ In this case, the eclipse project would use the jdk that the user named sun-jdk-1.4.2.08. An easy way to fix this is to remove the hard-coded setting in plugin.jelly and, instead, make org.eclipse.jdt.launching.JRE_CONTAINER the default value of the maven.eclipse.conclasspath property. Then in plugin.jelly, the classpathentry kind=con path=.../ would always be generated with a path equal to org.eclipse.jdt.launching.JRE_CONTAINER unless the property was overriden. Carlos Sanchez helped me produce the patch. An alternate fix would be to make a new property called something like maven.eclipse.jre which would have a value like sun-jdk-1.4.2.08 in which case plugin.jelly would generate: classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/sun-jdk-1.4.2.08/ instead of classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ Attached are patches. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPUBERJAR-8) uberjar broken
[ https://jira.codehaus.org/browse/MPUBERJAR-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPUBERJAR-8. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. uberjar broken -- Key: MPUBERJAR-8 URL: https://jira.codehaus.org/browse/MPUBERJAR-8 Project: Maven 1.x UberJar Plugin Issue Type: Bug Environment: m1.1-beta-2, maven-uberjar-plugin-1.3-SNAPSHOT Reporter: Lukas Theussl Priority: Blocker The upgrade of cassworlds seems to have broken the uberjar plugin: java -jar test-uber.jar Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/boot/Bootstrapper I have fixed a few things in plugin.jelly but couldn't get it to work. Probably related to CLASSWORLDS-19. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJNLP-23) maven.jnlp.jardiff and maven.jnlp.usejarversions aren't mutually exclusive
[ https://jira.codehaus.org/browse/MPJNLP-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJNLP-23. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. maven.jnlp.jardiff and maven.jnlp.usejarversions aren't mutually exclusive -- Key: MPJNLP-23 URL: https://jira.codehaus.org/browse/MPJNLP-23 Project: Maven 1.x JNLP Plugin Issue Type: Bug Affects Versions: 1.4.1 Reporter: Xanthros Fix For: 1.5 If maven.jnlp.usejarversions=true and maven.jnlp.jardiff=true then the version.xml file is created and the jar files are renamed using the filename based convention instead of the version based. This is incorrect. If both are true then the version.xml file should be used and not the filename based convention. By using the filename based convention the version based has no chance of working since it can't match the value in the file tag that is put in the version.xml. When the jars are being signed, it renames the jars using the filename based convention, thereby making the version.xml useless. Also the version.xml is newly created everytime and therefore doesn't have the previous resources. jnlp descriptor snippet: resources jar version=1.14 href=test-core.jar /jar jar version=1.05 href=test-service.jar /jar /resources version.xml snippet: jnlp-versions resource pattern nametest-core.jar/name version-id1.13/version-id /pattern fileblah.jar/file /resource resource pattern nametest-core.jar/name version-id1.14/version-id /pattern fileblah245.jar/file /resource resource pattern nametest-service.jar/name version-id1.04/version-id /pattern filesample.jar/file /resource resource pattern nametest-service.jar/name version-id1.05/version-id /pattern filesample1.jar/file /resource jnlp-versions The value of the href has to match the name in the version.xml file. Currently this is also incorrect. The plugin produces a version.xml file like this: jnlp-versions resource pattern nametest-core-1.14.jar/name version-id1.14/version-id /pattern filetest-core-1.14.jar/file /resource resource pattern nametest-service-1.05.jar/name version-id1.05/version-id /pattern filetest-service-1.05.jar/file /resource jnlp-versions The file tag has to exactly match a file on the file system. It can be named anything as long as it exists. This is probably two-three issues that are all linked. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHANGELOG-90) Changelog hangs when asked about new certificate
[ https://jira.codehaus.org/browse/MPCHANGELOG-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGELOG-90. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Changelog hangs when asked about new certificate Key: MPCHANGELOG-90 URL: https://jira.codehaus.org/browse/MPCHANGELOG-90 Project: Maven 1.x Changelog Plugin Issue Type: Bug Affects Versions: 1.8.2 Environment: Windows XP SP2 Reporter: Niall Pemberton The certificate for the apache subversion repository changed a week ago - the changelog plugin just hangs. Once I ran svn on the command line and accepted the certificate it started working fine again. Presumably the command needs to recognise when it gets this kind of response. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPHIBERNATE-15) Oracle sequence is not set correctly
[ https://jira.codehaus.org/browse/MPHIBERNATE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPHIBERNATE-15. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Oracle sequence is not set correctly Key: MPHIBERNATE-15 URL: https://jira.codehaus.org/browse/MPHIBERNATE-15 Project: Maven 1.x Hibernate Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Daniel Beland When executing the goal schema-export, with OracleDialect, the sequences are created but they are not assigned to the tables. Something similar to this should be generated: CREATE OR REPLACE TRIGGER TRG_ALIAS BEFORE INSERT ON ALIAS FOR EACH ROW BEGIN IF :new.COID IS NULL THEN SELECT SEQ_ALIAS.nextval INTO :new.COID FROM dual; END IF; END; / SHOW ERRORS; -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPHIBERNATE-17) Support query tag in aggregate-mappings
[ https://jira.codehaus.org/browse/MPHIBERNATE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPHIBERNATE-17. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Support query tag in aggregate-mappings --- Key: MPHIBERNATE-17 URL: https://jira.codehaus.org/browse/MPHIBERNATE-17 Project: Maven 1.x Hibernate Plugin Issue Type: Bug Affects Versions: 1.3 Environment: maven 1.0.2 Reporter: Brian Cochran Attachments: MappingsAggregatorBean.java, project.xml May want to support more features of the hibernate-mapping. specifically conform to !ELEMENT hibernate-mapping (meta*, import*, (class|subclass|joined-subclass)*, query*, sql-query*) As of now only class is supported. I added pseudo support for the others. A hack, but it should work. see MappingsAggregatorBean.java around line 84 attatched file should fix. Note i attatched the project.xml file as well because I was required to make modifications to the cglib version, and add an asm version so that schema-export would work correctly. Tell me if I am missing someting. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPTEST-24) Stacktrace filtering
[ https://jira.codehaus.org/browse/MPTEST-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPTEST-24. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Stacktrace filtering Key: MPTEST-24 URL: https://jira.codehaus.org/browse/MPTEST-24 Project: Maven 1.x Test Plugin Issue Type: Bug Environment: maven rc2 (january 21, 2004 cvs) Reporter: fabrizio giustina junit ant task automatically filter from stacktrace lines related to ant classes. In details: junit.framework.TestCase junit.framework.TestResult junit.framework.TestSuite junit.framework.Assert. junit.swingui.TestRunner junit.awtui.TestRunner junit.textui.TestRunner java.lang.reflect.Method.invoke( org.apache.tools.ant. This is controlled by the filtertrace task attribute, on by default. However, executing test using maven, all the lines in the stacktrace generated by maven are not filtered and added to any exception. The maven test goal should supply a different formatter which can strips from the stacktrace all the lines generated by maven and not by the test being runned, to make it more readable. Actually the following __78__ lines are appended by maven to any stacktrace generated during a failure: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at
[jira] (MPPLUGIN-36) rewritten project.xml isn't incorporated into jar
[
https://jira.codehaus.org/browse/MPPLUGIN-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPPLUGIN-36.
--
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
rewritten project.xml isn't incorporated into jar
-
Key: MPPLUGIN-36
URL: https://jira.codehaus.org/browse/MPPLUGIN-36
Project: Maven 1.x Plugin Plugin
Issue Type: Bug
Affects Versions: 1.7
Reporter: Kohsuke Kawaguchi
The plugin:plugin goal is written as follows:
goal name=plugin:plugin description=Build a plugin jar
!-- For some reason a prereq on this causes an internal error... --
attainGoal name=jar:jar /
!-- We can't use it in the bootstrap phase because classes aren't yet
build in the artifact plugin --
j:if test=${bootstrapping == null}
assert:assertPluginAvailable groupId=maven
artifactId=maven-artifact-plugin minRelease=1.7
neededBy=${plugin.artifactId}/
artifact:rewritePOM path=${maven.build.dir}/project.xml/
ant:jar
jarfile=${maven.build.dir}/${maven.jar.final.name}
basedir=${maven.build.dir}
update=true
ant:setProperty name=includes value=project.xml /
/ant:jar
ant:delete file=${maven.build.dir}/project.xml quiet=true/
/j:if
/goal
The idea here is first to build an ordinary jar, and then update its
project.xml by using the rewritten version.
This didn't work as expected in my system, because the jar generation and POM
rewriting happens too quickly,
they get the same (or at least very similar) timestamp --- note that zip file
only maintains timestamp in
2 sec precision.
So when this runs the jar task to update project.xml, Ant actually skips
the processing, saying project.xml
is up to date.
One simple but stupid way to fix this is to insert a delay before rewriting
POM, like:
ant:sleep seconds=3 /
Or alternatively I guess one can unjar, use copy to overwrite, then update.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPCASTOR-12) Missing serialversionUID in serializable classes
[ https://jira.codehaus.org/browse/MPCASTOR-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCASTOR-12. -- Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Missing serialversionUID in serializable classes Key: MPCASTOR-12 URL: https://jira.codehaus.org/browse/MPCASTOR-12 Project: Maven 1.x Castor Plugin Issue Type: Bug Reporter: Michele La Porta In order to ensure that serialized classes work between jars, classes which are serializable should always explicitly list a serialVersionUID; if the serialized implementation of the object changes, the number can then be re-generated; but will not change on a per-compile basis and maintains serialized object compatibility. See http://jira.codehaus.org/browse/CASTOR-719 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-35) MAVEN_OPTS is not being set correctly
[ https://jira.codehaus.org/browse/MPJCOVERAGE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-35. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. MAVEN_OPTS is not being set correctly - Key: MPJCOVERAGE-35 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-35 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Environment: windows xp Reporter: Tigran Antonyan Priority: Blocker I set the MAVEN_OPTS to -Xmx1024m (tried from command line and %MAVEN_HOME%/bin/maven) and it still fail the build when JVM memory use gets up to 220m with either outOfMemory or java heap size exception here is a part of the output: Root cause java.lang.OutOfMemoryError: PermGen space Thanks Tigran -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPSOURCE-1) Attemps to download at the old location even if the source artifact is found
[ https://jira.codehaus.org/browse/MPSOURCE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPSOURCE-1. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Attemps to download at the old location even if the source artifact is found Key: MPSOURCE-1 URL: https://jira.codehaus.org/browse/MPSOURCE-1 Project: Maven 1.x Source Plugin Issue Type: Bug Affects Versions: 1.0 Reporter: Stéphane Nicoll Fix For: 1.1 When the backwardCompatibleFlag mode is set, the plugin always attemps to download the java source archive from the old location, even if it's found at the standard location. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBUILDER-16) JBuilder will not start up when plugin is installed and maven project is open
[ https://jira.codehaus.org/browse/MPJBUILDER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJBUILDER-16. Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. JBuilder will not start up when plugin is installed and maven project is open - Key: MPJBUILDER-16 URL: https://jira.codehaus.org/browse/MPJBUILDER-16 Project: Maven 1.x JBuilder Plugin Issue Type: Bug Environment: Window XP JBuilder X Enterprise. Maven 1.0 Reporter: Marteijn Nouwens If an Project is open that contains an project.xml JBuilder will not start. The Root coause of this is. Caused by: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory If JBuilder is started. It also not possible to open a project that contaisn a project.xml I tried to create a fix for this but was unable to get latest source code. I would be willing to help on this since Jbuilder is out main development ide. Marteijn Nouwens -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-23) rendering bug
[ https://jira.codehaus.org/browse/MPJCOVERAGE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-23. - Resolution: Won't Fix Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. rendering bug - Key: MPJCOVERAGE-23 URL: https://jira.codehaus.org/browse/MPJCOVERAGE-23 Project: Maven 1.x JCoverage Plugin Issue Type: Bug Reporter: Brett Porter I found a bug at org.apache.maven.jcoveragereport.JavaToHtml: The string public void hello(final String foo, final String bar) turns into public void hello(final String foo, keyword String bar) the span class=\keyword\ replaces the 'class' again and generates span span class=keyword=keywordfinal I fixed that the following way (UPPERCASE): private static HashMap reservedWords = new HashMap(); private static boolean inMultiLineComment = false; private static String commentStart = span CLASS=\comment\; private static String commentEnd = /span; private static String stringStart = span CLASS=\string\; private static String stringEnd = /span; private static String reservedWordStart = span CLASS=\keyword\; private static String reservedWordEnd = /span; Other minor bug... semicolon is missing at #34 // replace \ sequences with HTML escape sequences; line = replace(line, + (char) 92 + (char) 34, #92;#34); Regards Allan Jones https://genesis.dev.java.net/ Summa Technologies do Brasil Ltda. --- -- This message was sent by Atlassian JIRA (v6.1.6#6162)
