[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359150#comment-359150
]
Michael Osipov commented on MPIR-263:
-
I'd like to clarify this first with Robert. In my opinion you misunderstood the
statement in MJAVADOC-310. The upshot is that plugins should not know of each
other. We do not have a shared config space:
bq. In one of the Maven Hangouts we spent some time on this issue. Jason is
very clear about this: plugins should have no knowledge about each other. If
there are shared configuration-elements amongst plugins, then the pom.xml might
need to be enriched for such elements.
That is the reason why I do not want to obtain information from compiler plugin.
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold reassigned MSHARED-394:
--
Assignee: Kristian Rosenvold
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-168) Don't overwrite unchanged resource to prevent unnecessary subsequent processing
[ https://jira.codehaus.org/browse/MRESOURCES-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned MRESOURCES-168: - Assignee: Kristian Rosenvold Don't overwrite unchanged resource to prevent unnecessary subsequent processing --- Key: MRESOURCES-168 URL: https://jira.codehaus.org/browse/MRESOURCES-168 Project: Maven Resources Plugin Issue Type: Improvement Components: filtering Environment: MVN3.0.4 Win7 Pro SP1 64 Bit JDK 1.6.0_07 Reporter: Markus KARG Assignee: Kristian Rosenvold Priority: Minor When filtering resources, the resulting files' last-modified date is updated. This is correct, as the file just got produced. But, there might be lots of files that passed the filter unchanged -- but now have changed last-modified date, too. This induces unneccesary subsequent processing and should be prevented. Example: Filtering of Java sources, then compiling those. The Java compiler typically will only compile modified files, but not thinks ALL files are modified. A solution could be to check whether at least one property was actually found in the filtered file and to reset the last-modified date in all other cases. Another solution could be to rename the previous output file and compare both files after filtering. If they are identical, the new fill can be discarded and the previous file can be renamed back. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359158#comment-359158
]
Kristian Rosenvold commented on MSHARED-394:
Haven given this issue some thought I believe I have come up with a radically
better solution than what is suggested here. There is no point in working on
the changes suggested here, at least not until I give up my other plan.
Since I am currently working on a slightly different task, it will be a couple
of weeks before I'll make any activity on this issue.
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359160#comment-359160
]
Vladimir Sitnikov commented on MSHARED-394:
---
Thanks for the update. Good to know there is better solution.
Can you please give a high-level overview? What's the idea?
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MTOOLCHAINS-14) Toolchains should support architecture definition
[ https://jira.codehaus.org/browse/MTOOLCHAINS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Pettey closed MTOOLCHAINS-14. Resolution: Not A Bug Sorry, thIs was PEBKAC. It works as it should when I don't have spurious characters in my file. Toolchains should support architecture definition - Key: MTOOLCHAINS-14 URL: https://jira.codehaus.org/browse/MTOOLCHAINS-14 Project: Maven Toolchains Plugin Issue Type: Improvement Reporter: Gordon Pettey Priority: Minor Toolchains should support an arch element in provides to allow defining multiple architecture JVMs of the same version. This would help support simple testing of native library code that needs a matching JVM. Possible workaround is to specify a different version for each additional arch, but the extra element would be nicer. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359171#comment-359171
]
Kristian Rosenvold commented on MSHARED-394:
Collect all the interpolation strings (e.g. ${project.version}), write the keys
to a file in target/ somewhere, together with a hash of all the values the keys
produced. Upon subsequent interpolation attempts, re-evaluate all the
expressions toward their context to see if the values have changed. If so,
everything needs to be filtered. Else filter only files that are newer than
their corresponding files in target. Do nothing for the rest.
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359172#comment-359172
]
Vladimir Sitnikov commented on MSHARED-394:
---
This is non-trivial.
0) My main concern is Velocity templates. org.apache:apache pom uses Velocity
templates to render {{DEPENDENCIES}}, etc.
1) Regular property-only interpolations are important as well, however I does
not make much sense if we cover just the basic stuff.
2) In Velocity, I expect the following expressions are very hard to tame:
{{#include(one.gif,two.txt,three.htm)}}, {{#evaluate}}, {{#define}}
3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you
can identify the required bits. If you try to hash the whole {{MavenProject}}
thing, I expect the cache will always miss.
Do you still think this kind of coupling between filtering and Velocity is
worth doing?
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359172#comment-359172
]
Vladimir Sitnikov edited comment on MSHARED-394 at 12/16/14 2:34 PM:
-
This is non-trivial.
0) My main concern is Velocity templates. org.apache:apache pom uses Velocity
templates to render {{DEPENDENCIES}}, etc.
1) Regular property-only interpolations are important as well, however it does
not make much sense if we cover just the basic stuff.
2) In Velocity, I expect the following expressions are very hard to tame:
{{#include(one.gif,two.txt,three.htm)}}, {{#evaluate}}, {{#define}}
3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you
can identify the required bits. If you try to hash the whole {{MavenProject}}
thing, I expect the cache will always miss.
Do you still think this kind of coupling between filtering and Velocity is
worth doing?
was (Author: vladimirsitnikov):
This is non-trivial.
0) My main concern is Velocity templates. org.apache:apache pom uses Velocity
templates to render {{DEPENDENCIES}}, etc.
1) Regular property-only interpolations are important as well, however I does
not make much sense if we cover just the basic stuff.
2) In Velocity, I expect the following expressions are very hard to tame:
{{#include(one.gif,two.txt,three.htm)}}, {{#evaluate}}, {{#define}}
3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you
can identify the required bits. If you try to hash the whole {{MavenProject}}
thing, I expect the cache will always miss.
Do you still think this kind of coupling between filtering and Velocity is
worth doing?
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359173#comment-359173
]
Robert Scholte commented on MPIR-263:
-
[Here's|https://www.youtube.com/watch?v=EA5JntR759sfeature=player_embedded#t=675]
the hangout I was referring to. Right now we don't have a good solution, both
the $\{maven.compiler.target} and the reading of the compiler-plugin
configuration are workarounds for something we cannot fix right now. the
parameter is probably the cleanest solution, but requires the user to specify
this as a property in his pom.xml. Reading the configuration is more user
friendly, but clashes with the concept that plugins shouldn't be aware of each
other.
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3832) Allow wildcards in dependency exclusions
[
https://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359176#comment-359176
]
Ciprian Pascu commented on MNG-3832:
Sorry for writing so late Sergei,
The scenario is simple:
Create a pom file. Add a dependency with transitive dependencies. For example
axis 2 dependency.
From command line execute mvn dependency:tree -Dverbose=true
The entire tree is visible.
Add exclusion with * to axis 2 dependency.
From command line execute again mvn dependency:tree -Dverbose=true
The entire tree is visible. But it shouldn't.
Allow wildcards in dependency exclusions
Key: MNG-3832
URL: https://jira.codehaus.org/browse/MNG-3832
Project: Maven
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
Assignee: Robert Scholte
Fix For: issues to be reviewed for 3.0.6, 3.2.1
Attachments: MNG-3832-maven-artifact.patch
I would like to be able to exclude all transitive dependencies from a certain
dependencies. This is especially useful when depending on an artifact with a
classifier that may not have the same dependencies as the main artifact.
Currently the only way to do this is by excluding each dependency
individually which requires significant effort and is prone to becoming out
of date. The following syntax is one possibility.
Exclude all transitive dependencies
{code}
exclusion
groupId*/groupId
/exclusion
{code}
Exclude transitive dependencies with the groupId org.company
{code}
exclusion
groupIdorg.company/groupId
artifactId*/artifactId
/exclusion
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359179#comment-359179
]
Frank Brewer commented on SCM-775:
--
His Chris-
I just sent you an email looking for status on this issue. It too is important
to us. The resolution that Mr. Shah mentions in SCM-775 describes perfectly
what we need.
Thanks.
Request for new optional parameter RTC (workItem) with release:prepare to
associate workitem with changesets got created during build process
-
Key: SCM-775
URL: https://jira.codehaus.org/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359179#comment-359179
]
Frank Brewer edited comment on SCM-775 at 12/16/14 3:52 PM:
Hi Chris-
I just sent you an email looking for status on this issue. It too is important
to us. The resolution that Mr. Shah mentions in SCM-775 describes perfectly
what we need.
Thanks.
was (Author: fdbrewer):
His Chris-
I just sent you an email looking for status on this issue. It too is important
to us. The resolution that Mr. Shah mentions in SCM-775 describes perfectly
what we need.
Thanks.
Request for new optional parameter RTC (workItem) with release:prepare to
associate workitem with changesets got created during build process
-
Key: SCM-775
URL: https://jira.codehaus.org/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3832) Allow wildcards in dependency exclusions
[
https://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359180#comment-359180
]
Robert Scholte commented on MNG-3832:
-
[~ciprianpascu], you're facing an issue with the {{maven-dependency-plugin}},
not with Maven Core. Ensure you're using the latest version:
{noformat}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.9:tree -Dverbose=true
{noformat}
If that still shows the wrong tree, create an issue for the
maven-dependency-plugin.
To ensure that excludes works, run {{mvn compile -X}}, which will show the
actual project jars used by Maven.
Allow wildcards in dependency exclusions
Key: MNG-3832
URL: https://jira.codehaus.org/browse/MNG-3832
Project: Maven
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
Assignee: Robert Scholte
Fix For: issues to be reviewed for 3.0.6, 3.2.1
Attachments: MNG-3832-maven-artifact.patch
I would like to be able to exclude all transitive dependencies from a certain
dependencies. This is especially useful when depending on an artifact with a
classifier that may not have the same dependencies as the main artifact.
Currently the only way to do this is by excluding each dependency
individually which requires significant effort and is prone to becoming out
of date. The following syntax is one possibility.
Exclude all transitive dependencies
{code}
exclusion
groupId*/groupId
/exclusion
{code}
Exclude transitive dependencies with the groupId org.company
{code}
exclusion
groupIdorg.company/groupId
artifactId*/artifactId
/exclusion
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1125) Running multiple methods via the `test` property does not work in junit47 provider
Jörn Horstmann created SUREFIRE-1125: Summary: Running multiple methods via the `test` property does not work in junit47 provider Key: SUREFIRE-1125 URL: https://jira.codehaus.org/browse/SUREFIRE-1125 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.18 Reporter: Jörn Horstmann Priority: Minor https://github.com/apache/maven-surefire/pull/75 The syntax discussed in https://jira.codehaus.org/browse/SUREFIRE-745 and documented in http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#Running_a_Set_of_Methods_in_a_Single_Test_Class does not work when using the junit 4.7 provider. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359183#comment-359183 ] Omair Majid edited comment on MJAVADOC-384 at 12/16/14 5:21 PM: Attempt number 2. Is this what you had in mind? was (Author: omajid): Attempt number 2 Allow whitespace in javadoc exclude list Key: MJAVADOC-384 URL: https://jira.codehaus.org/browse/MJAVADOC-384 Project: Maven Javadoc Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Omair Majid Priority: Minor Attachments: spaces-for-javadoc-exclude-02.patch, spaces-for-javadoc-exclude-list One of the projects that I am working on has a fairly large exclude list for javadoc packages. maven-javadoc-plugin requires me to put this in on line in the pom, which makes it very hard to read. I think it would be nicer to allow separating the items in the list with newlines and other whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omair Majid updated MJAVADOC-384: - Attachment: spaces-for-javadoc-exclude-02.patch Attempt number 2 Allow whitespace in javadoc exclude list Key: MJAVADOC-384 URL: https://jira.codehaus.org/browse/MJAVADOC-384 Project: Maven Javadoc Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Omair Majid Priority: Minor Attachments: spaces-for-javadoc-exclude-02.patch, spaces-for-javadoc-exclude-list One of the projects that I am working on has a fairly large exclude list for javadoc packages. maven-javadoc-plugin requires me to put this in on line in the pom, which makes it very hard to read. I think it would be nicer to allow separating the items in the list with newlines and other whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359185#comment-359185
]
Jonathan Sailor commented on MNG-5686:
--
Kristian, it looks like 0001 was applied but not 0002. 0002 is necessary to fix
this bug.
mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
---
Key: MNG-5686
URL: https://jira.codehaus.org/browse/MNG-5686
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.2.3
Environment: Mac OS X 10.9.4
Reporter: Takayoshi Fujiki
Assignee: Kristian Rosenvold
Fix For: 3.2.5
Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
From 3.2.3, mvn cannot start and outputs the following error.
{code}
$ ./apache-maven-3.2.3/bin/mvn -version
Error: JAVA_HOME is not defined correctly.
We cannot execute /usr/libexec/java_home/bin/java
{code}
3.2.2 doesn't have this problem.
{code}
$ ./apache-maven-3.2.2/bin/mvn -version
Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
2014-06-17T22:51:42+09:00)
Maven home: /Users/xxx/tmp/apache-maven-3.2.2
Java version: 1.8.0_11, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.9.4, arch: x86_64, family: mac
{code}
When I modified {{bin/mvn}} like the following, this problem was gone.
{code}
--- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
+++ bin/mvn 2014-09-10 03:34:18.0 +0900
@@ -83,7 +83,7 @@
#
# Apple JDKs
#
- export JAVA_HOME=/usr/libexec/java_home
+ export JAVA_HOME=`/usr/libexec/java_home`
fi
;;
esac
{code}
Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
and {{$(command)}} is a style of [Command
Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
style is {{`command`}}).
So removing $() breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
