[jira] (MCOMPILER-188) Add a flag to be able to disable incremental feature
[ https://jira.codehaus.org/browse/MCOMPILER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCOMPILER-188: --- Fix Version/s: 3.1 > Add a flag to be able to disable incremental feature > > > Key: MCOMPILER-188 > URL: https://jira.codehaus.org/browse/MCOMPILER-188 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Olivier Lamy > Fix For: 3.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-264) afterRebuildExecution must create createdFiles.lst file if not exists
[ https://jira.codehaus.org/browse/MSHARED-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-264. Resolution: Fixed Fix Version/s: maven-shared-incremental-1.1 Assignee: Olivier Lamy fixed. > afterRebuildExecution must create createdFiles.lst file if not exists > - > > Key: MSHARED-264 > URL: https://jira.codehaus.org/browse/MSHARED-264 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-incremental >Affects Versions: maven-shared-incremental-1.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-shared-incremental-1.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCOMPILER-187. -- Resolution: Fixed fixed http://svn.apache.org/r1413925 > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://jira.codehaus.org/browse/MCOMPILER-187 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-264) afterRebuildExecution must create createdFiles.lst file if not exists
Olivier Lamy created MSHARED-264: Summary: afterRebuildExecution must create createdFiles.lst file if not exists Key: MSHARED-264 URL: https://jira.codehaus.org/browse/MSHARED-264 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-incremental Affects Versions: maven-shared-incremental-1.0 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
https://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314415#comment-314415
]
Curtis Rueden commented on MNG-4687:
Another relevant recent thread from maven-users:
http://mail-archives.apache.org/mod_mbox/maven-users/201211.mbox/%3CCABbdPEaJPFahp8uAWmUYYkjKQQ3XdMWb6eeos9Qbx=h2bdp...@mail.gmail.com%3E
> Maven should not warn about incorrect parent path when no relativePath is
> specified
> ---
>
> Key: MNG-4687
> URL: https://jira.codehaus.org/browse/MNG-4687
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 3.0-beta-1
>Reporter: Paul Gier
>Priority: Minor
> Attachments: MNG-relativePath.zip
>
>
> If a module pom uses a parent other than the one in the parent directory,
> maven logs a warning. In some cases it is necessary that a module pom has an
> external parent pom, and there is no way to refer to this external pom in the
> relativePath. If nothing is specified in the relativePath, Maven should not
> log the warning.
> {noformat}
> [WARNING] 'parent.relativePath' of POM
> org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
> (/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
> org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
> please verify your project structure @
> {noformat}
> The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-700) Fix TfsChangeLogCommand
Vladimir Nemergut created SCM-700: - Summary: Fix TfsChangeLogCommand Key: SCM-700 URL: https://jira.codehaus.org/browse/SCM-700 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-tfs Reporter: Vladimir Nemergut The TfsChangeLogCommand executes the following command: tf history -format:detailed It should call /noprompt and /recursive as well. Without /noprompt the command will just open an UI and doesn't output anything. /recursive is important if the passed is a folder name. The TfsChangeLogConsumer should be changed accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reopened MCOMPILER-187: --- There is a problem with the way the metadata is recorded. After a clean, it will do a full compile once, but record the files as "created". The second compile will look for the inputFiles.lst which isn't there yet. Not finding it, it will again recompile everything. After that, it works fine. So two full recompiles after a clean. > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://jira.codehaus.org/browse/MCOMPILER-187 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-522) release plugin tagging don't work for submodules
[
https://jira.codehaus.org/browse/MRELEASE-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314401#comment-314401
]
Luke Rathbone commented on MRELEASE-522:
We have several projects in this format. In this real world case, sometimes the
modules are released independently, sometimes they are all released at the same
time. Each module _must_ have it's own trunk to accommodate this. The key here
is that we are being *flexible*. It would be nice to move this flexibility into
the plugin.
I've tried experimenting with {{tagBase}} and {{connectionUrl}}, but didn't get
anywhere. Is there anything we can add to the plugin configuration as a
workaround?
> release plugin tagging don't work for submodules
>
>
> Key: MRELEASE-522
> URL: https://jira.codehaus.org/browse/MRELEASE-522
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_14
> Java home: C:\Programme\Java\jdk1.6.0_14\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Ruediger Gubler
>
> release:prepare doesn't tag submodules which are in different svn path.
> We have the following structure in our svn repositories:
> parentmodule/[trunk|tags|branches]
> module1/[trunk|tags|branches]
> module2/[trunk|tags|branches]
> ...
> moduleN/[trunk|tags|branches]
> I tried to include the modules using ../module1
> Which caused to the svn error: the parent directory is not in version control
> After changing the modules to module1 and adding the
> submodules via svn:externals into the parent svn directory
> the release:prepare finishes successfully but the submodules are not tagged.
> Yours Rüdiger
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-67) Multiple Executions unsafe
[
https://jira.codehaus.org/browse/MRRESOURCES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314400#comment-314400
]
John Patrick commented on MRRESOURCES-67:
-
To confirm
client-X jar contains (aka jar 1)
client.properties (aka file 1)
client-X.properties (aka file 2)
client-Y jar contains (aka jar 2)
client.properties (aka file 3)
client-Y.properties (aka file 4)
client-Z jar contains (aka jar 3)
client.properties (aka file 5)
client-Z.properties (aka file 6)
So after a build I get the following;
${project.build.directory/${project.build.finalName}-client-X/WEB-INF/classes/client.properties
(file 1)
${project.build.directory/${project.build.finalName}-client-X/WEB-INF/classes/client-X.properties
(file 2)
${project.build.directory/${project.build.finalName}-client-Y/WEB-INF/classes/client.properties
(file 1 not file 3 as i expect)
${project.build.directory/${project.build.finalName}-client-Y/WEB-INF/classes/client-Y.properties
(file 4)
${project.build.directory/${project.build.finalName}-client-Z/WEB-INF/classes/client.properties(file
1 not file 5 as i expect)
${project.build.directory/${project.build.finalName}-client-Z/WEB-INF/classes/client-Z.properties
(file 6)
> Multiple Executions unsafe
> --
>
> Key: MRRESOURCES-67
> URL: https://jira.codehaus.org/browse/MRRESOURCES-67
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Mac & Windows
> Java 1.6 & 1.7
>Reporter: John Patrick
>
> When using executions, the resourceBundles in the 1st are using in all
> subsequent executions.
> Have a simple jar(s) which contain
> src/main/resources/WEB-INF/classes/client.properties
> Those are built in project-web-client-X and project-web-client-Y. The jar
> contain the correct client.properties.
> Within the war pom I define.
> org.apache.maven.pluginsmaven-remote-resoruces-plugin
>
>
> client-X
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-X
>
>
> ${project.groupId}:project-web-client-X:${project.version}
>
>
>
>
> client-Y
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-Y
>
>
> ${project.groupId}:project-web-client-Y:${project.version}
>
>
>
>
> client-Z
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-Z
>
>
> ${project.groupId}:project-web-client-Z:${project.version}
>
>
>
>
> [...]
> I do a clean install and I get client-X client.properties in the following
> locations. Not the one i'm expecting using the resource bundles above.
> ${project.build.directory/${project.build.finalName}-client-X/WEB-INF/classes/client.properties
> ${project.build.directory/${project.build.finalName}-client-Y/WEB-INF/classes/client.properties
> ${project.build.directory/${project.build.finalName}-client-Z/WEB-INF/classes/client.properties
> John
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-787) release:prepare-with-pom fails when suppressCommitBeforeTag is used (SVN)
[
https://jira.codehaus.org/browse/MRELEASE-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314399#comment-314399
]
Erik Schepers commented on MRELEASE-787:
Robert,
I've set remoteTagging to false (had it set to false all the time).
According to the documentation it should be false when using
{{suppressCommitBeforeTag=true}}
> release:prepare-with-pom fails when suppressCommitBeforeTag is used (SVN)
> -
>
> Key: MRELEASE-787
> URL: https://jira.codehaus.org/browse/MRELEASE-787
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare-with-pom
>Affects Versions: 2.2, 2.3.2
> Environment: Subversion 1.6.12
>Reporter: Brian Albers
>Assignee: Robert Scholte
> Fix For: 2.4
>
> Attachments: MRELEASE-787.diff
>
>
> When running a prepare-with-pom goal, using the suppressCommitBeforeTag
> option causes the removal of the release-pom.xml to fail.
> This is due to the fact that the SVN command to remove the release-pom won't
> complete because the release-pom was never committed. The ultimate error is
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare-with-pom
> (default-cli) on project com.example.project: Cannot remove release POMs from
> SCM
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: Use --force to override this restriction
> [ERROR] svn: 'C:\code\release-pom.xml' has local modifications
> {code}
> When suppressCommitBeforeTag is not used, the SCM operations are:
> # Status
> # Add the release-pom.xml
> # (build)
> # Commit with release version
> # Copy (create the tag)
> # Remove the release-pom.xml
> # Commit with next development version
> When suppressCommitBeforeTag is used, step #4 is omitted, which causes step
> #6 to fail with the supplied error. In both cases, the tag successfully has
> the release-pom.xml included.
> Could the --force option be used to suppress the warning?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-187) incremental stuff detect changes even if nothing has changed means too much compilation
[
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314394#comment-314394
]
Daniel Kulp commented on MCOMPILER-187:
---
I'm still seeing:
{code}
[INFO] --- maven-compiler-plugin:3.1-SNAPSHOT:compile (default-compile) @
cxf-api ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 519 source files to /Users/dkulp/working/cxf/api/target/classes
{code}
> incremental stuff detect changes even if nothing has changed means too much
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 3.1
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-67) Multiple Executions unsafe
John Patrick created MRRESOURCES-67:
---
Summary: Multiple Executions unsafe
Key: MRRESOURCES-67
URL: https://jira.codehaus.org/browse/MRRESOURCES-67
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.4
Environment: Mac & Windows
Java 1.6 & 1.7
Reporter: John Patrick
When using executions, the resourceBundles in the 1st are using in all
subsequent executions.
Have a simple jar(s) which contain
src/main/resources/WEB-INF/classes/client.properties
Those are built in project-web-client-X and project-web-client-Y. The jar
contain the correct client.properties.
Within the war pom I define.
org.apache.maven.pluginsmaven-remote-resoruces-plugin
client-X
process-resources
process
${project.build.directory/${project.build.finalName}-client-X
${project.groupId}:project-web-client-X:${project.version}
client-Y
process-resources
process
${project.build.directory/${project.build.finalName}-client-Y
${project.groupId}:project-web-client-Y:${project.version}
client-Z
process-resources
process
${project.build.directory/${project.build.finalName}-client-Z
${project.groupId}:project-web-client-Z:${project.version}
[...]
I do a clean install and I get client-X client.properties in the following
locations. Not the one i'm expecting using the resource bundles above.
${project.build.directory/${project.build.finalName}-client-X/WEB-INF/classes/client.properties
${project.build.directory/${project.build.finalName}-client-Y/WEB-INF/classes/client.properties
${project.build.directory/${project.build.finalName}-client-Z/WEB-INF/classes/client.properties
John
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-687) Fix TFS Support
[
https://jira.codehaus.org/browse/SCM-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314387#comment-314387
]
Freddy Mallet commented on SCM-687:
---
In fact according to the following discussion
http://social.msdn.microsoft.com/Forums/en-US/tfspowertools/thread/d1820874-be55-4cba-a612-119affeca145,
with TFS 2010 and TFS 2012, the tfpt.exe annotate /noprompt command doesn't
dump anymore the author and date of last commit. So as long as this will not be
case, I'm not sure that there is anything to do on Maven SCM side.
> Fix TFS Support
> ---
>
> Key: SCM-687
> URL: https://jira.codehaus.org/browse/SCM-687
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.7
> Environment: TFS 2008 (Team Explorer 2008 + TFPowerTools 2008)
> Sonar 3.1.1
> Sonar Runner 1.4
> sonar-scm-activity-plugin-1.5.jar
> maven-scm-api-1.7.jar
>Reporter: Jonatan Urfalino
>
> When running SCM Activity Plugin for TFS you get hundreeds of
> "java.text.ParseException: Unparseable date" exceptions, because the 'tfpt
> annotate /nopromts' command does not return neither the date nor the author
> of each line, only the changeset number.
> (Thus the second string that the plugin tries to find is not a date, but the
> file code itself)
> Also see
> [SONARPLUGINS-373|http://jira.codehaus.org/browse/SONARPLUGINS-373?focusedCommentId=307289#comment-307289]
> Error:
> {code}
> 09:36:29.218 ERROR .s.ScmActivitySensor - Failure during SCM blame retrieval
> java.lang.NullPointerException: null
> at java.util.Calendar.setTime(Calendar.java:1106) ~[na:1.7.0_03]
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:955)
> ~[na:1.7.0_03]
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:948)
> ~[na:1.7.0_03]
> at
> org.sonar.api.utils.DateUtils$ThreadSafeDateFormat.format(DateUtils.java:149)
> ~[sonar-plugin-api-3.1.1.jar:na]
> at java.text.DateFormat.format(DateFormat.java:336) ~[na:1.7.0_03]
> at org.sonar.api.utils.DateUtils.formatDateTime(DateUtils.java:55)
> ~[sonar-plugin-api-3.1.1.jar:na]
> at org.sonar.plugins.scmactivity.Blame.save(Blame.java:61) ~[na:na]
> at
> org.sonar.plugins.scmactivity.BlameVersionSelector.fileChanged(BlameVersionSelector.java:73)
> ~[na:na]
> at
> org.sonar.plugins.scmactivity.BlameVersionSelector.detect(BlameVersionSelector.java:57)
> ~[na:na]
> at
> org.sonar.plugins.scmactivity.ScmActivitySensor$1.call(ScmActivitySensor.java:110)
> ~[na:na]
> at
> org.sonar.plugins.scmactivity.ScmActivitySensor$1.call(ScmActivitySensor.java:108)
> ~[na:na]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> ~[na:1.7.0_03]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> ~[na:1.7.0_03]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> ~[na:1.7.0_03]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> ~[na:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) ~[na:1.7.0_03]
> 09:36:31.464 WARN .p.s.SonarScmManager - skip ParseException: Unparseable
> date: "System.Configuration;" during parsing date System.Configuration; with
> pattern MM/dd/ with Locale en
> java.text.ParseException: Unparseable date: "System.Configuration;"
> at java.text.DateFormat.parse(DateFormat.java:357) ~[na:1.7.0_03]
> at
> org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
> [maven-scm-api-1.7.jar:1.7]
> at
> org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:68)
> [maven-scm-api-1.7.jar:1.7]
> at
> org.apache.maven.scm.provider.tfs.command.blame.TfsBlameConsumer.consumeLine(TfsBlameConsumer.java:66)
> [maven-scm-provider-tfs-1.7.jar:1.7]
> at
> org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:197)
> [plexus-utils-2.0.5.jar:na]
> at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:137)
> [plexus-utils-2.0.5.jar:na]
> 09:36:31.464 WARN .p.s.SonarScmManager - skip ParseException: Unparseable
> date: "System.Web;" during parsing date System.Web; with pattern MM/dd/
> with Locale en
> java.text.ParseException: Unparseable date: "System.Web;"
> at java.text.DateFormat.parse(DateFormat.java:357) ~[na:1.7.0_03]
> at
> org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
> [maven-scm-api-1.7.jar:1.7]
> at
> org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:68)
> [maven-scm-api-1.7.jar:1.7]
> at
> org.apache.maven.scm.provider.tfs.command.blame.TfsBlameConsumer.consumeLine(TfsBlameConsumer.java:66)
> [maven-scm-provider-tfs-1.7.jar:1.7]
> at
> org
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314385#comment-314385 ] Scott Sosna commented on MNG-3092: -- I'm surprised of the focus for excluding snapshots; I see snapshots as being the main use case of ranges, in a development environment as I and at least one other have described. For a release artifact, I expect it to have well-known, tested, absolute dependencies. I don't want dependencies wandering as, for example, new versions of log4j get released. When the new version of log4j has been tested/approved/certified, then put out a new POM with a slight version modification. And I would never expect (or use) a released artifact that used snapshots. However, a snapshot artifact should be able to use ranges referring to both snapshot and released artifacts, as necessary. Instead of flags to determine inclusion/exclusion of snapshots within ranges, can we base on the type of artifact? -For released artifacts, ranges only include releases and no snapshots in dependency resolution -For snapshot artifacts, ranges include both release and snapshots in dependency resolution The other question is to determine where snapshots fall in a version range. If you presume that a released artifact represents finality, then snapshots always are less than the released artifact. [1.0.0,1.3.0] starts at the 1.0.0 release up through the 1.3.0 release. If the built artifact is a release, then you'd consider all 1.0.x, 1.1.x, 1.2.x releases as well as 1.3.0 itself. If the build is a snapshot, you'd also consider all > 1.0.x snapshots, all 1.1.x snapshots, all 1.2.x snapshots, and all 1.3.0 snapshots. [1.0.0-SNAPSHOT,1.0.1] implies building a snapshot artifact, discussed previously, and should consider all 1.0.0.x snapshots, 1.0.0 release, all 1.0.1.x snapshots and 1.0.1 release. [Not comprehensive examples, but hopefully enough to move the conversation forward.] Now that this has been moved to 3.1.1, how do we continue this conversation so it doesn't die off again until 3.1.1 is next up. This must be dealt with eventually. If no resolution is determined, than at least go back to the functionality as implemented in Maven2. While not perfect, it doesn't break backwards-compatibility. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-188) Add a flag to be able to disable incremental feature
Olivier Lamy created MCOMPILER-188: -- Summary: Add a flag to be able to disable incremental feature Key: MCOMPILER-188 URL: https://jira.codehaus.org/browse/MCOMPILER-188 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 3.0 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-804) scm:cvs dosn't take global .cvsignore from user home dir
Maciej Matys created MRELEASE-804: - Summary: scm:cvs dosn't take global .cvsignore from user home dir Key: MRELEASE-804 URL: https://jira.codehaus.org/browse/MRELEASE-804 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare, prepare-with-pom, scm Affects Versions: 2.3.2 Environment: Win7 x64, mvn 3.0.4 Reporter: Maciej Matys Priority: Critical As in title, then running prepare or prepare-with-pom on project with cvs as scm ,phase 'scm-check-modifications' fails with 'Cannot prepare the release because you have local modifications' showing that I've uncommitted files *.iml (Idea modules files) although I have *.iml in global .cvsignore file in my user home dir. I don't want to configure *.iml in every project whats why I have it in global .cvsignore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-388) NPE in analyze-report
[
https://jira.codehaus.org/browse/MDEP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MDEP-388:
-
Issue Type: Bug (was: New Feature)
> NPE in analyze-report
> -
>
> Key: MDEP-388
> URL: https://jira.codehaus.org/browse/MDEP-388
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.5.1
>Reporter: Benson Margulies
> Fix For: 2.6
>
>
> Using Maven 3.0.4, and site plugin 3.2, and an execution of the
> analyze-report goal, I get the following NPE. I'm going to go try to make
> some sense and add notes here.
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
