[jira] [Created] (MNGSITE-288) Different paragraphs in relocation guide use same anchor
Stevo Slavic created MNGSITE-288: Summary: Different paragraphs in relocation guide use same anchor Key: MNGSITE-288 URL: https://issues.apache.org/jira/browse/MNGSITE-288 Project: Maven Project Web Site Issue Type: Bug Reporter: Stevo Slavic Priority: Trivial https://maven.apache.org/guides/mini/guide-relocation.html page has multiple paragraphs named "Releasing the next version" and they all use same anchor. This makes referencing particular paragraph bit more complicated than necessary (e.g. see https://github.com/rest-assured/rest-assured/issues/703 ) Please consider making the anchors unique on relocation guide page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPOM-64) Change maven-source-goal from jar to jar-no-fork
[ https://issues.apache.org/jira/browse/MPOM-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388207#comment-14388207 ] Stevo Slavic commented on MPOM-64: -- Are there plans to release this any time soon? Change maven-source-goal from jar to jar-no-fork Key: MPOM-64 URL: https://issues.apache.org/jira/browse/MPOM-64 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-16 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: ASF-17 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (SUREFIRE-1027) Running test console report appears only when test is finished
[ https://jira.codehaus.org/browse/SUREFIRE-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed SUREFIRE-1027. -- Resolution: Not A Bug Test classes were run in parallel with forkCount 1. Solution to get orderly console report on running tests was to remove parallel=classes setting from m-surefire-p configuration. Running test console report appears only when test is finished -- Key: SUREFIRE-1027 URL: https://jira.codehaus.org/browse/SUREFIRE-1027 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.16 Reporter: Stevo Slavic When running a JUnit test whose execution takes long time, one can notice that surefire as of 2.16 no longer reports which test has started running as soon as it starts running; only when that test execution completes both Running ... and Tests run ... now get printed on console at the same time even though a test execution took considerable time. Because of this one no longer can by looking at console log see which tests were running in parallel. -- 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] (SUREFIRE-1027) Running test console report appears only when test is finished
Stevo Slavic created SUREFIRE-1027: -- Summary: Running test console report appears only when test is finished Key: SUREFIRE-1027 URL: https://jira.codehaus.org/browse/SUREFIRE-1027 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.16 Reporter: Stevo Slavic When running a JUnit test whose execution takes long time, one can notice that surefire as of 2.16 no longer reports which test has started running as soon as it starts running; only when that test execution completes both Running ... and Tests run ... now get printed on console at the same time even though a test execution took considerable time. Because of this one no longer can by looking at console log see which tests were running in parallel. -- 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] (SUREFIRE-1013) Fix typo, forkCount instead of forkMode on fork options examples page
[
https://jira.codehaus.org/browse/SUREFIRE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=328215#comment-328215
]
Stevo Slavic commented on SUREFIRE-1013:
Thank you [~agudian] for quick fix!
Fix typo, forkCount instead of forkMode on fork options examples page
-
Key: SUREFIRE-1013
URL: https://jira.codehaus.org/browse/SUREFIRE-1013
Project: Maven Surefire
Issue Type: Task
Components: documentation
Affects Versions: 2.15
Reporter: Stevo Slavic
Assignee: Andreas Gudian
Priority: Trivial
Fix For: 2.16
In paragraph
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Forked_Test_Execution
there is sentence:
{noformat}
forkMode=1/reuseForks=false executes each test class in its own JVM process,
one after another.
{noformat}
Instead it should be
{noformat}
forkCount=1/reuseForks=false executes each test class in its own JVM process,
one after another.
{noformat}
--
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] (SUREFIRE-1013) Fix typo, forkCount instead of forkMode on fork options examples page
Stevo Slavic created SUREFIRE-1013:
--
Summary: Fix typo, forkCount instead of forkMode on fork options
examples page
Key: SUREFIRE-1013
URL: https://jira.codehaus.org/browse/SUREFIRE-1013
Project: Maven Surefire
Issue Type: Task
Components: documentation
Affects Versions: 2.15
Reporter: Stevo Slavic
Priority: Trivial
In paragraph
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Forked_Test_Execution
there is sentence:
{noformat}
forkMode=1/reuseForks=false executes each test class in its own JVM process,
one after another.
{noformat}
Instead it should be
{noformat}
forkCount=1/reuseForks=false executes each test class in its own JVM process,
one after another.
{noformat}
--
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
]
Stevo Slavic updated MPOM-44:
-
Attachment: MPOM-44-extended.patch
Attaching [^MPOM-44-extended.patch], an extended and more complete variant of
the fix which changes both Apache parent POM and Maven parent POM.
Patch also includes version bump to latest ones of all the plugins which are
managed/used throughout Apache and Maven POMs, and a touch of DRYness as well.
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-extended.patch, 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] [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
]
Stevo Slavic updated MPOM-44:
-
Attachment: (was: MPOM-44-extended.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] [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
]
Stevo Slavic updated MPOM-44:
-
Attachment: MPOM-44-extended.patch
Attaching modified [^MPOM-44-extended.patch] which uses {{maven.compiler...}}
instead of {{maven.compile...}}
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-extended.patch, 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] (MPMD-170) Have targetJdk default to maven.compiler.target
Stevo Slavic created MPMD-170:
-
Summary: Have targetJdk default to maven.compiler.target
Key: MPMD-170
URL: https://jira.codehaus.org/browse/MPMD-170
Project: Maven 2.x PMD Plugin
Issue Type: Improvement
Components: PMD
Affects Versions: 3.0.1
Reporter: Stevo Slavic
Priority: Minor
Attachments: MPMD-170.patch
Currently {{targetJdk}} has to be defined separately from
{{maven.compiler.target}} property that most plugins already default to, so
target JDK information is unnecessarily repeated, making POMs with
maven-pmd-plugin less DRY, harder to maintain, prone to mistakes and unwanted
behavior.
So, please make {{targetJdk}} default to {{maven.compiler.target}} property.
Attached is [^MPMD-170.patch] which adds this behavior.
--
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] (MPMD-170) Have targetJdk default to maven.compiler.target
[
https://jira.codehaus.org/browse/MPMD-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327575#comment-327575
]
Stevo Slavic commented on MPMD-170:
---
Thanks [~rfscholte], I appreciate your quick review and feedback.
It would help even more if you could also provide some reference to docs or
existing code which does something like that proper solution you mentioned.
To run a report like pmd, which analyzes sources, compiler execution is not
needed. Which maven-compiler-plugin execution configuration of potentially more
than one configured should we read?
Have targetJdk default to maven.compiler.target
---
Key: MPMD-170
URL: https://jira.codehaus.org/browse/MPMD-170
Project: Maven 2.x PMD Plugin
Issue Type: Improvement
Components: PMD
Affects Versions: 3.0.1
Reporter: Stevo Slavic
Priority: Minor
Attachments: MPMD-170.patch
Currently {{targetJdk}} has to be defined separately from
{{maven.compiler.target}} property that most plugins already default to, so
target JDK information is unnecessarily repeated, making POMs with
maven-pmd-plugin less DRY, harder to maintain, prone to mistakes and unwanted
behavior.
So, please make {{targetJdk}} default to {{maven.compiler.target}} property.
Attached is [^MPMD-170.patch] which adds this behavior.
--
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-768) Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses
Stevo Slavic created MRELEASE-768: - Summary: Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses Key: MRELEASE-768 URL: https://jira.codehaus.org/browse/MRELEASE-768 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Environment: maven 3.0.4 jdk 1.6 x64 update 32 Reporter: Stevo Slavic Priority: Minor P |--W (+A) |--J (depends on A) P is parent and aggregator module with two child modules W (war) and J (jar). W module has maven-war-plugin:2.2 configured to [attachClasses|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses] resulting in additional artifact A with Ws classes attached to the build. A is declared as (provided) dependency of J. Problem is that P cannot be release prepared - snapshot dependencies check fails for J module on A dependency. It seems that maven release plugin isn't aware that the W will also produce A artifact. -- 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-768) Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses
[ https://jira.codehaus.org/browse/MRELEASE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MRELEASE-768. - Resolution: Not A Bug Not a bug, works ok - just reference to A dependency was wrong. Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses Key: MRELEASE-768 URL: https://jira.codehaus.org/browse/MRELEASE-768 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Environment: maven 3.0.4 jdk 1.6 x64 update 32 Reporter: Stevo Slavic Priority: Minor P |--W (+A) |--J (depends on A) P is parent and aggregator module with two child modules W (war) and J (jar). W module has maven-war-plugin:2.2 configured to [attachClasses|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses] resulting in additional artifact A with Ws classes attached to the build. A is declared as (provided) dependency of J. Problem is that P cannot be release prepared - snapshot dependencies check fails for J module on A dependency. It seems that maven release plugin isn't aware that the W will also produce A artifact. -- 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] [Created] (MPOM-36) Declare maven-dependency-plugin in pluginManagement
Stevo Slavic created MPOM-36: Summary: Declare maven-dependency-plugin in pluginManagement Key: MPOM-36 URL: https://issues.apache.org/jira/browse/MPOM-36 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-10 Reporter: Stevo Slavic Priority: Minor [Apache v10 pom|http://repo1.maven.org/maven2/org/apache/apache/10/apache-10.pom] declares common plugins and their versions in pluginManagement for reproducibility, but not [maven-dependency-plugin|http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-36) Declare maven-dependency-plugin in pluginManagement
[ https://issues.apache.org/jira/browse/MPOM-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated MPOM-36: - Attachment: MPOM-36.patch Attaching patch [^MPOM-36.patch] which fixes this issue. Declare maven-dependency-plugin in pluginManagement --- Key: MPOM-36 URL: https://issues.apache.org/jira/browse/MPOM-36 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-10 Reporter: Stevo Slavic Priority: Minor Attachments: MPOM-36.patch [Apache v10 pom|http://repo1.maven.org/maven2/org/apache/apache/10/apache-10.pom] declares common plugins and their versions in pluginManagement for reproducibility, but not [maven-dependency-plugin|http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MPOM-37) Enable wiki renderer for MPOM JIRA project
Stevo Slavic created MPOM-37: Summary: Enable wiki renderer for MPOM JIRA project Key: MPOM-37 URL: https://issues.apache.org/jira/browse/MPOM-37 Project: Maven POMs Issue Type: Improvement Reporter: Stevo Slavic Priority: Minor Please enable wiki renderer for MPOM JIRA project as that would help to write nicer and more expressive issue descriptions and comments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4752) scopeendorsed/scope
[
https://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=293135#comment-293135
]
Stevo Slavic commented on MNG-4752:
---
Spotted some workarounds like
[this|http://www.mindbug.org/2009/02/adding-endorsements-to-mavens-plugins.html]
where combination of maven-dependency-plugin:copy and maven-compiler-plugin
are used to copy endorsed artifacts in target/endorsed, and configure compiler
to use that dir as endorsed libs dir.
Native support for endorsed scope is preferred - compared to native support,
workaround is ugly, and it's even uglier if one is using Eclipse IDE and m2e.
scopeendorsed/scope
---
Key: MNG-4752
URL: https://jira.codehaus.org/browse/MNG-4752
Project: Maven 2 3
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.2.1
Environment: An issue in 2.2.1 but I think the same issue applies
also to 3.0.
Reporter: Jesse Glick
Fix For: Issues to be reviewed for 3.x
There appears to be no official way to request usage of a particular Java
library (such as a new release of JAXB) using the Java endorsed mechanism.
The semantics would be very similar to provided scope except that the library
is expected to override the JRE's boot classpath, both at compile time (main
or test) and runtime ({{exec:exec}} and Surefire).
As investigated in https://netbeans.org/bugzilla/show_bug.cgi?id=185139#c8
there are various ways you can get this functionality to work in current
Maven releases if you Google long enough, but all seem hackish. Prepending
arguments to the bootclasspath directly is generally discouraged.
Manually configuring {{-endorseddirs}} (for {{javac}}) or
{{-Djava.endorsed.dirs}} (for {{java}} incl. Surefire) seems to work, but you
have to first download the endorsed libraries into some subdirectory of
target, where they could consume considerable disk space.
You could fix the disk space issue by passing dirs in the local repository,
but this requires hardcoding details of the {{~/.m2/repository/}} structure
in the POM which is very ugly, and also means duplicating information about
{{groupId}}, {{artifactId}}, and {{version}} (you still need to have
artifacts declared elsewhere so they will get downloaded if not initially
present).
Anyway all these tricks obscure the relatively simple intent of the
developer, which is to use a given artifact in the project in preference to
any equivalent in the current JRE. It is important to have a standardized way
of declaring such dependencies, not just to make it easy to write and
maintain {{pom.xml}}, but so that IDEs and other tools know what you intend
to do and can (for example) offer appropriate code completion without reverse
engineering various idioms.
Much preferable would be to simply declare these dependencies in the normal
POM section, but with {{scopeendorsed/scope}}. Then
{{maven-compiler-plugin}}, {{maven-exec-plugin}}, {{maven-surefire-plugin}},
etc. would need to be modified to understand these dependencies and use them
appropriately when calling JDK tools. Plugin code could be smart enough to
work optimally in the available environment; for example, if an artifact has
only a single JAR in the local repository (no extra classifiers), the
containing directory could be passed directly to JDK tools as an endorsed
dir, but in other cases a {{target/endorsed}} dir could be generated and used
instead.
One concern is that the notion of an endorsed library is quite specific to
the JVM; Maven projects targeted at other platforms would presumably have no
use for this scope. Perhaps this is not an issue.
--
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] Commented: (MRELEASE-577) release:prepare does not pass argument --settings with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283134#comment-283134 ] Stevo Slavic commented on MRELEASE-577: --- Isn't [arguments|http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#arguments] meant for passing arguments to inner Maven executions? release:prepare does not pass argument --settings with current settings.xml to inner maven Key: MRELEASE-577 URL: https://jira.codehaus.org/browse/MRELEASE-577 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9, 2.0 Reporter: Petr Kozelka Priority: Critical Labels: contributers-welcome Fix For: Backlog The impact is that release:prepare tries to use $HOME/.m2/settings.xml instead of the one supplied by --settings cmdline option, which leads to unexpected behavior Of course if it does not exist, the inhouse repository is avoided and release often fails due to a ResourceDoesNotExistException when an inhouse artifact is requested by the pom. To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml and run this: mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280566#comment-280566
]
Stevo Slavic commented on MDEP-98:
--
I've reproduced this using attached surefire test case. [1] is relevant build
log with error when running just {{mvn site}}.
With this command one runs {{site}} phase of {{site}} lifecycle to which by
default {{maven-site-plugin}} {{site} goal is bound to. Site plugin site goal
runs {{test}} phase of default lifecycle. {{package}} phase, to which assembly
of jar module zip archive with bin classifier is bound, will not be triggered
by this test phase execution, but {{process-resources}} in war module, to which
unpacking of that bin/zip is bound, will be triggered. IMO it's wrong that
dependency plugin manages to resolve jar module from reactor - it should try to
resolve one with bin classifier (and not main jar module), and in that case I'd
expect build to fail with missing dependency reported since jar module with bin
classifier creation has not been triggered and thus it's not attached to the
build.
It's strange to me also that if you run mvn package as one build, and then
mvn site as separate build that dependency plugin in site build will be
able to resolve jar module bin classifier artifact and unpack it even though
it's not installed on any repository nor is it in reactor of site build.
Looks like a bug too, again related to resolving dependencies.
[1] build log
{noformat}
[INFO]
[INFO] Building MDEP-98 test case - WAR 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-site-plugin:3.0:site (default-site) @ mdep98-testcase-web ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:2.4
[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:2.10
[INFO]
[INFO] maven-surefire-report-plugin:2.10:report-only (report:report-only) @
mdep98-testcase-web
[INFO]
[INFO] maven-surefire-report-plugin:2.10:report-only (report:report-only) @
mdep98-testcase-web
[INFO]
[INFO] maven-surefire-report-plugin:2.10:report (report:report) @
mdep98-testcase-web
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
mdep98-testcase-web ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web
---
[INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
[INFO] Unpacking
D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-jar\target\classes to
D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-web\target\mdep98-testcase-web-1.0.0-SNAPSHOT\webstart
with includes null and excludes:null
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260)
at
org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
at
org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:175
)
at
org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java:
282)
at
org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:
148)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:240)
{noformat}
The source must not be a directory
--
Key: MDEP-98
URL: https://jira.codehaus.org/browse/MDEP-98
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.0-alpha-4
Environment: Windows XP Professional SP2
Java(TM) 2
[jira] Commented: (MDEP-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280568#comment-280568
]
Stevo Slavic commented on MDEP-98:
--
In site build after package build maven-dependency-plugin reports that
classes were already unpacked:
{noformat}
[INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web
---
[INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
[INFO] classes already unpacked.
{noformat}
The source must not be a directory
--
Key: MDEP-98
URL: https://jira.codehaus.org/browse/MDEP-98
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.0-alpha-4
Environment: Windows XP Professional SP2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
Reporter: Pablo Muñiz
Assignee: Brian Fox
Attachments: MDEP-98-ITs.patch,
mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
Using maven-dependency-plugin in a multimodule project inside a module wich
has a dependency with another module in the same project the next error
ocurrs :
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error unpacking file:
c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.
Project structure is as follows:
plataforma
- platform-core
- platform-bundle
- platform-bundle-jar
- platform-bundle-src
and the error happens on executing any goal from parent pom.
maven-dependency-plugin seems to receive a reference to target/classes
directory for platform-core dependency instead of the URL to my local
repository where platform-core is located.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-98) The source must not be a directory
[ https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated MDEP-98: - Attachment: MDEP-98-ITs.patch Here's a patch [^MDEP-98-ITs.patch] with integration test for unpacking dependencies from reactor. The source must not be a directory -- Key: MDEP-98 URL: https://jira.codehaus.org/browse/MDEP-98 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack-dependencies Affects Versions: 2.0-alpha-4 Environment: Windows XP Professional SP2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) Reporter: Pablo Muñiz Assignee: Brian Fox Attachments: MDEP-98-ITs.patch Using maven-dependency-plugin in a multimodule project inside a module wich has a dependency with another module in the same project the next error ocurrs : org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232) at org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error unpacking file: c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. Project structure is as follows: plataforma - platform-core - platform-bundle - platform-bundle-jar - platform-bundle-src and the error happens on executing any goal from parent pom. maven-dependency-plugin seems to receive a reference to target/classes directory for platform-core dependency instead of the URL to my local repository where platform-core is located. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-98) The source must not be a directory
[ https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280466#comment-280466 ] Stevo Slavic commented on MDEP-98: -- ITs prove that the maven-dependency-plugin works well, as designed. This is practically m2e issue. By combining profiles and maven-resource-plugin:copy-resources I've managed to workaround this issue. In a multi-module project there is a shared resources module (SRM). Other modules which reference SRM and need it's content unpacked have two profiles, non-m2e and m2e, former activated when m2e.version property is not defined and latter activated when m2e.version property is defined. In non-m2e profile maven-dependency-plugin:unpack-dependencies unpacks SRM, while in m2e profile maven-resources-plugin:copy-resources is configured to copy shared resources from SRM. When build is run using maven on command line, m2e.version is not defined and maven-dependency-plugin will unpack SRM dependency from reactor. When build is run from eclipse using m2e, m2e.version is defined and m2e will copy resources. Removing my vote. The source must not be a directory -- Key: MDEP-98 URL: https://jira.codehaus.org/browse/MDEP-98 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack-dependencies Affects Versions: 2.0-alpha-4 Environment: Windows XP Professional SP2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) Reporter: Pablo Muñiz Assignee: Brian Fox Attachments: MDEP-98-ITs.patch Using maven-dependency-plugin in a multimodule project inside a module wich has a dependency with another module in the same project the next error ocurrs : org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232) at org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error unpacking file: c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. Project structure is as follows: plataforma - platform-core - platform-bundle - platform-bundle-jar - platform-bundle-src and the error happens on executing any goal from parent pom. maven-dependency-plugin seems to receive a reference to target/classes directory for platform-core dependency instead of the URL to my local repository where platform-core is located.
[jira] Commented: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ https://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=276892#comment-276892 ] Stevo Slavic commented on ARCHETYPE-220: Oh, there is one already, ARCHETYPE-204 Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: https://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Assignee: Olivier Lamy Priority: Minor Fix For: 2.1 Attachments: https.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ https://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=276891#comment-276891 ] Stevo Slavic commented on ARCHETYPE-220: I don't see in changes that specifying repositoryId is supported. Should separate ticket be created for support for providing credentials and/or repositoryId? Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: https://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Assignee: Olivier Lamy Priority: Minor Fix For: 2.1 Attachments: https.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-204) Add option to use remote repositories that are password protected
[
https://jira.codehaus.org/browse/ARCHETYPE-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=276893#comment-276893
]
Stevo Slavic commented on ARCHETYPE-204:
[ARCHETYPE-220 contains a
patch|https://jira.codehaus.org/secure/attachment/45804/org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch]
which adds support for specifying archetypeRepositoryId
Add option to use remote repositories that are password protected
-
Key: ARCHETYPE-204
URL: https://jira.codehaus.org/browse/ARCHETYPE-204
Project: Maven Archetype
Issue Type: Improvement
Components: Generator
Affects Versions: 2.0-alpha-3
Environment: mvn -version
Maven version: 2.0.9
Java version: 1.6.0_06
OS name: linux version: 2.6.24-19-generic arch: i386 Family: unix
Reporter: Martin Tilma
Priority: Minor
Fix For: 2.x
When the archetype's are in a password protected repository you can't
download the archetype
Command used: {noformat}mvn archetype:generate
-DarchetypeGroupId=nl.func.quickstart -DarchetypeArtifactId=quickstart
-DarchetypeVersion=1.0 -DgroupId=nl.func.test -DartifactId=apple
-DarchetypeRepository=https://maven.func.nl{noformat}
There is a archetypeRepository option, but there is no option to bind a
server id from the settings.xml.
Could this, or some other solution, be added?
My current workaround is to use scpexe instead of https.
Command used:
{noformat}mvn archetype:generate -DarchetypeGroupId=nl.func.quickstart
-DarchetypeArtifactId=quickstart -DarchetypeVersion=1.0
-DgroupId=nl.func.test -DartifactId=apple
-DarchetypeRepository=scpexe://maven.func.nl/var/sites/nl.func.maven/www/
-Darchetype.interactive=false{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-350) Proposal for making (sub-)module handling more flexible with regards to folder names
[
http://jira.codehaus.org/browse/ARCHETYPE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269881#action_269881
]
Stevo Slavic commented on ARCHETYPE-350:
Module's name in it's aggregator pom, and module directory name have to match.
Some plugins by default (if I recall well for links to work site plugin does)
additionally expect that module directory name matches module artifactId. So by
default, all 3 have to match.
Current archetype plugin (2.0) from archetype descriptor
(archetype-metadata.xml) uses module dir attribute for source directory name,
for module name in aggregator pom, and for destination directory within
aggregator module. It uses module id attribute only for artifactId variable.
IMO it should use module dir attribute only for the source directory name, and
use id attribute for module name in aggregator pom, for destination directory
name, and for artifactId variable.
I agree that module name attribute, if specified, should be used, instead of id
attribute value, as module name and destination directory name within
aggregator.
+1 for parameter (like rootArtifactId) expansion within module attributes of
archetype descriptor.
Proposal for making (sub-)module handling more flexible with regards to
folder names
Key: ARCHETYPE-350
URL: http://jira.codehaus.org/browse/ARCHETYPE-350
Project: Maven Archetype
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Marc Wirth
Attachments: module_name.patch
We have a use-case where we want modules to use the artifact ID of the parent
as prefix, but the modules folder should only use the suffix to keep
overall paths short (without becoming too redundant.)
To make configuration more flexible I've changed the implementation so that
the name of a module is used to define the output folder where the module
is created and that it is run through velocity so that arbitrary properties
can be defined. Please check the attached patch file.
For example with this patch we could use a archetype-metadata definition
like:
{code}
requiredProperty key=subArtifactId
...
module id=${rootArtifactId}.${subArtifactId} dir=__rootArtifactId__.sub
name=${subArtifactId}
{code}
to generate the module (from {{__rootArtifactId__.sub}} in the archetype-zip)
into a folder that only consists of the module name, but having the
rootArtifact ID plus the module name as its artifactId.
I don't have a testcase specifically for this, but at least it doesn't break
the existing fileset-archetype tests.
While looking through the relevant code I've tried to clean up a few other
oddities (artifactId is reset so log output would print a potentially wrong
id, what looked like a mixup of replacements in Strings with ${x} or __x__
delimiters to me).
Also,
http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
says The attributes name, id and dir of the module are used to determine
the directory where to generate that module's files, they also are used to
determine the artifactId of the Maven project corresponding to this module.
but actually the name attribute was never used during generation (only set
during creation, same value as the id). To distinguish the source location
within the archetype, i.e. the dir-attribute, from the destination I used the
name attribute to define the output directory name.
What do you think about that?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-539) Reporting plugin version references in new configuration example are wrong and misleading
[
http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268320#action_268320
]
Stevo Slavic commented on MSITE-539:
I managed to reproduce this one. When releasing corporate Maven parent project,
release:perform goal checkouts tag created with release:prepare, runs a build
with specified goals (-Dgoals=deploy) and for that inner build Maven prints out
warnings that version is not set for maven-javadoc-plugin plugin although it is
set, maven-site-plugin has reportPlugins and within it, along with other
reporting plugins is maven-javadoc-plugin with version 2.8 set.
Environment:
- Maven 3.0.3,
- Java 1.6 update 24 x64,
- Windows 7 x64,
- maven-release-plugin 2.1
- maven-site-plugin 3.0-beta-3
Build output follows:
{noformat}
D:\foo\foo.bar.maven.parentmvn release:perform -s settings.xml -Dgoals=deploy
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Foo Maven Parent 14-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.1:perform (default-cli) @
foo.bar.maven.parent ---
[INFO] Checking out the project to perform the release ...
[INFO] Executing: cmd.exe /X /C svn --non-interactive checkout
https://svn.foo.bar/foo-repo/parent
/tags/releases/foo.bar.maven.parent-13
D:\foo\foo.bar.maven.parent\target\checkout
[INFO] Working directory: D:\foo\foo.bar.maven.parent\target
[INFO] Executing goals 'deploy'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker inst
ance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for foo.bar.maven:foo.bar.maven.p
arent:pom:13
[INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing.
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[INFO] [WARNING]
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] Building Foo Maven Parent 13
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-versions) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent
[INFO] [INFO]
[INFO] [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-versions) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent
[INFO] [INFO]
[INFO] [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @
foo.bar.maven.parent ---
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO]
[INFO] [INFO] --- maven-site-plugin:3.0-beta-3:attach-descriptor
(attach-descriptor) @ foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
foo.bar.maven.parent ---
[INFO] [INFO] Installing D:\foo\foo.bar.maven.parent\target\checkout\pom.xml to
C:\Users\s.slavic\
.m2\repository\foo\bar\maven\foo.bar.maven.parent\13\foo.bar.maven.parent-13.pom
[INFO] [INFO] Installing
D:\foo\foo.bar.maven.parent\target\checkout\target\foo.bar.maven.parent
-13-site.xml to
C:\Users\s.slavic\.m2\repository\foo\bar\maven\foo.bar.maven.parent\13\foo.bar.maven.parent-13-sit
e.xml
[INFO] [INFO]
[INFO] [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @
foo.bar.maven.parent ---
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/13/foo.bar.maven.parent-13.pom
[INFO] 4 KB
[INFO] 8 KB
[INFO] 12 KB
[INFO] 14 KB
[INFO]
[INFO] Uploaded:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.parent
/13/foo.bar.maven.parent-13.pom (14 KB at 5.0 KB/sec)
[INFO] Downloading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.par
ent/maven-metadata.xml
[INFO]
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/maven-metadata.xml
[INFO] 311 B
[INFO]
[INFO] Uploaded:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.parent
/maven-metadata.xml (311 B at 1.2 KB/sec)
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/13/foo.bar.maven.parent-13-site.xml
[INFO] 751 B
[INFO]
[INFO] Uploaded:
[jira] Created: (MNG-5093) Concurrency issue in plugin version resolution
Concurrency issue in plugin version resolution
--
Key: MNG-5093
URL: http://jira.codehaus.org/browse/MNG-5093
Project: Maven 2 3
Issue Type: Bug
Components: Errors
Affects Versions: 3.0.3
Environment: Java 1.6 update 24, x64
Windows 7 x64
Reporter: Stevo Slavic
Issue initially posted on aether-user mailing list in topic Aether, plugin
maven-metadata.xml, and server authentication from today (May 13th 2011).
Unfortunatelly I couldn't find mailing list archive to post a reference.
I tried to build {{https://github.com/SpringSource/spring-data-commons}} from
environment configured to use a mirror of central repository which requires
authentication. POMs in the project configure executions of
maven-compiler-plugin, maven-sources-plugin, and maven-surefire-plugin but
without specifying version of these plugins. Mavan build prints warnings that
plugin versions should be set, but continues only to fail with [1]. Because
{{AuthorizationException}} is reported I thought it was authentication issue.
Then I checked-out aether 1.11 (Maven 3.0.3 uses it) and debugged. I placed a
breakpoint in {{WagonRepositoryConnector}}, in get method, within loop over
metadataDownloads. When build starts, and plugins (metadata) are about to be
resolved, 3 threads appear paused in debugger - it seems Maven starts them, one
for each plugin repository (2 configured in pom and third is central) to
download plugin metadata in parallel from the repositories. If I let just one
thread at a time to continue plugin maven-metadata.xml file gets downloaded
from mirror-of-central and build is successful (so it's not
security/authentication/credentials issue).
Then Benjamin Bentmann suggested that I try setting
aether.metadataResolver.threads=1. After that, resolving metadata and plugins
passes well, which made me conclude this is concurrency issue. Setting
aether.metadataResolver.threads=2 build also passes. For
aether.metadataResolver.threads=3 build fails. From
https://issues.sonatype.org/browse/AETHER-26 it seems default is 4 threads in
pool.
When testing before build I first delete org/apache/maven/plugins directory in
local repo to force version resolving from remote repo to reproduce the bug.
When build fails in local repo in org/apache/maven/plugins/maven-comiler-plugin
only {{resolver-status.properties}} file is available.
On Benjamins suggestion I also tried using asynchttp connector and it worked
well.
[1] Maven build error stack trace
{code}
c:\Users\s.slavic\spring-data-commonsmvn clean verify -U -X
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: d:\java\maven\apache-maven-3.0.3\bin\..
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: d:\java\jdk\jdk1.6.0_24-x64\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
[INFO] Error stacktraces are turned on.
[DEBUG] Reading global settings from
d:\java\maven\apache-maven-3.0.3\bin\..\conf\settings.xml
[DEBUG] Reading user settings from C:\Users\s.slavic\.m2\settings.xml
[DEBUG] Using local repository at C:\Users\s.slavic\.m2\repository
[DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
C:\Users\s.slavic\.m2\repository
[INFO] Scanning for projects...
[DEBUG]
org.springframework.build.aws:org.springframework.build.aws.maven:jar:3.1.0.RELEASE:
[DEBUG]commons-httpclient:commons-httpclient:jar:3.1:compile
[DEBUG] commons-logging:commons-logging:jar:1.0.4:compile
[DEBUG] commons-codec:commons-codec:jar:1.2:compile
[DEBUG]net.java.dev.jets3t:jets3t:jar:0.8.0:compile
[DEBUG] com.jamesmurty.utils:java-xmlbuilder:jar:0.4:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
[DEBUG] Created new class realm maven.api
[DEBUG] Importing foreign packages into class realm maven.api
[DEBUG] Imported: org.apache.maven.wagon.events plexus.core
[DEBUG] Imported: org.sonatype.aether.transfer plexus.core
[DEBUG] Imported: org.apache.maven.exception plexus.core
[DEBUG] Imported: org.sonatype.aether.metadata plexus.core
[DEBUG] Imported: org.codehaus.plexus.util.xml.Xpp3Dom plexus.core
[DEBUG] Imported: org.sonatype.aether.collection plexus.core
[DEBUG] Imported: org.sonatype.aether.version plexus.core
[DEBUG] Imported: org.apache.maven.monitor plexus.core
[DEBUG] Imported: org.apache.maven.wagon.repository plexus.core
[DEBUG] Imported: org.apache.maven.repository plexus.core
[DEBUG] Imported: org.apache.maven.wagon.resource plexus.core
[DEBUG] Imported: org.codehaus.plexus.logging plexus.core
[DEBUG] Imported: org.apache.maven.profiles plexus.core
[DEBUG] Imported: org.sonatype.aether.repository plexus.core
[DEBUG] Imported: org.apache.maven.classrealm plexus.core
[DEBUG] Imported: org.apache.maven.execution plexus.core
[DEBUG]
[jira] Commented: (MSITE-539) Reporting plugin version references in new configuration example are wrong and misleading
[ http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262778#action_262778 ] Stevo Slavic commented on MSITE-539: Yes, I found example there misleading, version element for every reporting plugin listed under reportPlugins was not respected - if I remember well, if reporting plugins were only defined in reportingPlugins Maven 3 would report that it's not good practice that reporting plugin version is not specified. Only by specifying reporting plugins in pluginManagement I was able to configure required version, and have Maven not complain about bad practice. After specifying version of reporting plugins in pluginManagement section, I could, and now typically do remove version of plugins in reportPlugins section. Reporting plugin version references in new configuration example are wrong and misleading - Key: MSITE-539 URL: http://jira.codehaus.org/browse/MSITE-539 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0-beta-3 Reporter: Stevo Slavic Priority: Minor [New configuration example|http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html#New_Configuration] shows invalid reference to maven-javadoc-plugin version - version info there won't break a build but it is simply not used by Maven 3 or site plugin (maven reports that version info is not available for such reporting plugin). Such wrong example might mislead users that this is expected way of specifying version of reporting plugin used within maven site plugin configuration. Example following new configuration example, related to version resolution, is valid, it specifies reporting plugin version info in pluginManagement section. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-539) Reporting plugin version references in new configuration example are wrong and misleading
[ http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262778#action_262778 ] Stevo Slavic edited comment on MSITE-539 at 4/7/11 4:28 AM: Yes, I found example there misleading, version element for every reporting plugin listed under reportPlugins was not respected - if I remember well, if reporting plugins were only defined in reportingPlugins Maven 3 would report that it's not good practice that reporting plugin version is not specified, even though version was specified as in example. Only by specifying reporting plugins in pluginManagement I was able to configure required version, and have Maven not complain about bad practice. After specifying version of reporting plugins in pluginManagement section, I could, and now typically do remove version of plugins in reportPlugins section. was (Author: sslavic): Yes, I found example there misleading, version element for every reporting plugin listed under reportPlugins was not respected - if I remember well, if reporting plugins were only defined in reportingPlugins Maven 3 would report that it's not good practice that reporting plugin version is not specified. Only by specifying reporting plugins in pluginManagement I was able to configure required version, and have Maven not complain about bad practice. After specifying version of reporting plugins in pluginManagement section, I could, and now typically do remove version of plugins in reportPlugins section. Reporting plugin version references in new configuration example are wrong and misleading - Key: MSITE-539 URL: http://jira.codehaus.org/browse/MSITE-539 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0-beta-3 Reporter: Stevo Slavic Priority: Minor [New configuration example|http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html#New_Configuration] shows invalid reference to maven-javadoc-plugin version - version info there won't break a build but it is simply not used by Maven 3 or site plugin (maven reports that version info is not available for such reporting plugin). Such wrong example might mislead users that this is expected way of specifying version of reporting plugin used within maven site plugin configuration. Example following new configuration example, related to version resolution, is valid, it specifies reporting plugin version info in pluginManagement section. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-539) Reporting plugin version references in new configuration example are wrong and misleading
[ http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262784#action_262784 ] Stevo Slavic commented on MSITE-539: Can not reproduce this anymore. Reporting plugin version references in new configuration example are wrong and misleading - Key: MSITE-539 URL: http://jira.codehaus.org/browse/MSITE-539 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0-beta-3 Reporter: Stevo Slavic Priority: Minor Attachments: MSITE-539.zip [New configuration example|http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html#New_Configuration] shows invalid reference to maven-javadoc-plugin version - version info there won't break a build but it is simply not used by Maven 3 or site plugin (maven reports that version info is not available for such reporting plugin). Such wrong example might mislead users that this is expected way of specifying version of reporting plugin used within maven site plugin configuration. Example following new configuration example, related to version resolution, is valid, it specifies reporting plugin version info in pluginManagement section. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-366) Provide pure-java svn implementation
[ http://jira.codehaus.org/browse/SCM-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262235#action_262235 ] Stevo Slavic commented on SCM-366: -- New home at: http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/ Provide pure-java svn implementation Key: SCM-366 URL: http://jira.codehaus.org/browse/SCM-366 Project: Maven SCM Issue Type: Wish Components: maven-scm-provider-svn Affects Versions: 1.2 Reporter: Florian Kirchmeir Assignee: Olivier Lamy Priority: Minor Please remove the dependency on the svn.exe command-line executable! See http://jira.codehaus.org/browse/SCM-13: The issue has been closed as FIXED, but the maven-scm-provider-svnjava module appearently has never been comitted. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4583) warning printed when a pom does not use an activated profile is poorly worded and also should not be printed for multi-module builds
[ http://jira.codehaus.org/browse/MNG-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=258513#action_258513 ] Stevo Slavic commented on MNG-4583: --- Are there any means to configure Maven not to print this warning? In my case a multi-module project uses activated profile only in a single module. If this is not supported, maybe support could be added, e.g. to allow one to specify profile names for which this warning should not be printed. warning printed when a pom does not use an activated profile is poorly worded and also should not be printed for multi-module builds Key: MNG-4583 URL: http://jira.codehaus.org/browse/MNG-4583 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.0.11, 2.2.1, 3.0-alpha-6 Reporter: Ian Springer Assignee: Benjamin Bentmann Priority: Minor Fix For: 3.0-alpha-6 Attachments: MNG-4583.zip This is a followup to http://jira.codehaus.org/browse/MNG-3641. Refer to that issue for the background. The current warning message is: Profile with id: ' + explicitProfileId + ' has not been activated. I think this message is misleading, because the profile actually is activated - it's just not used at all in the pom being processed. I suggest changing the message to something like: Profile with id ' + explicitProfileId + ' is activated, but this pom does not contain any usages of the profile. Also, I don't think it makes sense to print this warning at all in a multi-module build. In the large multi-module project I work on, we have a number of profiles that are only used in a handful of the 50 or so modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4583) warning printed when a pom does not use an activated profile is poorly worded and also should not be printed for multi-module builds
[ http://jira.codehaus.org/browse/MNG-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=258517#action_258517 ] Stevo Slavic commented on MNG-4583: --- It seems this is m2eclipse issue - checked, it doesn't get printed in CLI, only in eclipse for incremental builds. warning printed when a pom does not use an activated profile is poorly worded and also should not be printed for multi-module builds Key: MNG-4583 URL: http://jira.codehaus.org/browse/MNG-4583 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.0.11, 2.2.1, 3.0-alpha-6 Reporter: Ian Springer Assignee: Benjamin Bentmann Priority: Minor Fix For: 3.0-alpha-6 Attachments: MNG-4583.zip This is a followup to http://jira.codehaus.org/browse/MNG-3641. Refer to that issue for the background. The current warning message is: Profile with id: ' + explicitProfileId + ' has not been activated. I think this message is misleading, because the profile actually is activated - it's just not used at all in the pom being processed. I suggest changing the message to something like: Profile with id ' + explicitProfileId + ' is activated, but this pom does not contain any usages of the profile. Also, I don't think it makes sense to print this warning at all in a multi-module build. In the large multi-module project I work on, we have a number of profiles that are only used in a handful of the 50 or so modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-334) Can not generated class-path from Manifest
[
http://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252957#action_252957
]
Stevo Slavic commented on MASSEMBLY-334:
As temporary workaround I'm using maven-war-plugin manifest goal to create
manifest file for assemblies - nasty but works for me for now.
Can not generated class-path from Manifest
--
Key: MASSEMBLY-334
URL: http://jira.codehaus.org/browse/MASSEMBLY-334
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Pc - Windows XP sp2
Reporter: Damien
I have a maven's projet multi-module.
I have a problem when i launch mvn package assembly:assembly
In the Manifest file, the class path does not generated.
Pom project
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.ipsis.pacha/groupId
artifactIdPacha/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
namePACHA/name
build
plugins
plugin
!-- Tache permettant d'afficher le classpath
utilisé lors de l'execution de maven. --
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idprint-maven-runtime-classpath/id
phasecompile/phase
configuration
tasks
property
name=runtime-classpath
refid=maven.runtime.classpath /
echo
message=maven.runtime.classpath=${runtime-classpath} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
execution
idprint-maven-test-classpath/id
phasetest-compile/phase
configuration
tasks
property
name=test-classpath
refid=maven.test.classpath /
echo
message=maven.test.classpath=${test-classpath} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
plugin
!-- Version du compilateur et de la JVM cible
pour l'execution de l'application --
artifactIdmaven-compiler-plugin/artifactId
configuration
!-- On reste en 1.6. --
source1.6/source
target1.6/target
meminitial512m/meminitial
maxmem1024m/maxmem
optimizetrue/optimize
verbosetrue/verbose
forktrue/fork
executable${JAVA_HOME}\bin\javac.exe/executable
compilerVersion1.6/compilerVersion
/configuration
dependencies /
/plugin
!-- Deploiement --
plugin
[jira] Commented: (MASSEMBLY-334) Can not generated class-path from Manifest
[
http://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252566#action_252566
]
Stevo Slavic commented on MASSEMBLY-334:
Just got hit by this. I'm using maven-assembly-plugin 2.2; addClasspath archive
setting doesn't seem to influence (jar format) assembly archive manifest
creation. For maven-jar-plugin 2.3.1 it works.
Debugged a bit. In MavenArchiver, getManifest method,
getRuntimeClasspathElements call returns only project build output directory
but not dependencies.
Can not generated class-path from Manifest
--
Key: MASSEMBLY-334
URL: http://jira.codehaus.org/browse/MASSEMBLY-334
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Pc - Windows XP sp2
Reporter: Damien
I have a maven's projet multi-module.
I have a problem when i launch mvn package assembly:assembly
In the Manifest file, the class path does not generated.
Pom project
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.ipsis.pacha/groupId
artifactIdPacha/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
namePACHA/name
build
plugins
plugin
!-- Tache permettant d'afficher le classpath
utilisé lors de l'execution de maven. --
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idprint-maven-runtime-classpath/id
phasecompile/phase
configuration
tasks
property
name=runtime-classpath
refid=maven.runtime.classpath /
echo
message=maven.runtime.classpath=${runtime-classpath} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
execution
idprint-maven-test-classpath/id
phasetest-compile/phase
configuration
tasks
property
name=test-classpath
refid=maven.test.classpath /
echo
message=maven.test.classpath=${test-classpath} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
plugin
!-- Version du compilateur et de la JVM cible
pour l'execution de l'application --
artifactIdmaven-compiler-plugin/artifactId
configuration
!-- On reste en 1.6. --
source1.6/source
target1.6/target
meminitial512m/meminitial
maxmem1024m/maxmem
optimizetrue/optimize
verbosetrue/verbose
forktrue/fork
executable${JAVA_HOME}\bin\javac.exe/executable
[jira] Created: (MPIR-217) Generating Dependency management report prints Unable to create Maven project from repository. warning with ugly stacktrace
Generating Dependency management report prints Unable to create Maven project
from repository. warning with ugly stacktrace
-
Key: MPIR-217
URL: http://jira.codehaus.org/browse/MPIR-217
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-management
Affects Versions: 2.3.1
Environment: maven 3.0.1
maven site plugin 3.0-beta-3
java 1.6 u23
windows 7 x64
Reporter: Stevo Slavic
Generating Dependency management report results in [1] stack traces printed
while generating site for a project. Btw, dependencies for which this stack
trace gets printed, are not available on repository printed in the output
messages. [2] is relevant pom.xml fragment.
[1] Project build output fragment
{code}
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find org.springframework
.webflow:spring-binding:pom:${org.springframework.webflow.version} in
https://repo.foo.bar.com/content/groups/foo-bar-
group was cached in the local repository, resolution will not be reattempted
until the update interval of foo-bar ha
s elapsed or updates are forced for project
org.springframework.webflow:spring-binding:pom:${org.springframework.webflow
.version}
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:260)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtil
s.java:332)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(Depen
dencyManagementRenderer.java:219)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForS
cope(DependencyManagementRenderer.java:198)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForA
llScopes(DependencyManagementRenderer.java:147)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDe
pendencies(DependencyManagementRenderer.java:140)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyM
anagementRenderer.java:126)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at
org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:
115)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:165)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:159)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
[jira] Created: (MSITE-539) Reporting plugin version references in new configuration example are wrong and misleading
Reporting plugin version references in new configuration example are wrong and misleading - Key: MSITE-539 URL: http://jira.codehaus.org/browse/MSITE-539 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0-beta-3 Reporter: Stevo Slavic Priority: Minor [New configuration example|http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html#New_Configuration] shows invalid reference to maven-javadoc-plugin version - version info there won't break a build but it is simply not used by Maven 3 or site plugin (maven reports that version info is not available for such reporting plugin). Such wrong example might mislead users that this is expected way of specifying version of reporting plugin used within maven site plugin configuration. Example following new configuration example, related to version resolution, is valid, it specifies reporting plugin version info in pluginManagement section. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-181) Javadoc report not generated for multi-module project if run from parent level.
[ http://jira.codehaus.org/browse/MJAVADOC-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated MJAVADOC-181: -- Attachment: maven_release_failure_caused_by_mjavadoc.txt I think I just got hit by this issue - release:perform fails on multi-module project because of javadoc plugin. See [^maven_release_failure_caused_by_mjavadoc.txt] for relevant build output. Javadoc report not generated for multi-module project if run from parent level. --- Key: MJAVADOC-181 URL: http://jira.codehaus.org/browse/MJAVADOC-181 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Environment: W2K, JDK 6u5, Maven 2.0.8 Reporter: André Fügenschuh Assignee: Vincent Siveton Fix For: 2.6 Attachments: maven-site-javadoc-testcase.zip, maven_release_failure_caused_by_mjavadoc.txt, MJAVADOC-181-1.patch, MJAVADOC-181.patch For the following project design (s. attached testcase): parent \- library// javadoc:aggregate! \- module-a \- module-b \- application javadoc report for 'library' is *not* generated (not invoked), if 'mvn site' is called at 'parent' level (but is properly done if run at 'library' level itself). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242867#action_242867 ] Stevo Slavic commented on MNG-624: -- Removed my vote for this feature - maven-release-plugin does a great job, and I really don't mind any more to have parent version in modules which inherit it. Parent module reference, like any other dependency, for reproducibility and clarity it's best to have it fully defined. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-648) Make surefire plugin compatible with TestNG 5.14
[ http://jira.codehaus.org/browse/SUREFIRE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237477#action_237477 ] Stevo Slavic commented on SUREFIRE-648: --- Checked, with 5.14.2 it works well. Issue can be closed, not a bug in surefire/failsafe. Make surefire plugin compatible with TestNG 5.14 Key: SUREFIRE-648 URL: http://jira.codehaus.org/browse/SUREFIRE-648 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.6 Reporter: Stevo Slavic Attachments: testng-groups.zip Latest TestNG version surefire plugin is compatible with is 5.13.1. groups configuration option does not work with 5.14. Attached example [^testng-groups.zip] works well when testng version is configured to 5.13.1, and doesn't work as expected when testng version is configured to 5.14. Same applies to failsafe plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-648) Make surefire plugin compatible with TestNG 5.14
[ http://jira.codehaus.org/browse/SUREFIRE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237453#action_237453 ] Stevo Slavic commented on SUREFIRE-648: --- It's a bug in TestNG 5.14.x (see [this|http://groups.google.com/group/testng-users/browse_thread/thread/b54417e5a61c5c62] related TestNG users mailing list thread). IMO issue can be closed as not a bug. Make surefire plugin compatible with TestNG 5.14 Key: SUREFIRE-648 URL: http://jira.codehaus.org/browse/SUREFIRE-648 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.6 Reporter: Stevo Slavic Attachments: testng-groups.zip Latest TestNG version surefire plugin is compatible with is 5.13.1. groups configuration option does not work with 5.14. Attached example [^testng-groups.zip] works well when testng version is configured to 5.13.1, and doesn't work as expected when testng version is configured to 5.14. Same applies to failsafe plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-648) Make surefire plugin compatible with TestNG 5.14
Make surefire plugin compatible with TestNG 5.14 Key: SUREFIRE-648 URL: http://jira.codehaus.org/browse/SUREFIRE-648 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.6 Reporter: Stevo Slavic Attachments: testng-groups.zip Latest TestNG version surefire plugin is compatible with is 5.13.1. groups configuration option does not work with 5.14. Attached example [^testng-groups.zip] works well when testng version is configured to 5.13.1, and doesn't work as expected when testng version is configured to 5.14. Same applies to failsafe plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-671) ftpserver-parent 1.0.4 has an 'r' character after closing groupId and before opening artifactId tag
ftpserver-parent 1.0.4 has an 'r' character after closing groupId and before opening artifactId tag --- Key: MEV-671 URL: http://jira.codehaus.org/browse/MEV-671 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Stevo Slavic See related issues [FTPSERVER-388|https://issues.apache.org/jira/browse/FTPSERVER-388] and [FTPSERVER-356|https://issues.apache.org/jira/browse/FTPSERVER-356], where latter has fixed pom file attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-445) Support parametrization of component descriptors
[
http://jira.codehaus.org/browse/MASSEMBLY-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stevo Slavic updated MASSEMBLY-445:
---
Attachment:
org.apache.maven.plugins.maven-assembly-plugin-MASSEMBLY-445.patch
After rethinking this new feature, I've come to a conclusion that initially it
would be enough to just expose assembly id so it becomes referenceable as
parameter from within component descriptors.
Here is a patch (
[^org.apache.maven.plugins.maven-assembly-plugin-MASSEMBLY-445.patch] ) which
adds support for this new feature. It works like this:
- If assembly id is defined in assembly descriptor
([assembly-1.1.1.xsd|http://maven.apache.org/xsd/assembly-1.1.1.xsd] allows it
not to be) that is being processed by the assembly plugin, then assembly
interpolator gets configured to replace ${assembly.id} references with
current assembly's id value;
- This substitution works correctly also when assembly id itself references
some cli/environment/project parameter/property, like project.build.finalName;
- A fresh interpolator is created for interpolation of every assembly in a
given project, so correct assembly id will be used for assembly interpolation
if there are more than one assemblies defined;
- Because of when existing assembly plugin code applies assembly interpolation
(after merging info from component descriptor(s) into assembly - and I didn't
want to change that), assembly.id can be referenced from assembly descriptor,
but primary goal was to support referencing it from component descriptor;
- If assembly.id is defined as project property, or given as cli parameter,
than that property/parameter value will take precedence compared to assembly
descriptor's id value when it comes to assembly/component interpolation.
Patch contains additional tests for this feature, and all of them, including
existing ones, pass.
Support parametrization of component descriptors
Key: MASSEMBLY-445
URL: http://jira.codehaus.org/browse/MASSEMBLY-445
Project: Maven 2.x Assembly Plugin
Issue Type: Wish
Affects Versions: 2.2-beta-4
Reporter: Stevo Slavic
Attachments:
org.apache.maven.plugins.maven-assembly-plugin-MASSEMBLY-445.patch
Please support parametrization of component descriptors. One should be able
to specify parameter placeholders in component descriptors, and when
referencing component descriptor from an assembly descriptor provide actual
parameter value(s) which would then be applied to the parameter placeholders.
One should be able to set global parameters (for all component descriptors),
and component descriptor specific parameters, with component descriptor
specific parameters overriding global ones if their names overlap.
This would be useful if e.g. one uses assembly descriptors to specify
assemblies for different deployment environments, and if these assemblies
differ (see example [1]) only in which environment specific configuration
file should be included in the assembly where this distinction is based on
configuration file name suffix - this suffix could be passed to shared
component descriptor as parameter, like in example [2].
[1] assembly descriptor example without parameters
?xml version=1.0 encoding=UTF-8?
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
http://maven.apache.org/xsd/assembly-1.1.1.xsd;
idprod/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory${project.build.directory}/${project.build.finalName}/directory
outputDirectory//outputDirectory
excludes
exclude**/jdbc.properties/exclude
exclude**/jdbc-*.properties/exclude
/excludes
excludes
exclude**/log4j.xml/exclude
exclude**/log4j-*.xml/exclude
/excludes
/fileSet
/fileSets
files
file
source${project.build.outputDirectory}/com/foo/bar/cfg/jdbc-${environment}.properties/source
outputDirectoryWEB-INF/classes/com/foo/bar/cfg//outputDirectory
destNamejdbc.properties/destName
/file
file
[jira] Commented: (MECLIPSE-36) use project.build.finalName for WTP context-root (if specified)
[
http://jira.codehaus.org/browse/MECLIPSE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=232921#action_232921
]
Stevo Slavic commented on MECLIPSE-36:
--
eclipse-maven-plugin:2.8 can be configured via
[wtpContextName|http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#wtpContextName]
parameter to use project.build.finalName as context name e.g.
{code:title=pom.xml|borderStyle=solid}
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
configuration
wtpContextName${project.build.finalName}/wtpContextName
/configuration
/plugin
...
{code}
use project.build.finalName for WTP context-root (if specified)
---
Key: MECLIPSE-36
URL: http://jira.codehaus.org/browse/MECLIPSE-36
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: java on linux, maven 2.0
Reporter: Dan Allen
Assignee: fabrizio giustina
Fix For: 2.1
When the regular maven build creates a *.war file, it honors the
project.build.finalName if specified. However, the maven-eclipse-plugin
always uses the artifactId of the project and therefore the *.war file
generated by eclipse is different than the one generated by maven.
The following code in EclipseWtpmodulesWriter.java can resolve the correct
context-root and should be used for setting the deploy-name and the
context-root.
String contextRoot = project.getArtifactId();
String finalName = project.getBuild().getFinalName();
if ( !finalName.equals( project.getArtifactId() + - +
project.getVersion() ) ){
contextRoot = finalName;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-361) eclipse plugin and WTP generating warnings in Europa
[ http://jira.codehaus.org/browse/MECLIPSE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated MECLIPSE-361: -- Attachment: org.apache.maven.plugins.maven-eclipse-plugin-MECLIPSE-361.patch Attaching proposed fix (org.apache.maven.plugins.maven-eclipse-plugin-MECLIPSE-361.patch) - existing tests pass. eclipse plugin and WTP generating warnings in Europa - Key: MECLIPSE-361 URL: http://jira.codehaus.org/browse/MECLIPSE-361 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5 Environment: Eclipse 3.3.1.1 and WTP 2.0.1 Using Maven 2.0.7 and the last maven-eclipse-plugin 2.5-SNAPSHOT Reporter: Yann Albou Assignee: fabrizio giustina Priority: Minor Attachments: org.apache.maven.plugins.maven-eclipse-plugin-MECLIPSE-361.patch, wtpTest.zip The issue is regarding warnings in Europa and WTP: Classpath entry M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar will not be exported or published. Runtime ClassNotFoundExceptions may result. 1) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.5-SNAPSHOT = I get the same behaviour in EUROPA (WARNINGS) 2) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.4 = I get the same behaviour in EUROPA (WARNINGS) 3) I then try using Eclipse 3.2.2 with WTP 1.5.3 (instead of Eclipse 3.3.1.1 and WTP 2.0.1) with maven-eclipse-plugin version 2.4 or 2.5-SNAPSHOT = Everything is perfect, no more warnings I create a simple test in order to reproduce the issue. This test is a multi module application composed of 1 Ejb module and 1 Ear module. So at the top level Just run mvn install eclipse:eclipse And then in an europa workspace import the projetcs and you should see the warnings on the EJB module. It will behave the same way if it exists other modules. I notice that, in the case you update parameters on the eclipse plugin you will need to remove projects from workspace and import them again. otherwise some old parameter will stay in the eclipse cache... let me know if you need other tests Yann. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-638) Plugin cannot handle java in a path name
[ http://jira.codehaus.org/browse/SUREFIRE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated SUREFIRE-638: -- Attachment: org.apache.maven.surefire.surefire-SUREFIRE-638.patch Here is the patch (org.apache.maven.surefire.surefire-SUREFIRE-638.patch) with a fix. Existing unit test has been adjusted and related test data extended to cover this case. Plugin cannot handle java in a path name -- Key: SUREFIRE-638 URL: http://jira.codehaus.org/browse/SUREFIRE-638 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.4.3, 2.5, 2.6 Reporter: SebbASF Priority: Critical Attachments: org.apache.maven.surefire.surefire-SUREFIRE-638.patch, surefire-638.zip See SUREFIRE-536 Commons SCXML had the following include: includeorg/apache/commons/scxml/env/javascript/EnvJavaScriptTestSuite.java/include However, the suite was not being found and executed. A bit of experimentation showed that the problem is the string java in the pathname. A work-round is to use: includeorg/apache/commons/scxml/env/j*avascript/EnvJavaScriptTestSuite.java/include or includeorg/apache/commons/scxml/env/jav*ascript/EnvJavaScriptTestSuite.java/include or includeorg/apache/commons/scxml/env/*/EnvJavaScriptTestSuite.java/include etc. This appears to be due to the following code in SurefireDirectoryScanner.processIncludesExcludes(): incs[i] = StringUtils.replace( (String) list.get( i ), java, class ); Changing this to incs[i] = StringUtils.replace( (String) list.get( i ), .java, .class ); would be better than nothing, however that would still fail on a directory name that contains .java (perhaps not very likely). What is really needed is to only replace the .java if it appears at the end of the string. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-111) Support encrypted password
Support encrypted password -- Key: MCHANGELOG-111 URL: http://jira.codehaus.org/browse/MCHANGELOG-111 Project: Maven 2.x Changelog Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Stevo Slavic [Maven supports encrypted passwords|http://maven.apache.org/guides/mini/guide-encryption.html] for configuring server authentication. I wish changelog plugin would have same feature supported. Currently authentication fails if password field is configured with an encrypted password. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[
http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stevo Slavic updated ARCHETYPE-273:
---
Attachment:
org.apache.maven.archetype.maven-archetype-ARCHETYPE-220__273_interactive_combo.patch
Here is a new patch
[^org.apache.maven.archetype.maven-archetype-ARCHETYPE-220__273_interactive_combo.patch].
New mojo has been renamed to ImportMojo, and it's goal has been renamed too
from import-catalog to just import since it now supports importing not only
all archetypes but also importing just single fully specified archetype from
given remote archetype repository, in both interactive and non-interactive mode.
E.g. to import all weld archetypes one can issue:
{code}
mvn archetype:import \
-Drepository=http://anonsvn.jboss.org/repos/weld/archetypes/tags/1.0.0-BETA1 \
-DinteractiveMode=false
{code}
or to have just weld-jsf-jee imported:
{code}
mvn archetype:import \
-Drepository=http://anonsvn.jboss.org/repos/weld/archetypes/tags/1.0.0-BETA1 \
-Dsettings.interactiveMode=false -DarchetypeArtifactId=weld-jsf-jee \
-DarchetypeGroupId=org.jboss.weld.archetypes \
-DarchetypeVersion=1.0.0-BETA1
{code}
(note: \ and line breaks are only included for pretty printing, and should
not be present in actual command)
When importing archetypes from a repository in (default) interactive mode,
archetype selector will offer user to chose from archetypes found in remote
archetype catalog, appended at the start of the archetype list with all
option which if chosen (option 1) will result in having all remote catalog
archetypes imported in local archetype catalog and repository.
repositoryId is present and optional for repositories which require
authentication.
Notice that in this comment examples
http://anonsvn.jboss.org/repos/weld/archetypes/tags/1.0.0-BETA1 is not path to
maven 2 repository, but it points archetype plugin to archetype-catalog.xml
file, while archetype artifacts will actually get resolved from maven central
repository as neither (initially) local nor that remote repository URL do not
contain archetype artifacts, while central does.
Patch doesn't add new tests, existing ones pass. Will try to add some
integration tests later in a separate patch.
Note that because of bug in maven 2 (fixed in maven 3 alphas) and jetty 6
(fixed in jetty 7) existing tests (even without patch) will not pass if project
build path contains spaces.
add goal to import remote archetype catalog into local catalog
--
Key: ARCHETYPE-273
URL: http://jira.codehaus.org/browse/ARCHETYPE-273
Project: Maven Archetype
Issue Type: New Feature
Components: Archetypes
Affects Versions: 2.0-alpha-4
Reporter: Dan Allen
Attachments:
org.apache.maven.archetype.maven-archetype-ARCHETYPE-220__273_interactive_combo.patch,
org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch
If I've just published a new archetype, I need to be able to provide the
developer with a command that allows them to educate their local catalog
about the new archetypes that area available. Currently, it's possible to
specify an archetype catalog for a single run of the generate goal:
mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2
But the catalog is transient. Those entries are not remembered. The next
time I run the generate goal...
mvn archetype:generate
...the archetypes in the catalog provided in the previous command are not
offered as options.
This is especially problematic when using an IDE to create a new Maven
project, because the mechanism for providing an archetype catalog differs in
each IDE. We want them to be in the local repository. Simply point, it's too
much information for the developer to have to reconcile, especially since
using an archetype is likely the developer's first exposure to your project.
It needs to be simple.
What I'm looking for is a command that I can give the developer to import the
entries from a remote archetype catalog. A discovery mechanism so to speak.
I envision the following sequence to work:
mvn archetype:import -DarchetypeCatalog=http://example.com/maven2
mvn archetype:generate
At this point, the developer would see options for the imported archetypes.
The import goal could even download the archetype JAR files at the same time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-242) The remote archchetype-catalog doesn't really exist.
[ http://jira.codehaus.org/browse/ARCHETYPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204922#action_204922 ] Stevo Slavic commented on ARCHETYPE-242: Just submitted a patch for ARCHETYPE-273 which adds support for importing remote archetypes in local archetype catalog and repository; with that it would be possible to consume archetypes whose artifacts have (optionally) been deployed to central repo, with archetypes being listed in remote (not necessarily central repo) archetype catalog. The remote archchetype-catalog doesn't really exist. -- Key: ARCHETYPE-242 URL: http://jira.codehaus.org/browse/ARCHETYPE-242 Project: Maven Archetype Issue Type: Bug Reporter: Jörg Henne Priority: Minor This page http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html states that the default remote catalog is located at http://repo1.maven.org/maven2/archetype-catalog.xml. However, there is no such file on repo1.maven.org and thus the remote catalog is useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-180) Repositories which require authentication get blacklisted
Repositories which require authentication get blacklisted - Key: MPIR-180 URL: http://jira.codehaus.org/browse/MPIR-180 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.2 Environment: maven 2.2.1 maven-site-plugin 2.1 Reporter: Stevo Slavic Dependencies report when rendering dependency repository locations wrongfully blacklists repositories which require authentication. Bug is in DependenciesRenderer, void blacklistRepositoryMap( Map repos, List repoUrlBlackListed ) method, ProjectInfoReportUtils.getInputStream( repoUrl, settings ) call throws IOException (java.io.IOException: Server returned HTTP response code: 401 for URL: ...) if repoUrl is URL of a repository which requires authentication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-242) The remote archchetype-catalog doesn't really exist.
[ http://jira.codehaus.org/browse/ARCHETYPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204123#action_204123 ] Stevo Slavic commented on ARCHETYPE-242: Nexus Archetype Plugin will maintain archetype-catalog.xml for a given repository, once archetype artifact is deployed to that repository. If Nexus managed repository is a proxy/mirror of central, it will cache artifacts from central, but only ones that were used through mirror of central. Using latest archetype trunk (2.0-alpha-5-SNAPSHOT), archetype artifact can not be used without being first in an archetype catalog. So, remote (central) and all archetypes in central repository (except ones listed in archetype plugin internal archetype catalog) are useless unless archetype-catalog.xml is generated and maintained in central repository. The remote archchetype-catalog doesn't really exist. -- Key: ARCHETYPE-242 URL: http://jira.codehaus.org/browse/ARCHETYPE-242 Project: Maven Archetype Issue Type: Bug Reporter: Jörg Henne Priority: Minor This page http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html states that the default remote catalog is located at http://repo1.maven.org/maven2/archetype-catalog.xml. However, there is no such file on repo1.maven.org and thus the remote catalog is useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203783#action_203783 ] Stevo Slavic commented on ARCHETYPE-273: @Luke IMO such functionality should be part of archetype:generate mojo, because I doubt one would like to have archetype just to be resolved/installed in local repository and added in local archetype catalog without intention to use archetype in the first place. Once remote archetype is specified archetype:generate resolves it and if all OK archetype is downloaded and present in local repository, just isn't yet usable (in next archetype:generate call) from local repository because it's not listed in local archetype catalog. Configurable parameter (e.g. importArchetype) could tell archetype:generate whether, besides using archetype for generating project, archetype:generate should also add archetype to local archetype catalog. It makes little sense to me, to download remote archetype in local repository but not have it automatically listed in local archetype catalog, so this importArchetype could by default be set to true (although this would somewhat break compatibility in default behavior with previous version). If importArchetype is set to true, archetype:generate should do the importing archetype in local catalog only after successful generation of project using given archetype, and before user specified additional goals. If not already archetype:generate could be made smart, when in interactive mode and listing archetypes, it should make sure that for each archetype no more than one option for same archetype version gets listed; if it makes any difference, archetype:generate should consistently prefer local to remote copy of same archetype version. Nevertheless, IMO a separate issue should be created for this. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203864#action_203864 ] Stevo Slavic commented on ARCHETYPE-273: Dan, I understood that you want support for importing _all_ archetypes, while if I understood Luke well he'd like support for importing _single_ archetype. My initial thought was that importing single archetype would best suite archetype:generate goal, and I still think it would be at least handy if one could suggest generate goal, not just to download, and use, but also to enlist downloaded archetype in local catalog. Nevertheless, importing archetypes could also be implemented with bit of interactivity, similar to what is already supported in archetype:generate, so behavior could be following: - if in interactive mode -- if just repository is given, import archetype mojo could retrieve remote catalog, list all the entries in remote archetype catalog as options + option import all so user can choose whether to import just specific archetype or to have them all imported - if in non-interactive mode -- if just repository is specified all archetypes get imported - regardless of being in interactive mode or not -- if user specifies archetype (groupId, artifactId, version) and remote repository, just that archetype gets imported Parameter interactiveMode, like [one|http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html#interactiveMode] in archetype:generate, would signal the mode we're in. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated ARCHETYPE-273: --- Attachment: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch Attaching proposed patch to archetype trunk r892601 ([^org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch]) with new ImportRemoteCatalogMojo (archetype:import-catalog goal, mandatory repository parameter with no default value, and optional repositoryId parameter defaulting to archetype value). When run import mojo will: - load remote archetype catalog from %repository%/archetype-catalog.xml URL; - load local archetype catalog from %localRepository%/archetype-catalog.xml; - loop through archetypes listed in remote archetype catalog and for each check: -- if remote archetype is not listed in local archetype catalog import mojo will download archetype artifact into local repository and update local archetype catalog; - and finally save local archetype catalog to %localRepository%/archetype-catalog.xml. This patch also contains my patch for ARCHETYPE-220, adding support for archetypeRepositoryId parameter to archetype:generate goal. Will look into separating the two if possible. Existing tests pass. No new tests have been added yet. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203713#action_203713 ] Stevo Slavic commented on ARCHETYPE-273: repository parameter is inline with archetype:generate's archetypeRepository parameter; in both cases it is any repository URL, which is used by mojos to construct repository (usually with default repositoryId, and if explicitly provided with given repository id which is handy for authentication) for retrieving repository archetype catalog and artifacts. In archetype:generate catalog can be local, remote, internal, http:// or file://, neither of which is flexible, powerful, nor simple as just any repository URL requirement (so including https://, maybe even dav:// will work, as long as there is appropriate wagon provider available). add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203726#action_203726 ] Stevo Slavic commented on ARCHETYPE-273: archetypeRepository (repository) and archetypeCatalog (catalog) are somewhat overlapping. Yes, docs are scarce, even in the [Maven book|http://www.sonatype.com/books/maven-book]. Luckily it's FOSS. I agree that either both parameters should be supported or just one, consistently. As proof of concept in my import-catalog mojo patch I implemented support just for one (repository). If there's no special reason to support both I'd prefer if it was just one that is left, maybe even just archetypeCatalog/catalog, it would make things more clear. Of course decision is up to plugin maintainers. IMO, in any case, repositoryId should be supported - repository URL (in form of repository or catalog) and repositoryId should go as a pair, just like in deploy:deploy-file mojo. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-275) Add eclipse IDE specific .settings to svn:ignore property of archetype-testing module
Add eclipse IDE specific .settings to svn:ignore property of archetype-testing module - Key: ARCHETYPE-275 URL: http://jira.codehaus.org/browse/ARCHETYPE-275 Project: Maven Archetype Issue Type: Task Affects Versions: 2.0-alpha-4 Reporter: Stevo Slavic Priority: Trivial -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203560#action_203560 ] Stevo Slavic commented on ARCHETYPE-273: Until this is implemented, one can issue mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 -Dgoals=archetype:crawl so at least used archetype will become available in local archetype catalog. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-275) Add eclipse IDE specific .settings to svn:ignore property of archetype-testing module
[ http://jira.codehaus.org/browse/ARCHETYPE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203561#action_203561 ] Stevo Slavic commented on ARCHETYPE-275: Same for root module. Thanks in advance! Add eclipse IDE specific .settings to svn:ignore property of archetype-testing module - Key: ARCHETYPE-275 URL: http://jira.codehaus.org/browse/ARCHETYPE-275 Project: Maven Archetype Issue Type: Task Affects Versions: 2.0-alpha-4 Reporter: Stevo Slavic Assignee: Benjamin Bentmann Priority: Trivial -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198361#action_198361 ] Stevo Slavic edited comment on ARCHETYPE-220 at 12/20/09 6:57 PM: -- Because one typically needs to provide credentials for such URL, and AFAIK standard way in Maven2 for providing (plugin) repository credentials is via server definition in settings.xml which would have id matching to (plugin) repository id. was (Author: sslavic): Because one needs to provide credentials for such URL, and AFAIK standard way in Maven2 for providing (plugin) repository credentials is via server definition in settings.xml which would have id matching to (plugin) repository id. Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: http://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Priority: Minor Attachments: https.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203592#action_203592 ] Stevo Slavic commented on ARCHETYPE-273: IMO it would be wise to support specifying archetypeRepositoryId parameter for this new archetype:import mojo, like I suggested in ARCHETYPE-220 for archetype:generate, so that archetypes listed in catalogs on repositories which require authentication can be imported as well. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-274) Regression in 2.6.1 - modules with no sources cause an error
[ http://jira.codehaus.org/browse/MJAVADOC-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202009#action_202009 ] Stevo Slavic commented on MJAVADOC-274: --- This is Java's javadoc tool reporting error. Just skip maven-javadoc-plugin execution for such module. Regression in 2.6.1 - modules with no sources cause an error Key: MJAVADOC-274 URL: http://jira.codehaus.org/browse/MJAVADOC-274 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6.1 Reporter: Andrey Razumovsky After upgrading from 2.6 to 2.6.1 our Apache Cayenne builds got broken. The problem is in module with no public or protected sources (there's only a package-private class). Now, after infamous message 'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be previously called for the project ... build fails and creates an error report. In the report: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation: Exit code: 1 - javadoc: error - No public or protected classes found to document. Command line was: C:\Progra~1\Java\jdk1.6.0_13\jre\..\bin\javadoc.exe @options @packages Refer to the generated Javadoc files in 'C:\Project\cayenne-parent\framework\cayenne-jdk1.6-unpublished\target\site\apidocs' dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-205) possibility to run a specified phase on newly generated project
[ http://jira.codehaus.org/browse/ARCHETYPE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=200407#action_200407 ] Stevo Slavic commented on ARCHETYPE-205: This is already possible in maven-archetype-plugin 2.0-alpha-4 via its goals parameter, e.g. mvn archetype:generate -Dgoals=clean,package. See docs [here|http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html#goals]. possibility to run a specified phase on newly generated project --- Key: ARCHETYPE-205 URL: http://jira.codehaus.org/browse/ARCHETYPE-205 Project: Maven Archetype Issue Type: Improvement Reporter: Adrian Herscu I am integrating some code generator into Maven. Currently, I have a project archetype and a plugin that wraps the generator. In the current arrangement creating a project is a three steps process: 1. mvn archetype:generate parameters 2. cd project-dir 3. mvn package/install/whatever I would like to make it a one step process - like: mvn archetype:generate parameters -DrunTo=package -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-648) plexus-utils-1.5.12-sources.jar has no sources
plexus-utils-1.5.12-sources.jar has no sources -- Key: MEV-648 URL: http://jira.codehaus.org/browse/MEV-648 Project: Maven Evangelism Issue Type: Bug Components: Problem with Jar Reporter: Stevo Slavic plexus-utils-1.5.12-sources.jar contains only META-INF folder with MANIFEST.MF file, and no sources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198361#action_198361 ] Stevo Slavic commented on ARCHETYPE-220: Because one needs to provide credentials for such URL, and AFAIK standard way in Maven2 for providing (plugin) repository credentials is via server definition in settings.xml which would have id matching to (plugin) repository id. Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: http://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Priority: Minor Attachments: https.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198083#action_198083 ] Stevo Slavic edited comment on ARCHETYPE-220 at 11/15/09 8:03 AM: -- One can already with 2.0-alpha-4 use archetypes from secured (https) repositories, not by specifying archetypeCatalog URL parameter, but by specifying archetypeRepository URL parameter. It is undocumented at the moment, but after 2.0-alpha-4 code analysis, I found that archetype plugin, if archetypeRepository parameter is provided, internally creates ArchetypeRepository instance with URL equal to archetypeRepository parameter value, and with id equal to %artifactId%-repo where %artifactId% is the value of archetypeArtifactId parameter. To provide credentials one has to adjust either global or user settings.xml file, by adding server definition with id equal to this calculated artifact repository id, and with appropriate credentials. Problem is that if one was to use N different artifacts (with different artifactId) from same repository, one would have to define N server definitions in settings.xml which is not nice at all. To fix this problem, I've extended archetype plugin with additional archetypeRepositoryId parameter which can be passed together with archetypeRepository (URL) parameter. If archetypeRepositoryId is configured together with archetypeRepository then plugin will construct and use ArchetypeRepository with id equal to archetypeRepositoryId parameter value. If only archetypeRepository is configured, plugin will work as before (so change is backwards compatible), setting ArchetypeRepository id to %artifactId%-repo. Attached is proposed patch ( org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch ) with fix described above. No new unit nor integration tests are included - existing ones all pass. Documentation should be updated too with appropriate example. was (Author: sslavic): One can already with 2.0-alpha-4 use archetypes from secured (https) repositories, not by specifying archetypeCatalog URL parameter, but by specifying archetypeRepository URL parameter. It is undocumented at the moment, but after 2.0-alpha-4 code analysis, I found that archetype plugin, if archetypeRepository parameter is provided, internally creates ArchetypeRepository instance with URL equal to archetypeRepository parameter value, and with id equal to %artifactId%-repo where %artifactId% is the value of archetypeArtifactId parameter. To provide credentials one has to adjust either global or user settings.xml file, by adding server definition with id equal to this calculated artifact repository id, and with appropriate credentials. Problem is that if one was to use N different artifacts (with different artifactId) from same repository, one would have to define N server definitions in settings.xml which is not nice at all. To fix this problem, I've extended archetype plugin with additional archetypeRepositoryId parameter which can be passed together with archetypeRepository (URL) parameter. If archetypeRepositoryId is configured together with archetypeRepository then plugin will construct and use ArchetypeRepository with id equal to archetypeRepositoryId parameter value. If only archetypeRepository is configured, plugin will work as before (so change is backwards compatible), setting ArchetypeRepository id to %artifactId%-repo. Attached is proposed patch with fix described above. No new unit nor integration tests are included - existing ones all pass. Documentation should be updated too with appropriate example. Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: http://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Priority: Minor Attachments: https.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access
[jira] Updated: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated ARCHETYPE-220: --- Attachment: org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch One can already with 2.0-alpha-4 use archetypes from secured (https) repositories, not by specifying archetypeCatalog URL parameter, but by specifying archetypeRepository URL parameter. It is undocumented at the moment, but after 2.0-alpha-4 code analysis, I found that archetype plugin, if archetypeRepository parameter is provided, internally creates ArchetypeRepository instance with URL equal to archetypeRepository parameter value, and with id equal to %artifactId%-repo where %artifactId% is the value of archetypeArtifactId parameter. To provide credentials one has to adjust either global or user settings.xml file, by adding server definition with id equal to this calculated artifact repository id, and with appropriate credentials. Problem is that if one was to use N different artifacts (with different artifactId) from same repository, one would have to define N server definitions in settings.xml which is not nice at all. To fix this problem, I've extended archetype plugin with additional archetypeRepositoryId parameter which can be passed together with archetypeRepository (URL) parameter. If archetypeRepositoryId is configured together with archetypeRepository then plugin will construct and use ArchetypeRepository with id equal to archetypeRepositoryId parameter value. If only archetypeRepository is configured, plugin will work as before (so change is backwards compatible), setting ArchetypeRepository id to %artifactId%-repo. Attached is proposed patch with fix described above. No new unit nor integration tests are included - existing ones all pass. Documentation should be updated too with appropriate example. Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: http://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Priority: Minor Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4391) DependencyManagement should allow replaceWith to manage use of re-named, woven, instrumented or compatible artifacts
[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=195984#action_195984
]
Stevo Slavic commented on MNG-4391:
---
Why not just support dependencies section for a dependency, like what's already
supported for build plugins (and hopefully will be in v3 supported for
reporting plugins too)? One could then for a given dependency configure set of
exclusions and add dependencies too out of which some could be exclusion
replacements. Dependency POM no longer reflects reality once one adds
exclusions to it, so adding more dependencies to it will IMO not be much more
difference on that aspect - there's always dependency:tree and
dependency:analyze, and IDE plugins can visualize effective POM.
DependencyManagement should allow replaceWith to manage use of re-named,
woven, instrumented or compatible artifacts
--
Key: MNG-4391
URL: http://jira.codehaus.org/browse/MNG-4391
Project: Maven 2
Issue Type: Improvement
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Neale
[if only this was a later version of JIRA I'd have not lost all of what I
just typed, as I could use Mylyn instead of the web UI. here goes again...]
The challenge of using a different artifact instead of the one that is
specified in a POM that you are consuming is not an easy one.
Examples where this hits uses is:
- the artifact name and packaging changes that Spring made at 2.5.6A (which
was a big improvement)
- wanting to use SLF4J instead of Apache commons logging (i.e. use something
that provides the same API, but is an entirely different project)
- wanting to use your own derivation of a public artifact
- wanting to use a woven/instrumented version of a public artifact
The current approach to replacing, say org.springframework : spring-beans
with org.springframework : org.springframework.beans is to do ('scuse the
shorthand):
{code:xml}
dependencyManagement
dependencies
dependency
groupIdcom.sun.jersey.contribs/groupId
artifactIdjersey-spring/artifactId
exclusions
org.springframework : spring-beans
/exclusions
/dependency
... repeat for every artifact that uses spring-beans, and then add more
if adding another artifact
/dependencies
/dependencyManagement
{code}
to exclude it, and then globally include the replacement using:
{code:xml}
dependencies
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
version${spring.version}/version
/dependency
/dependencies
{code}
This is error prone, and could be made far easier by an extension to
dependencies, which would remove the need to know what artifacts
(jersey-spring in the above example) use the artifact that you are replacing.
Here's how it would look:
{code:xml}
dependencyManagement
!-- this declares the version we want to use if this artifact is in use --
dependencies
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
version${spring.version}/version
/dependency
!-- This deals with artifact name change --
dependency
groupIdorg.springframework/groupId
artifactidspring-beans/groupId
replaceWith !-- list of dependency elements --
dependency
groupIdorg.springframework/groupId
artifactidorg.springframework.beans/groupId
/dependency
!-- more dependency elements could be added here if an artifact
has been split --
/replaceWith
/dependency
/dependencies
{code}
NOTE:
- Nothing is specified in dependencies so no artifacts are globally added
where they may not be needed. This means we can develop a project wide
parent pom.xml.
- Artifacts can have been split and merged
- Derived artifacts, such as instrumented ones can easily be substituted, and
could be selectively substituted using profiles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHARED-133) Invalid example in maven-archiver documentation
[
http://jira.codehaus.org/browse/MSHARED-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=195915#action_195915
]
Stevo Slavic commented on MSHARED-133:
--
Seems I misunderstood version info. Nevertheless, configuration options from
example seem not to be applicable to current version of maven-jar-plugin -
problem with example is [1] when [2].
[1] failed build trace snippet
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-jar-plugin:2.2
Cause: Cannot find setter nor field in
org.apache.maven.archiver.ManifestConfiguration for 'classpathLayoutType'
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
org.apache.maven.plugins:maven-jar-plugin. Reason: Unable to parse the created
DOM for plugin configuration
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:723)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginConfigurationException: Error
configuring: org.apache.maven.plugins:maven-jar-plugin. Reason: Unable to parse
the created DOM for plugin configuration
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1363)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:724)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot find setter nor field in org.apache.maven.archiver.ManifestConfiguration
for 'classpathLayoutType'
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.init(ComponentValueSetter.java:68)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:134)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:90)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:90)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1357)
... 20 more
{code}
[2] maven-jar-plugin:2.2 configuration
[jira] Created: (MSHARED-133) Invalid example in maven-archiver documentation
Invalid example in maven-archiver documentation --- Key: MSHARED-133 URL: http://jira.codehaus.org/browse/MSHARED-133 Project: Maven Shared Components Issue Type: Bug Components: maven-archiver Affects Versions: maven-archiver-2.4 Reporter: Stevo Slavic Priority: Minor [Using a Maven Repository-Style Classpath|http://maven.apache.org/shared/maven-archiver/examples/classpath.html#Repository] example is invalid - configuration options, like classpathLayoutType and classpathMavenRepositoryLayout/classpathLayoutType, as well as referenced plugin versions (2.3 and 2.4) are for maven-war-plugin, while in example maven-jar-plugin is used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-168) Dependency Has Changed Incorrectly Reported
[
http://jira.codehaus.org/browse/MWAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=195116#action_195116
]
Stevo Slavic commented on MWAR-168:
---
This seems to be fixed in current 2.1-beta-1. To use it one should specify the
version in project's plugin settings:
{code}
...
build
...
pluginManagement
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-beta-1/version
/plugin
...
/plugins
/pluginManagement
...
/build
...
{code}
Dependency Has Changed Incorrectly Reported
-
Key: MWAR-168
URL: http://jira.codehaus.org/browse/MWAR-168
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: gotama
Assignee: Stephane Nicoll
In maven-war-plugin 2.1-alpha-2, execute the following on a war project:
mvn clean;
mvn install;
mvn install;
The 3rd command incorrectly lists messages for each dependency as follows:
[INFO] Dependency[Dependency {groupId=com.mycompany, artifactId=myartifact,
version=8.6.1, type=jar}]
has changed (was Dependency {groupId=com.mycompany, artifactId=myartifact,
version=8.6.1, type=jar}).
The first time that mvn install is run, dependencies are added to:
target\myapp-war-1.1-SNAPSHOT\WEB-INF\lib
The second invocation of mvn install appears to fail in comparing the
existing jars in the above path with what is in the repository. The message
states the dependencies have changed when in fact they have not.
This problem does not exist in maven-war-plugin 2.0.2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-258) Support excluding files from to-be-created archetype
Support excluding files from to-be-created archetype Key: ARCHETYPE-258 URL: http://jira.codehaus.org/browse/ARCHETYPE-258 Project: Maven Archetype Issue Type: Wish Components: Creator Affects Versions: 2.0-alpha-4 Reporter: Stevo Slavic Please support configuration option for archetype:create-from-project mojo to exclude ((eclipse) IDE specific) files and directories (like .project, .classpath, .settings, .svn) when creating an archetype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-105) Update to Checkstyle 5.0
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192905#action_192905 ] Stevo Slavic commented on MCHECKSTYLE-105: -- From [this comment from Stephen Connolly|http://www.nabble.com/Re%3A-buildnumber-plugin-p25395826.html] I guess it would help if the patch included integration tests - with them maybe the new version with checkstyle 5 support could be released before Maven 3. Update to Checkstyle 5.0 Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Felix Röthenbacher Fix For: 2.4 Attachments: patch.diff, update-to-5.0-812221.patch, update-to-5.0.patch, update-to-5.0beta2.patch Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-445) Support parametrization of component descriptors
Support parametrization of component descriptors
Key: MASSEMBLY-445
URL: http://jira.codehaus.org/browse/MASSEMBLY-445
Project: Maven 2.x Assembly Plugin
Issue Type: Wish
Affects Versions: 2.2-beta-4
Reporter: Stevo Slavic
Please support parametrization of component descriptors. One should be able to
specify parameter placeholders in component descriptors, and when referencing
component descriptor from an assembly descriptor provide actual parameter
value(s) which would then be applied to the parameter placeholders. One should
be able to set global parameters (for all component descriptors), and component
descriptor specific parameters, with component descriptor specific parameters
overriding global ones if their names overlap.
This would be useful if e.g. one uses assembly descriptors to specify
assemblies for different deployment environments, and if these assemblies
differ (see example [1]) only in which environment specific configuration file
should be included in the assembly where this distinction is based on
configuration file name suffix - this suffix could be passed to shared
component descriptor as parameter, like in example [2].
[1] assembly descriptor example without parameters
?xml version=1.0 encoding=UTF-8?
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
http://maven.apache.org/xsd/assembly-1.1.1.xsd;
idprod/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory${project.build.directory}/${project.build.finalName}/directory
outputDirectory//outputDirectory
excludes
exclude**/jdbc.properties/exclude
exclude**/jdbc-*.properties/exclude
/excludes
excludes
exclude**/log4j.xml/exclude
exclude**/log4j-*.xml/exclude
/excludes
/fileSet
/fileSets
files
file
source${project.build.outputDirectory}/com/foo/bar/cfg/jdbc-${environment}.properties/source
outputDirectoryWEB-INF/classes/com/foo/bar/cfg//outputDirectory
destNamejdbc.properties/destName
/file
file
source${project.build.outputDirectory}/com/foo/bar/cfg/log4j-${environment}.xml/source
outputDirectoryWEB-INF/classes//outputDirectory
destNamelog4j.xml/destName
/file
/files
/assembly
[2] parametrized component descriptor and usage example
src/main/assembly/component.xml
-
component
fileSets
fileSet
directory${project.build.directory}/${project.build.finalName}/directory
outputDirectory//outputDirectory
excludes
exclude**/jdbc.properties/exclude
exclude**/jdbc-*.properties/exclude
/excludes
excludes
exclude**/log4j.xml/exclude
exclude**/log4j-*.xml/exclude
/excludes
/fileSet
/fileSets
files
file
source${project.build.outputDirectory}/com/foo/bar/cfg/jdbc-${environment}.properties/source
outputDirectoryWEB-INF/classes/com/foo/bar/cfg//outputDirectory
destNamejdbc.properties/destName
/file
file
source${project.build.outputDirectory}/com/foo/bar/cfg/log4j-${environment}.xml/source
outputDirectoryWEB-INF/classes//outputDirectory
destNamelog4j.xml/destName
/file
/files
/component
src/main/assembly/packaging-prod.xml
--
?xml version=1.0 encoding=UTF-8?
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
[jira] Commented: (MRELEASE-467) Release preparation should update version of plugin dependencies
[
http://jira.codehaus.org/browse/MRELEASE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187080#action_187080
]
Stevo Slavic commented on MRELEASE-467:
---
Yes, I knew that, thanks anyway. Maybe example wasn't the best, but there are
cases where modules have to be built/released together. E.g. if one wants to
share soapUI tests between two or more web services projects having common
subset of WS operations. In this case a module could be created to contain
shared soapui tests project as it's main/resources, and it could be shared by
configuring in same way soapui-maven-plugin for each of the web service project
modules, with a shared soapui tests module defined as soapui-maven-plugin
dependency.
If all project modules share the same version, then there is a workaround, by
just using ${project.version} as plugin dependency version. This doesn't work
in previous example where shared resource module (and parent it's built
together with) has one version and project using shared resources module has a
different version, so if parent module defines plugin dependency as
${project.version}, version of module (extends parent) using shared resources
will be replaced as ${project.version} which is different from shared resources
or parent module version resulting in dependency not or wrongly resolved.
Release preparation should update version of plugin dependencies
Key: MRELEASE-467
URL: http://jira.codehaus.org/browse/MRELEASE-467
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Stevo Slavic
Attachments: whizbang.zip
Currently plugin prepare release will update project dependencies, but not
project plugin dependencies. Please support updating version of plugin
dependencies as part of the prepare goal.
This would be useful if one has a multi-module project with one module
defining plugin with dependency to other project module, e.g. like in
suggested handling of sharing checkstyle configuration between modules of a
project (see
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
and attached eclipse project). There one build resources module contains
checkstyle configuration to be shared, while parent module inherited by all
other project modules (except one with the checkstyle configuration) defines
checkstyle plugin with added dependency to build resources module. Parent
module defines build resources module as it's module, and both are built at
the same time, likely all of them have same version. Currently version of
plugin dependency version doesn't get updated automatically by prepare goal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-158) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MPIR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=186223#action_186223 ] Stevo Slavic commented on MPIR-158: --- True, it started appearing again with 2.1.2 on a very complex project, but can not reproduce it on a simple project that could be attached to the issue. Can not reopen the issue, maybe new one will have to be created with maybe a link to this one. Artifact ## has no file error. -- Key: MPIR-158 URL: http://jira.codehaus.org/browse/MPIR-158 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.1 Environment: Windows xp, tomcat 5.5 server Reporter: Damian Sinczak Priority: Minor During 'mvn site' command on project i receive some strange errors. Their are no critical, but they are still errors. Console dump: [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no fi le. [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 .2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 .1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h as no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 ha s no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. 1.2 has no file. [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no file. [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga has n o file. [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. [ERROR] Artifact: xom:xom:jar:1.0 has no file. [INFO] Generating Project Team report. [INFO] Generating Project License report. [INFO] Generating Project Plugins report. [INFO] Generating Maven Surefire Report report. [INFO] Generating FindBugs Report report. [INFO] Using source root: [INFO] C:\edys_workspace\edystok\target\classes [INFO] Using test source root: [INFO] C:\edys_workspace\edystok\target\test-classes
[jira] Created: (MRELEASE-468) Branch mojo page lists branchName parameter as optional itparameter although it is required
Branch mojo page lists branchName parameter as optional itparameter although it is required --- Key: MRELEASE-468 URL: http://jira.codehaus.org/browse/MRELEASE-468 Project: Maven 2.x Release Plugin Issue Type: Bug Components: documentation Affects Versions: 2.0-beta-9 Reporter: Stevo Slavic Branch mojo page (http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html) lists branchName parameter as optional, although it is required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-468) Branch mojo page lists branchName parameter as optional itparameter although it is required
[ http://jira.codehaus.org/browse/MRELEASE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MRELEASE-468. - Resolution: Duplicate Duplicate of MRELEASE-327 Branch mojo page lists branchName parameter as optional itparameter although it is required --- Key: MRELEASE-468 URL: http://jira.codehaus.org/browse/MRELEASE-468 Project: Maven 2.x Release Plugin Issue Type: Bug Components: documentation Affects Versions: 2.0-beta-9 Reporter: Stevo Slavic Branch mojo page (http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html) lists branchName parameter as optional, although it is required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-467) Release preparation should update version of plugin dependencies
Release preparation should update version of plugin dependencies Key: MRELEASE-467 URL: http://jira.codehaus.org/browse/MRELEASE-467 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-9 Reporter: Stevo Slavic Attachments: whizbang.zip Currently plugin prepare release will update project dependencies, but not project plugin dependencies. Please support updating version of plugin dependencies as part of the prepare goal. This would be useful if one has a multi-module project with one module defining plugin with dependency to other project module, e.g. like in suggested handling of sharing checkstyle configuration between modules of a project (see http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html and attached eclipse project). There one build resources module contains checkstyle configuration to be shared, while parent module inherited by all other project modules (except one with the checkstyle configuration) defines checkstyle plugin with added dependency to build resources module. Parent module defines build resources module as it's module, and both are built at the same time, likely all of them have same version. Currently version of plugin dependency version doesn't get updated automatically by prepare goal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-158) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MPIR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=178335#action_178335 ] Stevo Slavic commented on MPIR-158: --- Can't reproduce this anymore. Artifact ## has no file error. -- Key: MPIR-158 URL: http://jira.codehaus.org/browse/MPIR-158 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.1 Environment: Windows xp, tomcat 5.5 server Reporter: Damian Sinczak Priority: Minor During 'mvn site' command on project i receive some strange errors. Their are no critical, but they are still errors. Console dump: [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no fi le. [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 .2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 .1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h as no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 ha s no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. 1.2 has no file. [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no file. [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga has n o file. [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. [ERROR] Artifact: xom:xom:jar:1.0 has no file. [INFO] Generating Project Team report. [INFO] Generating Project License report. [INFO] Generating Project Plugins report. [INFO] Generating Maven Surefire Report report. [INFO] Generating FindBugs Report report. [INFO] Using source root: [INFO] C:\edys_workspace\edystok\target\classes [INFO] Using test source root: [INFO] C:\edys_workspace\edystok\target\test-classes [INFO] No effort provided, using default effort. [INFO] Adding Source Directory: C:\edys_workspace\edystok\src\main\java [INFO] No threshold provided, using default threshold. [INFO] Using FindBugs Version: 1.3.7
[jira] Commented: (MCOMPILER-80) Change default source level to 1.5
[ http://jira.codehaus.org/browse/MCOMPILER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=178213#action_178213 ] Stevo Slavic commented on MCOMPILER-80: --- Why not go all the way and set 1.6 as default, since J2SE 5.0 will reach its end of service life (EOSL) on October 30th, 2009.? Change default source level to 1.5 -- Key: MCOMPILER-80 URL: http://jira.codehaus.org/browse/MCOMPILER-80 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Reporter: Grzegorz Borkowski Priority: Minor Deafult source level setting for Maven compiler plugin is 1.3, as far as I remember. This makes no sense. 1.3 is used at this moment only in legacy applications. Probability of porting such legacy application to Maven 2 is very small. I was working with such applications - none of them used Maven. In fact, I don't know any application using Maven, which requires level 1.3. On the other hand, Maven is used exensively in new applications. Most of them use Java 5 features (annotations, generics...). All new applications I create use Maven 2 and Java 5. Every time I setup such application it makes me crazy that I get errors on my generics and annoations, and I have to setup manually the source level to 1.5. Come on, we have year 2008, not 2000! Java 5 is here for several years already. So why Maven compiler plugin does not use the most reasonable default approach, instead it still assumes we are in 2000 year? If someone wants to use old java version, than he can change the source level. By default should be 1.5. The default setting can be changed in never wersion of maven compiler plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4156) Local test scope shouldn't override transitive compile scope
Local test scope shouldn't override transitive compile scope Key: MNG-4156 URL: http://jira.codehaus.org/browse/MNG-4156 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.1.0 Reporter: Stevo Slavic Attachments: example.zip Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. In this case (local test scoped vs transitive compile scoped dependency), requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it's correct in far less cases than it is wrong). Attached is example project where current in most cases unwanted behavior can be reproduced. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-157) Artifact ###### has no file error.
Artifact ## has no file error. -- Key: MPIR-157 URL: http://jira.codehaus.org/browse/MPIR-157 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.1 Environment: maven 2.1.0 Reporter: Stevo Slavic Attachments: maven-project-info-reports-downloading-transitive-deps.zip, maven_log_snippet.txt Issue initially created on maven site plugin JIRA ( MSITE-397 ) so please see description of the issue there. I'm attaching additional maven debug log output snippet which will hopefully shed more light to the issue. Will have to investigate if this happens only for modules with pom packaging. What I did notice via attached example trivial project, in 2.1.1 info reports plugin for dependencies report for every build plugin downloads transitive dependencies - in 2.1 this at least is not logged if it is being done at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-397) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MSITE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=173725#action_173725 ] Stevo Slavic commented on MSITE-397: Just created issue on maven project info reports plugin JIRA ( MPIR-157 ). It seems to be issue in 2.1.1 version of the mentioned plugin. Artifact ## has no file error. -- Key: MSITE-397 URL: http://jira.codehaus.org/browse/MSITE-397 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Windows xp, tomcat 5.5 server Reporter: Damian Sinczak Priority: Minor During 'mvn site' command on project i receive some strange errors. Their are no critical, but they are still errors. Console dump: [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no fi le. [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 .2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 .1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h as no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 ha s no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. 1.2 has no file. [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no file. [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga has n o file. [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. [ERROR] Artifact: xom:xom:jar:1.0 has no file. [INFO] Generating Project Team report. [INFO] Generating Project License report. [INFO] Generating Project Plugins report. [INFO] Generating Maven Surefire Report report. [INFO] Generating FindBugs Report report. [INFO] Using source root: [INFO] C:\edys_workspace\edystok\target\classes [INFO] Using test source root: [INFO] C:\edys_workspace\edystok\target\test-classes [INFO] No effort provided, using default effort. [INFO] Adding Source Directory: C:\edys_workspace\edystok\src\main\java [INFO] No threshold provided,
[jira] Created: (MCHECKSTYLE-109) Credentials ignored when provided in configLocation URL
Credentials ignored when provided in configLocation URL --- Key: MCHECKSTYLE-109 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-109 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.2 Environment: maven 2.1.0 Reporter: Stevo Slavic If configLocation URL contains username and password, e.g. https://username:password/acme.org/checkstyle_checks.xml, those should be used when obtaining checkstyle configuration xml. Currently, plugin fails to obtain resource from such URL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-204) go-offline fails to resolve artifact available in maven reactor
go-offline fails to resolve artifact available in maven reactor --- Key: MDEP-204 URL: http://jira.codehaus.org/browse/MDEP-204 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: go-offline Affects Versions: 2.1, 2.0 Environment: maven 2.1.0 Reporter: Stevo Slavic Assignee: Brian Fox Attachments: mvn-dependency-go-offline-failing-example.zip Attached is example project, for which IMO dependency:go-offline should be able to resolve all dependencies as they are only intermodule dependencies within same multimodule project which haven't been installed yet but are available in maven reactor so can be considered as resolvable in offline mode - instead dependency:go-offline fails to resolve these dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-380) Update assembly schema reference on Introduction page
Update assembly schema reference on Introduction page - Key: MASSEMBLY-380 URL: http://jira.codehaus.org/browse/MASSEMBLY-380 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-3 Reporter: Stevo Slavic Priority: Trivial Please update Assembly Descriptor Schemas (XSD) paragraph of plugin Introduction page at http://maven.apache.org/plugins/maven-assembly-plugin/ as it currently contains a broken link ( http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd instead of http://maven.apache.org/xsd/assembly-1.1.0.xsd ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-143) Wrong scope/phase requirement documented on project-info-reports:dependencies page
Wrong scope/phase requirement documented on project-info-reports:dependencies page -- Key: MPIR-143 URL: http://jira.codehaus.org/browse/MPIR-143 Project: Maven 2.x Project Info Reports Plugin Issue Type: Task Affects Versions: 2.1 Environment: maven 2.0.9 Reporter: Stevo Slavic Priority: Minor After discussion on maven user mailing list (see http://markmail.org/search/?q=sslavic%20list%3Aorg.apache.maven.users#query:sslavic%20list%3Aorg.apache.maven.users+page:2+mid:kkzcdmruemiwpeei+state:results ) conclusion was that wrong scope is documented on following page: http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies-mojo.html in Attributes section where instead of test in Requires dependency resolution of artifacts in scope: test. it should stand package. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-217) Update Aggregating Javadocs example
Update Aggregating Javadocs example - Key: MJAVADOC-217 URL: http://jira.codehaus.org/browse/MJAVADOC-217 Project: Maven 2.x Javadoc Plugin Issue Type: Task Affects Versions: 2.5 Reporter: Stevo Slavic Priority: Minor Please update Aggregating Javadocs example at http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html to comply with changes in Maven Javadocs plugin v2.5 (e.g. aggregate parameter being deprecated). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3758) Implement support for property expansion in the /project/parent/* nodes
[ http://jira.codehaus.org/browse/MNG-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MNG-3758. - Resolution: Duplicate Duplicate of http://jira.codehaus.org/browse/MNG-624 Implement support for property expansion in the /project/parent/* nodes --- Key: MNG-3758 URL: http://jira.codehaus.org/browse/MNG-3758 Project: Maven 2 Issue Type: Improvement Components: Maven Resources Filtering Affects Versions: 2.0.9 Reporter: Stevo Slavic For details see discussion in following maven-users mailing list topic: http://mail-archives.apache.org/mod_mbox/maven-users/200809.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3758) Implement support for property expansion in the /project/parent/* nodes
Implement support for property expansion in the /project/parent/* nodes --- Key: MNG-3758 URL: http://jira.codehaus.org/browse/MNG-3758 Project: Maven 2 Issue Type: Improvement Components: Maven Resources Filtering Affects Versions: 2.0.9 Reporter: Stevo Slavic For details see discussion in following maven-users mailing list topic: http://mail-archives.apache.org/mod_mbox/maven-users/200809.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3706) Multi-module project with intermodule dependencies fails to package
[ http://jira.codehaus.org/browse/MNG-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MNG-3706. - Resolution: Not A Bug Issue was in wrong use of maven assembly plugin where instead of attached goal, assembly goal was used, breaking multimodule project build. Multi-module project with intermodule dependencies fails to package --- Key: MNG-3706 URL: http://jira.codehaus.org/browse/MNG-3706 Project: Maven 2 Issue Type: Bug Components: Reactor and workspace Affects Versions: 2.0.9 Reporter: Stevo Slavic Say we have a maven project with following module structure: mainproject (packaging: pom) module 1 (packaging: jar) module 2 (packaging: pom) module 2.1 (packing: jar, depends on module 1) module 2.2 (packagin: jar, depends on module 2.1) module 3 (packaging: pom) module 3.1 (packaing: jar, depends on module 1) module 3.2 (packaging: jar, depends on module 2.2) If using command line one issues mvn clean package on a main project a build error gets reported that while building module 3.1 maven failed to resolve artifact, reporting module 1 as missing. If using command line one issues mvn clean install, again on a main project, a similar build error gets reported but now while building module 3.2 maven failed to resolve artifact, reporting as missing module 3.1 and module 2.2. Before issuing either of the commands I've cleaned up local repository from all of these modules artifacts, expecting that maven will resolve dependencies between modules while building them without using local or remote repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3706) Multi-module project with intermodule dependencies fails to package
Multi-module project with intermodule dependencies fails to package --- Key: MNG-3706 URL: http://jira.codehaus.org/browse/MNG-3706 Project: Maven 2 Issue Type: Bug Components: Reactor and workspace Affects Versions: 2.0.9 Reporter: Stevo Slavic Say we have a maven project with following module structure: mainproject (packaging: pom) module 1 (packaging: jar) module 2 (packaging: pom) module 2.1 (packing: jar, depends on module 1) module 2.2 (packagin: jar, depends on module 2.1) module 3 (packaging: pom) module 3.1 (packaing: jar, depends on module 1) module 3.2 (packaging: jar, depends on module 2.2) If using command line one issues mvn clean package on a main project a build error gets reported that while building module 3.1 maven failed to resolve artifact, reporting module 1 as missing. If using command line one issues mvn clean install, again on a main project, a similar build error gets reported but now while building module 3.2 maven failed to resolve artifact, reporting as missing module 3.1 and module 2.2. Before issuing either of the commands I've cleaned up local repository from all of these modules artifacts, expecting that maven will resolve dependencies between modules while building them without using local or remote repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3706) Multi-module project with intermodule dependencies fails to package
[ http://jira.codehaus.org/browse/MNG-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144925#action_144925 ] Stevo Slavic commented on MNG-3706: --- One important note, all the modules are snapshots, same version. I wanted, but couldn't set version information just in mainproject pom, and have all others (or at least some modules) reuse it, so now I have to go through all the pom's and set version manually to same value. Using parent.version works only in simplest cases, and using separate property didn't work also. But, anyway, that's another issue. Multi-module project with intermodule dependencies fails to package --- Key: MNG-3706 URL: http://jira.codehaus.org/browse/MNG-3706 Project: Maven 2 Issue Type: Bug Components: Reactor and workspace Affects Versions: 2.0.9 Reporter: Stevo Slavic Say we have a maven project with following module structure: mainproject (packaging: pom) module 1 (packaging: jar) module 2 (packaging: pom) module 2.1 (packing: jar, depends on module 1) module 2.2 (packagin: jar, depends on module 2.1) module 3 (packaging: pom) module 3.1 (packaing: jar, depends on module 1) module 3.2 (packaging: jar, depends on module 2.2) If using command line one issues mvn clean package on a main project a build error gets reported that while building module 3.1 maven failed to resolve artifact, reporting module 1 as missing. If using command line one issues mvn clean install, again on a main project, a similar build error gets reported but now while building module 3.2 maven failed to resolve artifact, reporting as missing module 3.1 and module 2.2. Before issuing either of the commands I've cleaned up local repository from all of these modules artifacts, expecting that maven will resolve dependencies between modules while building them without using local or remote repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
