[jira] (MCHECKSTYLE-193) Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration
[ https://jira.codehaus.org/browse/MCHECKSTYLE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326870#comment-326870 ] Oleg Kalnichevski commented on MCHECKSTYLE-193: --- [DEBUG] executeCheckstyle start headerLocation : hc-stylecheck/asl2.header [DEBUG] Added 220 source files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/java'. [DEBUG] Added 1 resource files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources'. [DEBUG] Added 221 files to process. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.URLResourceLoader. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader. [DEBUG] request.getConfigLocation() hc-stylecheck/default.xml [DEBUG] Extension realms for project org.apache.httpcomponents:project:pom:7-SNAPSHOT: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] [DEBUG] Extension realms for project org.apache:apache:pom:13: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] ... [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:1: Missing a header - not enough lines in file. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:17: Trailing whitespace Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration -- Key: MCHECKSTYLE-193 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-193 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski Resource files get included into checkstyle audit regardless of explicit sourceDirectory / includes / excludes configuration, which seems wrong to me. I found no way of forcing version 2.10 to revert to the behavior of version 2.9.1 with regards to project resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-193) Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration
Oleg Kalnichevski created MCHECKSTYLE-193: - Summary: Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration Key: MCHECKSTYLE-193 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-193 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski Resource files get included into checkstyle audit regardless of explicit sourceDirectory / includes / excludes configuration, which seems wrong to me. I found no way of forcing version 2.10 to revert to the behavior of version 2.9.1 with regards to project resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-194) Stylecheck audit invoked on intermedaite files generated by Clover2 plugin
[ https://jira.codehaus.org/browse/MCHECKSTYLE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326882#comment-326882 ] Oleg Kalnichevski commented on MCHECKSTYLE-194: --- [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ httpcore --- [INFO] Deleting /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target [INFO] [INFO] --- maven-clover2-plugin:3.1.10.1:setup (default-cli) @ httpcore --- [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Creating new database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 220 files (15 packages). [INFO] Elapsed time = 1.585 secs. (138.801 files/sec, 18,435.961 srclines/sec) [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Updating existing database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 88 files (15 packages). [INFO] 633 test methods detected. [INFO] Elapsed time = 0.76 secs. (115.789 files/sec, 22,477.633 srclines/sec) [INFO] [INFO] --- maven-checkstyle-plugin:2.9.1:checkstyle (validate) @ httpcore --- [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/ProtocolException.java:1: Line does not match expected header line of '/*'. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/concurrent/Cancellable.java:1: Line does not match expected header line of '/*'. Stylecheck audit invoked on intermedaite files generated by Clover2 plugin -- Key: MCHECKSTYLE-194 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-194 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski This issue may not necessarily be a problem with Maven Stylecheck plugin but I just unable to pinpoint the exact culprit here and the Stylecheck appears to be trying to audit intermediate files generated by Clover2 report. I am really unsure how to approach this problem. Please let me know if you need more info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-194) Stylecheck audit invoked on intermedaite files generated by Clover2 plugin
Oleg Kalnichevski created MCHECKSTYLE-194: - Summary: Stylecheck audit invoked on intermedaite files generated by Clover2 plugin Key: MCHECKSTYLE-194 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-194 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski This issue may not necessarily be a problem with Maven Stylecheck plugin but I just unable to pinpoint the exact culprit here and the Stylecheck appears to be trying to audit intermediate files generated by Clover2 report. I am really unsure how to approach this problem. Please let me know if you need more info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5485) ClassRealmAdapter.getParent() handles null parents incorrectly
Stefan Fromm created MNG-5485:
-
Summary: ClassRealmAdapter.getParent() handles null parents
incorrectly
Key: MNG-5485
URL: https://jira.codehaus.org/browse/MNG-5485
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.5
Environment: Java 1.6.0_30, Windows XP Professional 2002 SP3
Reporter: Stefan Fromm
Here is the code from plexus classworlds 2.4.x.
{noformat}
public ClassRealm getParent()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public ClassRealm getParentRealm()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public static ClassRealmAdapter getInstance(
org.codehaus.plexus.classworlds.realm.ClassRealm newRealm )
{
ClassRealmAdapter adapter = new ClassRealmAdapter( newRealm );
return adapter;
}
{noformat}
If the parent of the backend realm is {{null}}, then there is returned a new
{{ClassRealmAdapter}} instead of {{null}}. Calling methods on the returned
{{ClassRealmAdapter}} produces NPEs.
I think, that {{getParent()}} and {{getParentRealm()}} could be patched like
this:
{noformat}
public ClassRealm getParentRealm()
{
return realm.getParentRealm() != null
? ClassRealmAdapter.getInstance( realm.getParentRealm())
: null;
}
public ClassRealm getParent()
{
return getParentRealm();
}
{noformat}
Or should {{null}} be handled in {{ClassRealmAdapter.getInstance()}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-381) Both Maven 2 and 3 fail to retrieve a dependency that is larger than Integer.MAX_VALUE
[
https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326915#comment-326915
]
Olivier Lamy commented on WAGON-381:
still weird for me.
I added a unit test
https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=05098b3f0f0378a7272f0d9491ef356889bfc67f
And those huge files (with Content-Length or Chunked) are correctly downloaded.
Both Maven 2 and 3 fail to retrieve a dependency that is larger than
Integer.MAX_VALUE
Key: WAGON-381
URL: https://jira.codehaus.org/browse/WAGON-381
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.2
Reporter: Evgeny Goldin
Assignee: Olivier Lamy
Fix For: 2.5
Attachments: 1.png, 2.png
We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
*{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
*{{2147483647}}* size to be downloaded to local maven repo, which is exactly
2sup31/sup-1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MPOM-44) Compiler version settings cannot be overridden by defining maven.compiler.source/target
Sebb created MPOM-44:
Summary: Compiler version settings cannot be overridden by
defining maven.compiler.source/target
Key: MPOM-44
URL: https://issues.apache.org/jira/browse/MPOM-44
Project: Maven POMs
Issue Type: Bug
Components: maven-plugins
Affects Versions: ASF-13
Reporter: Sebb
The compiler plugin by default picks up the source and target from the
properties
maven.compiler.source and maven.compiler.target.
Unfortunately, the Apache POM uses the following fixed values to specify the
version:
{code}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.5.1/version
configuration
source1.4/source
target1.4/target
/configuration
{code}
This means that child poms which use the properties expecting them to be
honoured have to override the configuration as follows:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source${maven.compile.source}/source
target${maven.compile.target}/target
/configuration
/plugin
{code}
This is unnecessary and wrong.
For compatibility, the Apache Pom does need to still specify the default
source/target as 1.4 (the plugin default is 1.5), but it should do so by using
the standard properties which can then be overridden.
In fact, if the properties are defined, the compiler plugin config could be
dropped, as it is the default behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-44) Compiler version settings cannot be overridden by defining maven.compiler.source/target
[
https://issues.apache.org/jira/browse/MPOM-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated MPOM-44:
-
Attachment: MPOM-44.patch
Compiler version settings cannot be overridden by defining
maven.compiler.source/target
---
Key: MPOM-44
URL: https://issues.apache.org/jira/browse/MPOM-44
Project: Maven POMs
Issue Type: Bug
Components: maven-plugins
Affects Versions: ASF-13
Reporter: Sebb
Attachments: MPOM-44.patch
The compiler plugin by default picks up the source and target from the
properties
maven.compiler.source and maven.compiler.target.
Unfortunately, the Apache POM uses the following fixed values to specify the
version:
{code}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.5.1/version
configuration
source1.4/source
target1.4/target
/configuration
{code}
This means that child poms which use the properties expecting them to be
honoured have to override the configuration as follows:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source${maven.compile.source}/source
target${maven.compile.target}/target
/configuration
/plugin
{code}
This is unnecessary and wrong.
For compatibility, the Apache Pom does need to still specify the default
source/target as 1.4 (the plugin default is 1.5), but it should do so by
using the standard properties which can then be overridden.
In fact, if the properties are defined, the compiler plugin config could be
dropped, as it is the default behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated MRELEASE-431: - Attachment: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326938#comment-326938 ] Robert Munteanu commented on MRELEASE-431: -- I've attached a patch which adds a 'versionPolicy' property to the plugin. Possible values are 'default' - which is what the plugin does today - and 'odd-even', which ensures that snapshot dependencies are always odd and release versions are always even. You can also review the [commit on github|https://github.com/rombert/release/commit/35e42901868d5c18289e6687bbecdd78cddbf03e] as well. I tried to keep changes minimal and self-contained and also added tests as well as I could. I'm open to iterating on this so please let me know what you think. Thanks! Robert Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[
https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326943#comment-326943
]
Robert Scholte commented on MRELEASE-431:
-
There are a lot of issues related to version policies. I could try to collect
all wishes, but I'm afraid that I'll forget a few and that in the near future
developers invent more exotic ways of version policies.
To prevent this, we should define a {{VersionPolicyManager}} interface
(probably in the separated {{api}}-project), so everyone can code his own
version. It'll be just a matter of injecting your preferred implementation.
I'm not sure if I should introduce a {{release-api}} project for this or start
a new shared component. With the latter we could also reuse it for the
versions-maven-plugin.
Configuration of policy for calculating next (release) version
--
Key: MRELEASE-431
URL: https://jira.codehaus.org/browse/MRELEASE-431
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Components: prepare
Affects Versions: 2.0-beta-8
Reporter: Carsten Ziegeler
Attachments:
0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch
Currently, when preparing the release, the version to release is always the
next version which usually is the current version without the snapshot
extension.
There are quiet a lot projects (Apache Felix, Sling and others) following an
even release numbering policy. So while the current development version is
odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4.
It would be nice if this could be made configuration through some
configuration property like
versionPolicynext-even/versionPolicy (with possible values being: next
(default, as-is), next-even, next-odd
I briefly scanned through the code and it seems that adding support for this
requires changes in both, the release-manager and the release-plugin.
If this feature gets accepted and if someone could give me some minor hints
how/where to add this I could come up with a patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-406) skip is ignored
[
https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326954#comment-326954
]
Peter Kahn commented on MDEP-406:
-
I think it is this as I too have this problem. The skip setting in the
configuration for at least the copy-dependencies mojo doesn't appear to work
properly. I would expect the skip xml below to skip the execution, but it does
not.
h2. Goal
Conditionally execute copy-dependencies for specific modules in my project.
h2. Approach
* Top level pom defines copy-dependency execution using property
*skipIncludeCompileDeps* to control execution
* Top level pom sets *skipIncludeCompileDeps* to true
* Child poms will automatically skip execution unless they override property
definition
h2. Root Pom
{code}
properties
skipIncludeCompileDepstrue/skipIncludeCompileDeps
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idROOT POM: Gather Compile Dependencies For Scan/id
phasevalidate/phase
goals
goalcopy-dependencies/goal
/goals
configuration
skiptrue/skip
includeScopecompile/includeScope
outputDirectory${project.build.directory}/compileScopeDependencies/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
{code}
h2. Module Using common execution to gather deps
{code}
...
properties
skipIncludeCompileDepsfalse/skipIncludeCompileDeps
/properties{code}
skip is ignored
---
Key: MDEP-406
URL: https://jira.codehaus.org/browse/MDEP-406
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.7
Environment: Maven 3.0.4, Dependency Plugin 2.7
Reporter: H.-C. Gürsoy
I've a build there I've to skip dependency resolution.
According to the 2.7 documentation, using the skip parameter should prevent
from running the whole plugin execution.
Call mvn with -Dmdep.skip=true or setting skip to true in the plugin
configuration with
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.7/version
configuration
skiptrue/skip
/configuration
/plugin
{code}
is allways ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-406) skip is ignored
[
https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326955#comment-326955
]
Peter Kahn commented on MDEP-406:
-
Actually, this works for me. I checked my effective pom and found I used
version 2.4 which didn't yet support the feature.
Thanks and apologies for the churn
skip is ignored
---
Key: MDEP-406
URL: https://jira.codehaus.org/browse/MDEP-406
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.7
Environment: Maven 3.0.4, Dependency Plugin 2.7
Reporter: H.-C. Gürsoy
I've a build there I've to skip dependency resolution.
According to the 2.7 documentation, using the skip parameter should prevent
from running the whole plugin execution.
Call mvn with -Dmdep.skip=true or setting skip to true in the plugin
configuration with
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.7/version
configuration
skiptrue/skip
/configuration
/plugin
{code}
is allways ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326956#comment-326956 ] Robert Munteanu commented on MRELEASE-431: -- Right, so I'll create a VersionPolicyManager interface, and I can look it up based on the configured versionPolicy parameter. What I'm not sure is how to actually provide and look up implementations for this interface, since I'm not familiar with Maven component wiring. Where can I find the docs or a working example? And for now I can add a release-api project to the release reactor, and you can decide whether to move it to a shared component later, since it would be more difficult for me, not being a Maven committer. WDYT? Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[
https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326957#comment-326957
]
Robert Scholte commented on MRELEASE-431:
-
There are at least two options:
- through Plexus Components ( example is [Maven Compiler
Plugin|http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#420]
where you can choose a compiler by its id. Implementations are marked as a
Component and can be chosen by the hint.
- through Plexus Configuration. I couldn't find a good example, but it should
be something like this:
{code:xml}
configuration
versionPolicyManager
implementation=com.acme.custom.MyVersionPolicyManager
/versionPolicyManager
/configuration
{code}
The advantage of the latter is that it is very straightforward if you want to
use additional fields/setters on your VersionPolicyManager. For that reason
this would be my choice right now.
Configuration of policy for calculating next (release) version
--
Key: MRELEASE-431
URL: https://jira.codehaus.org/browse/MRELEASE-431
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Components: prepare
Affects Versions: 2.0-beta-8
Reporter: Carsten Ziegeler
Attachments:
0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch
Currently, when preparing the release, the version to release is always the
next version which usually is the current version without the snapshot
extension.
There are quiet a lot projects (Apache Felix, Sling and others) following an
even release numbering policy. So while the current development version is
odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4.
It would be nice if this could be made configuration through some
configuration property like
versionPolicynext-even/versionPolicy (with possible values being: next
(default, as-is), next-even, next-odd
I briefly scanned through the code and it seems that adding support for this
requires changes in both, the release-manager and the release-plugin.
If this feature gets accepted and if someone could give me some minor hints
how/where to add this I could come up with a patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-237) JavaDoc WARNING on generated HelpMojo class.
[
https://jira.codehaus.org/browse/MPLUGIN-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326959#comment-326959
]
SebbASF commented on MPLUGIN-237:
-
Agreed; the @author and @version fields could be dropped.
Alternatively, they could be used to document the name and version of the
plugin that creates the file ...
JavaDoc WARNING on generated HelpMojo class.
Key: MPLUGIN-237
URL: https://jira.codehaus.org/browse/MPLUGIN-237
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.2
Reporter: Karl Heinz Marbaise
Priority: Minor
During the site generation of a maven-plugin i got the following warning in
the builds:
{code}
2 warnings
[WARNING] Javadoc Warnings
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @author tag has no
arguments.
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @version tag has no
arguments.
[INFO] Generating Test JavaDocs report--- maven-javadoc-plugin:2.9
{code}
The question is: Can this be automatically be generated by the
maven-plugin-plugin from the original Mojo Class to avoid this WARNING?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-245) @Parameter property names are not written to the plugin-help.xml file
SebbASF created MPLUGIN-245: --- Summary: @Parameter property names are not written to the plugin-help.xml file Key: MPLUGIN-245 URL: https://jira.codehaus.org/browse/MPLUGIN-245 Project: Maven 2.x Plugin Tools Issue Type: Bug Reporter: SebbASF The generated HelpMojo fails to show user parameter names if the Mojo is generated from Java 5 annotations. This appears to be because the plugin-help.xml file does not include the information. HelpMojo.java is expecting to find an expression tag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
