[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)
