[jira] (MCHANGES-333) announcement-generate for JIRA doesn't query for relevant issues
[ https://jira.codehaus.org/browse/MCHANGES-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Barnett updated MCHANGES-333: - Attachment: MCHANGES-333.patch Attached [^MCHANGES-333.patch] which forces {{announcement-generate}} JQL query to be similar to {{jira-report}} query - proof of concept fix, real one would source values from {{@Parameter}} properties. > announcement-generate for JIRA doesn't query for relevant issues > > > Key: MCHANGES-333 > URL: https://jira.codehaus.org/browse/MCHANGES-333 > Project: Maven Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.9 >Reporter: Richard Barnett > Attachments: MCHANGES-333.patch > > > {{announcement-generate}} for JIRA submits a JQL query eg > {code} > Address: https://palomamobile.atlassian.net/rest/api/2/search > ... > Payload: {"jql":"project = PCSV AND status in (5, 6) AND resolution in (1, > 8)","maxResults":25,"fields":["*all"]} > {code} > and then selects issues from the response which were fixed in the current > version. If no issues are selected the goal fails, eg: > {code} > Couldn't find the release '1.0.76' among the supplied releases: > [Release[version='1.0.73.1', date='null', description='null', actionsSize=2], > Release[version='1.0.73', date='null', description='null', actionsSize=3], > Release[version='1.0.72', date='null', description='null', actionsSize=2], > Release[version='1.0.75', date='null', description='null', actionsSize=5], > Release[version='1.0.74', date='null', description='null', actionsSize=4], > Release[version='1.0.74.1', date='null', description='null', actionsSize=1], > Release[version='1.0.71.2', date='null', description='null', actionsSize=1], > Release[version='1.0.71.1', date='null', description='null', actionsSize=1]] > {code} > By contrast, {{jira-report}} uses a JQL query with a constraint on > {{fixVersion}}; eg when {{onlyCurrentVersion=true}} for the same pom as above > the query is: > {code} > Address: https://palomamobile.atlassian.net/rest/api/2/search > ... > Payload: {"jql":"project = PCSV AND fixVersion = \"1.0.77\" AND status in (5, > 6) AND resolution in (1, 8) ORDER BY priority DESC, created > DESC","maxResults":100,"fields":["*all"]} > {code} > It seems like {{announcement-generate}} should use the same JQL query that > {{jira-report}} does in this case. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-616) surefire-report doesn't create target/site/css
[ https://jira.codehaus.org/browse/SUREFIRE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345000#comment-345000 ] Marcel Stör commented on SUREFIRE-616: -- It doesn't look like the project team considers that many people want an HTML report without creating a Maven site. It's been 4 years since this was first reported :( So, as so often...Ant to the rescue: http://stackoverflow.com/a/2847475/131929 > surefire-report doesn't create target/site/css > -- > > Key: SUREFIRE-616 > URL: https://jira.codehaus.org/browse/SUREFIRE-616 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin > Environment: Maven 2.2.1, Java 1.6.0_17, OS/X 10.6.3 >Reporter: Marco Brandizi > > I've just try " mvn surefire-report:report-only" and I get what said in the > subject. It creates site surefire-report.html, but not the css/*.css files > that are imported by such html. The result is quite ugly to see. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345006#comment-345006 ] AF KL Customer commented on MRELEASE-812: - We have exactly the same problem with maven-release-plugin 2.5 (but only with projects which don't have a pom at the root of git repository) . For projects with a pom at the root , it works fine ! > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345007#comment-345007 ] Martin Ellis commented on MRELEASE-812: --- Looks like we're seeing MRELEASE-875. I've added my vote there. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-264) Allow other packaging types
[ https://jira.codehaus.org/browse/MPLUGIN-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MPLUGIN-264: -- Assignee: Igor Fedorenko > Allow other packaging types > --- > > Key: MPLUGIN-264 > URL: https://jira.codehaus.org/browse/MPLUGIN-264 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.3 > > > Currently, maven-plugin-plugin silently ignores projects that packaging > different from "maven-plugin". Although this is a reasonable default, it is > sometimes useful to generate plugin descriptor for "jar" projects or projects > that use domain-specific packaging types. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-264) Allow other packaging types
[ https://jira.codehaus.org/browse/MPLUGIN-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MPLUGIN-264: --- Fix Version/s: 3.3 > Allow other packaging types > --- > > Key: MPLUGIN-264 > URL: https://jira.codehaus.org/browse/MPLUGIN-264 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.3 > > > Currently, maven-plugin-plugin silently ignores projects that packaging > different from "maven-plugin". Although this is a reasonable default, it is > sometimes useful to generate plugin descriptor for "jar" projects or projects > that use domain-specific packaging types. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-264) Allow other packaging types
Igor Fedorenko created MPLUGIN-264: -- Summary: Allow other packaging types Key: MPLUGIN-264 URL: https://jira.codehaus.org/browse/MPLUGIN-264 Project: Maven Plugin Tools Issue Type: Improvement Components: Plugin Plugin Reporter: Igor Fedorenko Currently, maven-plugin-plugin silently ignores projects that packaging different from "maven-plugin". Although this is a reasonable default, it is sometimes useful to generate plugin descriptor for "jar" projects or projects that use domain-specific packaging types. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[ https://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345018#comment-345018 ] Vladimir Piyanov commented on MNG-4996: --- Why the issue is closed? I have run into the same problem in my build. I have tried maven 3.0.3, 3.2.1 and maven-compiler-plugin 3.1, 2.3.2. In all versions I have the same behaviour: when running parallel build, the classpath for the testCompile compiler run is sen incorrectly - all test artefacts are missing. > Maven3 parallel build fails occasionally for classpath problems. > > > Key: MNG-4996 > URL: https://jira.codehaus.org/browse/MNG-4996 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1 > Environment: maven 3.0.1, maven 3.0 >Reporter: Kari J. Niemi >Assignee: Kristian Rosenvold > > In a multimodule (>120 modules) maven build, the compiler plug-in would seem > to fail in creating a correct class-path every now and then. > Instead of this entry in maven -X logs for a single module build: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic > configurator --> > .. > [DEBUG] (f) classpathElements = > [/home/karniemi/"mymodulepath"/target/classes, > /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar, > > /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar, > > /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar, > > /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar, > > /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar, > /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar] > > every now and then I get this in the parallel build: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic > configurator --> > ... > [DEBUG] (f) classpathElements = > [/home/karniemi/"mymodulepath"/target/classes] > > And of course the compilation fails because none of the dependencies are > added to the classpath. Sometimes it goes fine in the multi-module build, but > every now and then it fails for this. > In both maven runs I can see that the dependencies are resolved fine: > -- > [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT > [DEBUG]junit:junit:jar:4.7:test > [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided > [DEBUG] > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided > [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided > [DEBUG] > org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided > (scope managed from compile) (version managed from 1.1.0) > [DEBUG] > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided > [DEBUG]log4j:log4j:jar:1.2.14:provided > --- > > The pluginArtifactMap looks like this: > > [DEBUG] (s) pluginArtifactMap = > {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:, > > org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile, > > org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile, > > org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile, > > org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile, > > org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile, > junit:junit=junit:junit:jar:3.8.1:compile, > org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile} > > I'm really using jbi-maven-plugin for most of the modules, and that plugin > binds the other plugins -also the compiler-plugin -to maven life-cycle phases. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[ https://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345024#comment-345024 ] Dimitri BAELI commented on MNG-4996: I agree the BUG is totally not closed, and easy to reproduce : * Build is here : https://buildhive.cloudbees.com/job/lesfurets/job/MNG4496 * Code is here : https://github.com/lesfurets/MNG4496 > Maven3 parallel build fails occasionally for classpath problems. > > > Key: MNG-4996 > URL: https://jira.codehaus.org/browse/MNG-4996 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1 > Environment: maven 3.0.1, maven 3.0 >Reporter: Kari J. Niemi >Assignee: Kristian Rosenvold > > In a multimodule (>120 modules) maven build, the compiler plug-in would seem > to fail in creating a correct class-path every now and then. > Instead of this entry in maven -X logs for a single module build: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic > configurator --> > .. > [DEBUG] (f) classpathElements = > [/home/karniemi/"mymodulepath"/target/classes, > /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar, > > /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar, > > /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar, > > /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar, > > /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar, > /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar] > > every now and then I get this in the parallel build: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic > configurator --> > ... > [DEBUG] (f) classpathElements = > [/home/karniemi/"mymodulepath"/target/classes] > > And of course the compilation fails because none of the dependencies are > added to the classpath. Sometimes it goes fine in the multi-module build, but > every now and then it fails for this. > In both maven runs I can see that the dependencies are resolved fine: > -- > [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT > [DEBUG]junit:junit:jar:4.7:test > [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided > [DEBUG] > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided > [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided > [DEBUG] > org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided > (scope managed from compile) (version managed from 1.1.0) > [DEBUG] > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided > [DEBUG]log4j:log4j:jar:1.2.14:provided > --- > > The pluginArtifactMap looks like this: > > [DEBUG] (s) pluginArtifactMap = > {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:, > > org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile, > > org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile, > > org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile, > > org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile, > > org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile, > junit:junit=junit:junit:jar:3.8.1:compile, > org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile} > > I'm really using jbi-maven-plugin for most of the modules, and that plugin > binds the other plugins -also the compiler-plugin -to maven life-cycle phases. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-183) Extra 'temp' directory created in wrong place
[ https://jira.codehaus.org/browse/MEAR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gabriel updated MEAR-183: --- Description: When DIR is used during maven phase PACKAGE 'temp' dir is created under this dir with fully compiled modules (ear, war) was: When DIR is used during maven phase 'temp' dir is created under this dir will fully compiled modules (ear, war) > Extra 'temp' directory created in wrong place > - > > Key: MEAR-183 > URL: https://jira.codehaus.org/browse/MEAR-183 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Peter Gabriel > Attachments: DIR.png > > > When > DIR > is used during maven phase PACKAGE 'temp' dir is created under this dir with > fully compiled modules (ear, war) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
Marcel Stör created SUREFIRE-1075: - Summary: Addresses to documented mailing lists in Maven site dead Key: SUREFIRE-1075 URL: https://jira.codehaus.org/browse/SUREFIRE-1075 Project: Maven Surefire Issue Type: Bug Components: documentation Reporter: Marcel Stör Priority: Critical I tried to subscribe to mailing lists documented here http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html What I got back was {noformat} - The following addresses had permanent fatal errors - (reason: 550 mail to surefire-users-subscr...@maven.apache.org not accepted here) - Transcript of session follows - ... while talking to mx1.us.apache.org.: >>> DATA <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here 550 5.1.1 ... User unknown <<< 503 RCPT first {noformat} The archives linked there seem to contain only messages up to year 2010 or so. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-183) Extra 'temp' directory created in wrong place
[ https://jira.codehaus.org/browse/MEAR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-183: - Affects Version/s: (was: 2.9) 2.8 > Extra 'temp' directory created in wrong place > - > > Key: MEAR-183 > URL: https://jira.codehaus.org/browse/MEAR-183 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Peter Gabriel > Attachments: DIR.png, pom.xml > > > When > DIR > is used during maven phase PACKAGE 'temp' dir is created under this dir with > fully compiled modules (ear, war) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-183) Extra 'temp' directory created in wrong place
[ https://jira.codehaus.org/browse/MEAR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gabriel updated MEAR-183: --- Attachment: pom.xml Here is the pom I use. > Extra 'temp' directory created in wrong place > - > > Key: MEAR-183 > URL: https://jira.codehaus.org/browse/MEAR-183 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Peter Gabriel > Attachments: DIR.png, pom.xml > > > When > DIR > is used during maven phase PACKAGE 'temp' dir is created under this dir with > fully compiled modules (ear, war) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345029#comment-345029 ] Aaron Digulla commented on MRESOURCES-171: -- I just stumbled over the same issue. Background: Property files need to use ISO-8859-1 as encoding as per [the docs|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html]: {quote} except the input/output stream is encoded in ISO 8859-1 character encoding {quote} Note: This is only true for the simple line-oriented properties file format, not the XML version! This becomes a problem when the default encoding {{project.build.sourceEncoding}} is set to something else because the resource plugin will try to load the files with this encoding (ignoring the Java standard) which garbles the input when it contains non-ASCII characters like "öäü". IDE usually get this right by ignoring the project's defaults for these files and enforcing ISO-8859-1 for {{*.properties}} files. I see two solutions: # Configure the resource plugin to ignore those files (which is bad since then, we can't replace variables in them anymore) # Offer a per-file-type encoding That way, one could say: {code} iso-8859-1 *.properties {code} I'd even opt for this to be the default. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://jira.codehaus.org/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-619) Configurations of different s influence each other
[ https://jira.codehaus.org/browse/MASSEMBLY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345046#comment-345046 ] Chris Seieroe commented on MASSEMBLY-619: - I have an assembly descriptor with many dependency sets and I see the same problem with useTransitiveDependencies. We have it on most of the dependency sets, but not all of them. One in particular is actually including transitive dependencies even though I set that value to false. It seems to work correctly with version 2.2-beta-5 but when I tried to upgrade to 2.2, I noticed the problem. It also happens with versions 2.3 and 2.4. > Configurations of different s influence each other > - > > Key: MASSEMBLY-619 > URL: https://jira.codehaus.org/browse/MASSEMBLY-619 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.2.2, 2.3 > Environment: Mqven 3.0.4, JDK 1.7 >Reporter: Olaf Otto >Priority: Minor > > When configuring two elements, the configurations in the > second influence the first one. > h2. Reproduction: > The following configuration utilizes to sets to copy different elements of > the dependency hierarchy of a module into two distinct subfolders: > {code:xml} > > software > false > > org.codehaus.groovy:* > > false > > > libs > false > > org.codehaus.groovy:groovy-all > > > {code} > However, the first unexpectedly contains most of the > transitive dependencies. The issue can only be resolved by adding > false to the second > , too. The issue remains reproducible when changing > etc. I suppose the isolation of the set configuration is > broken. I could reproduce the issue with both 2.3 and 2.2.2. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-619) Configurations of different s influence each other
[ https://jira.codehaus.org/browse/MASSEMBLY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Seieroe updated MASSEMBLY-619: Attachment: pom.xml assembly.xml Here is a small sample pom and assembly descriptor to test with. The directory "dir2" should be filled with the activemq-osgi artifact only since I'm excluding the other dependency, commons-configuration. If you use the maven-assembly-plugin version 2.2-beta-5 then dir2 only contains one jar file, like I expect. If you run with a newer version, it contains 104 jar files. > Configurations of different s influence each other > - > > Key: MASSEMBLY-619 > URL: https://jira.codehaus.org/browse/MASSEMBLY-619 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.2.2, 2.3 > Environment: Mqven 3.0.4, JDK 1.7 >Reporter: Olaf Otto >Priority: Minor > Attachments: assembly.xml, pom.xml > > > When configuring two elements, the configurations in the > second influence the first one. > h2. Reproduction: > The following configuration utilizes to sets to copy different elements of > the dependency hierarchy of a module into two distinct subfolders: > {code:xml} > > software > false > > org.codehaus.groovy:* > > false > > > libs > false > > org.codehaus.groovy:groovy-all > > > {code} > However, the first unexpectedly contains most of the > transitive dependencies. The issue can only be resolved by adding > false to the second > , too. The issue remains reproducible when changing > etc. I suppose the isolation of the set configuration is > broken. I could reproduce the issue with both 2.3 and 2.2.2. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-183) Extra 'temp' directory created in wrong place
[ https://jira.codehaus.org/browse/MEAR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345053#comment-345053 ] Stéphane Nicoll commented on MEAR-183: -- The {{changeManifestClasspath}} method that was introduced in MEAR-60 actually uses the wrong property to create its temp directory. > Extra 'temp' directory created in wrong place > - > > Key: MEAR-183 > URL: https://jira.codehaus.org/browse/MEAR-183 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Peter Gabriel > Attachments: DIR.png, pom.xml > > > When > DIR > is used during maven phase PACKAGE 'temp' dir is created under this dir with > fully compiled modules (ear, war) -- This message was sent by Atlassian JIRA (v6.1.6#6162)