[jira] [Created] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
Geoffrey De Smet created MJAVADOC-747:
-
Summary: jar goal fails with automatic module (Regression from
3.2.0)
Key: MJAVADOC-747
URL: https://issues.apache.org/jira/browse/MJAVADOC-747
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.5.0, 3.4.1, 3.4.0, 3.3.2, 3.3.1, 3.3.0
Reporter: Geoffrey De Smet
In optaplanner, we provide automatic module names for all our modules.
But some modules have a dependency with classes in the no-name package.
That was not a problem for the maven-javadoc-plugin, except since
maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
This happens with dependencies on quarkus and on rewrite.
For example, for optaplanner-migrator that depends on rewrite-maven and
rewrite-gradle:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
reproducer:
Execution default of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
Unable to derive module descriptor for
/.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
PluginSpec.class found in top-level directory (unnamed package not allowed in
module) -> [Help 1]{code}
Reproducer:
https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey De Smet updated MJAVADOC-747:
--
Description:
In optaplanner, we provide automatic module names for all our modules.
But some modules have a dependency with classes in the no-name package.
That was not a problem for the maven-javadoc-plugin, except since
maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
This happens with dependencies on quarkus and on rewrite.
For example, for optaplanner-migrator that depends on rewrite-maven and
rewrite-gradle:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
reproducer:
Execution default of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
Unable to derive module descriptor for
/.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
PluginSpec.class found in top-level directory (unnamed package not allowed in
module) -> [Help 1]{code}
Isolated reproducer:
[https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
was:
In optaplanner, we provide automatic module names for all our modules.
But some modules have a dependency with classes in the no-name package.
That was not a problem for the maven-javadoc-plugin, except since
maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
This happens with dependencies on quarkus and on rewrite.
For example, for optaplanner-migrator that depends on rewrite-maven and
rewrite-gradle:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
reproducer:
Execution default of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
Unable to derive module descriptor for
/.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
PluginSpec.class found in top-level directory (unnamed package not allowed in
module) -> [Help 1]{code}
Reproducer:
https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702781#comment-17702781 ] Geoffrey De Smet commented on MJAVADOC-707: --- Duplicated by MJAVADOC-747 which contains an isolated reproducer. > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702784#comment-17702784
]
Geoffrey De Smet commented on MJAVADOC-747:
---
Duplicated by MJAVADOC-707
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702781#comment-17702781 ] Geoffrey De Smet edited comment on MJAVADOC-707 at 3/20/23 2:58 PM: Related, but not duplicated by MJAVADOC-747 which contains an isolated reproducer. was (Author: ge0ffrey): Duplicated by MJAVADOC-747 which contains an isolated reproducer. > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702784#comment-17702784
]
Geoffrey De Smet edited comment on MJAVADOC-747 at 3/20/23 2:58 PM:
Related but not duplicated by MJAVADOC-707
was (Author: ge0ffrey):
Duplicated by MJAVADOC-707
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703133#comment-17703133
]
Geoffrey De Smet commented on MJAVADOC-747:
---
The stacktrace seems to indicate this is a user's problem - after all, there is
an "Automatic Module Name" defined on the project and one of its dependencies
is not module friendly (it uses the no-name package), so the javadoc plugin
rightly fails. Right?
However, I'd argue it's not a user's problem:
- Using "Automatic Module Name" is a way for open source projects that don't
want to go through the JPMS hassle today, to prepare themselves if they do want
to go through it some day - with minimal impact to their JPMS users.
- This issue effectively blocks the use of "Automatic Module Name" if quarkus,
openrewrite or other dependencies that don't care about JPMS are in the
dependencies.
- The compiler plugin etc all don't fail on this, only the new javadoc plugin
version (3.3.0+) does (=> regression).
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703135#comment-17703135
]
Geoffrey De Smet commented on MJAVADOC-747:
---
Workaround 1: don't use "Automatic Module Name".
Workaround 2: bind the javadoc plugin to the "process-classes" phase instead of
the "package" phase.
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-306) [REGRESSION] RequirePluginVersions fails
[
https://issues.apache.org/jira/browse/MENFORCER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664391#comment-16664391
]
Geoffrey De Smet commented on MENFORCER-306:
We also see this regression. It fails our build when upgrading from M1 to M2.
> [REGRESSION] RequirePluginVersions fails
>
>
> Key: MENFORCER-306
> URL: https://issues.apache.org/jira/browse/MENFORCER-306
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: MENFORCER-306.zip, pom.xml
>
>
> I have found that running the {{RequirePluginVersions}} rule on a project
> with version {{3.0.0-M1}} works fine whereas it fails with version
> {{3.0.0-M2}}.
> {code}
> [DEBUG] Executing rule:
> org.apache.maven.plugins.enforcer.RequirePluginVersions
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = clean
> [DEBUG] plugins = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] plugin = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] GAV = [org.apache.maven.plugins, maven-clean-plugin, 2.5, clean]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = install
> [DEBUG] plugins = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] plugin = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] GAV = [org.apache.maven.plugins, maven-install-plugin, 2.4,
> install]
> [DEBUG] lifecycleMapping = deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-deploy-plugin, 2.7, deploy]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = site
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, site]
> [DEBUG] lifecycleMapping = site-deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, deploy]
> [DEBUG] All Plugins in use: [Plugin [org.tinyjee.dim:doxia-include-macro],
> Plugin [org.apache.maven.plugins:maven-clean-plugin], Plugin
> [org.apache.maven.plugins:maven-install-plugin], Plugin
> [org.apache.maven.plugins:maven-site-plugin], Plugin
> [org.apache.maven.plugins:maven-deploy-plugin], Plugin
> [org.jacoco:jacoco-maven-plugin], Plugin
> [org.apache.maven.plugins:maven-enforcer-plugin]]
> [DEBUG] plugin org.tinyjee.dim:doxia-include-macro not found
> [DEBUG] plugin org.apache.maven.plugins:maven-clean-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-install-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-site-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-deploy-plugin not found
> [DEBUG] plugin org.jacoco:jacoco-maven-plugin not found
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Some plugins are
> missing valid versions:(LATEST RELEASE SNAPSHOT are not allowed )
> org.tinyjee.dim:doxia-include-macro. The version currently in use is 1.1
> org.apache.maven.plugins:maven-clean-plugin. The version currently in use is
> 3.0.0
> org.apache.maven.plugins:maven-install-plugin.The version currently
> in use is 2.5.2
> org.apache.maven.plugins:maven-site-plugin. The version currently in use is
> 3.6
> org.apache.maven.plugins:maven-deploy-plugin. The version currently
> in use is 2.8.2
> org.jacoco:jacoco-maven-plugin. The version currently in use is 0.8.0
> Always define plugin versions! Never use LATEST or RELEASE.
> at org.apache.maven.plugins.enforcer.RequirePluginVersions.execute
> (RequirePluginVersions.java:320)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] Created: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
Corrupted zip created by assembly: extracting the zip forgets certain folders
(or throws permission denied errors) possibly because zip index is corrupted
--
Key: MASSEMBLY-557
URL: http://jira.codehaus.org/browse/MASSEMBLY-557
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
Attachments:
droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
Take a look at the attached zip created by the assembly plugin.
- If you open it, you can see navigate to the submap
/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
map you find the file droolsjbpm-integration-docs.pdf which you can open with a
PDF reader.
- If instead you extract the entire archive to a directory, and navigate to the
submap /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you
'll find that that map is unreadable (chmod 000) and the pdf file is gone.
The directories html_single and html suffer the same fate, but none of the
other directories do.
I used the default linux Ubuntu 10.10 archive manager (which according to about
screen is called "File-roller 2.32.0").
I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
Note that that attached zip is gutted to stay inside the maximum file upload
size.
Possible reproduce recipe:
{code}
git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
cd droolsjbpm-integration
git checkout 5.2.0.M2
mvn clean install -DskipTests -Dfull
cd droolsjbpm-integration/target
ls
{code}
{code}
checkdir error: cannot create
/home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
Permission denied
unable to process
droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
...
{code}
--
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-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
http://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264372#action_264372
]
Geoffrey De Smet commented on MASSEMBLY-557:
Should be "cd droolsjbpm-integration-distribution/target" instead of "cd
droolsjbpm-integration/target"
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: http://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
http://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264377#action_264377
]
Geoffrey De Smet commented on MASSEMBLY-557:
Note that the reproduce recipe does not always reproduce it.
It's maybe a race condition in the zip algorithm which the assembly-plugin uses?
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: http://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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-5115) Repository deprecation: When a mvn build uses a maven repository that is marked deprecated in the maven repository metadata, it should show a warning.
Repository deprecation: When a mvn build uses a maven repository that is marked
deprecated in the maven repository metadata, it should show a warning.
--
Key: MNG-5115
URL: http://jira.codehaus.org/browse/MNG-5115
Project: Maven 2 & 3
Issue Type: New Feature
Components: Artifacts and Repositories
Affects Versions: 3.0.3
Reporter: Geoffrey De Smet
The old garbage JBoss repository is still used in many recent pom's (directly
or indirectly through dependencies).
To be able to battle it's use, a repository should be able to be marked as
deprecated.
Then when running a mvn build that somehow uses such a deprecated repository,
we should see something like this:
{code}
$ mvn clean install
[WARNING] You are using a deprecated repository
(http://deprecatedrepo.org/maven2/)
which was added in the pom of dependency org.foo:bar:1.0 ->
jdom:jdom:0.1 -> log4j:log4j:0.7
{code}
Note that it clearly shows the dependency graph path to the dependency pom that
included that bad repository.
--
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-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271007#comment-271007
]
Geoffrey De Smet commented on MASSEMBLY-557:
During the 5.2.0.CR1 it occurred again, but for another assembly
(drools-planner this time). This is a serious problem.
It's strange that both times it occurred on the reference_manual directory. It
feels like chmod related troubles.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271072#comment-271072
]
Geoffrey De Smet commented on MASSEMBLY-557:
During 5.2.0 final it occurred again, for droolsjbpm-integration again this
time.
So hopefully this is a reproduce recipe:
git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
droolsjbpm-build-bootstrap/script/git-clone-others.sh
droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests -Dfull
cd
droolsjbpm-build-distribution/droolsjbpm-uber-distribution/target/droolsjbpm-uber-distribution-*
unzip *.zip
// check the reference_manual directory contents after unzipping (not when
zipped)
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271072#comment-271072
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 6/23/11 7:00 AM:
-
During 5.2.0 first failed attempt it occurred again, for droolsjbpm-integration
again this time.
During 5.2.0.Final succeeded attempt it occurred again, for drools-planner that
time.
So hopefully this is a reproduce recipe:
git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
droolsjbpm-build-bootstrap/script/git-clone-others.sh
droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests -Dfull
cd
droolsjbpm-build-distribution/droolsjbpm-uber-distribution/target/droolsjbpm-uber-distribution-*
unzip *.zip
// check the reference_manual directory contents after unzipping (not when
zipped)
was (Author: ge0ffrey):
During 5.2.0 final it occurred again, for droolsjbpm-integration again this
time.
So hopefully this is a reproduce recipe:
git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
droolsjbpm-build-bootstrap/script/git-clone-others.sh
droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests -Dfull
cd
droolsjbpm-build-distribution/droolsjbpm-uber-distribution/target/droolsjbpm-uber-distribution-*
unzip *.zip
// check the reference_manual directory contents after unzipping (not when
zipped)
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271185#comment-271185
]
Geoffrey De Smet commented on MASSEMBLY-557:
Similar problems with javadoc directory
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
[
https://jira.codehaus.org/browse/MNG-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274335#comment-274335
]
Geoffrey De Smet commented on MNG-5064:
---
Yet I have replicated it a couple of days on the command line. Strange.
Maybe, there's a difference between the command line and the test environment?
I am using maven 3.0.3.
Here's a replication of what I did (although there's might be a shorter
reproduce recipe):
{code}
// Use maven 3.0.3 on linux
$ git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
// clones droolsjbpm-knowledge, then drools, then drools-planner, ...
$ droolsjbpm-build-bootstrap/script/git-clone-others.sh
// builds droolsjbpm-knowledge, then drools, then drools-planner, ...
$ droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests
// Note: drools-planner depends on a SNAPSHOT of drools
// Wait one day
$ cd drools-planner
$ mvn clean install -nsu -DskipTests
// It downloads drools-20110727-... pom and jar
{code}
> mvn -nsu (--no-snapshot-updates) should not download snapshots (and break
> local builds)
> ---
>
> Key: MNG-5064
> URL: https://jira.codehaus.org/browse/MNG-5064
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Geoffrey De Smet
>Assignee: Benson Margulies
>Priority: Critical
>
> Here's the command I ran (on a fresh morning, because our update policy is
> daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
> {code}
> $ mvn -nsu clean install -DskipTests
> [INFO] Scanning for projects...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> ...
> [INFO]
>
> [INFO] Building Drools Planner core 5.2.0-SNAPSHOT
> [INFO]
>
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> (2 KB at 1.8 KB/sec)
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> (6 KB at 6.0 KB/sec)
> ...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
> ...
> {code}
> Despite that I added "-nsu" (also known as "--no-snapshot-updates"), it
> downloaded snapshots.
> This is a pretty bad thing, because if I hadn't pulled in days (and just
> wanted to test my local changes before merging in remote changes),
> this would have broke my build, for example:
> - because the parent pom in downloaded SNAPSHOT had a dependency removed
> which my local pom was still using (because I hadn't pulled the changes yet)
> - because the downloaded knowledge-api changed a non-released method
> signature (and I hadn't pulled the changes to deal with that yet).
> - ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
[
https://jira.codehaus.org/browse/MNG-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274336#comment-274336
]
Geoffrey De Smet commented on MNG-5064:
---
Note, we do have this is in our parent pom:
{code}
jboss-public-repository-group
...
true
daily
{code}
But the -nsu should take precedence over that updatePolicy=daily
> mvn -nsu (--no-snapshot-updates) should not download snapshots (and break
> local builds)
> ---
>
> Key: MNG-5064
> URL: https://jira.codehaus.org/browse/MNG-5064
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Geoffrey De Smet
>Assignee: Benson Margulies
>Priority: Critical
>
> Here's the command I ran (on a fresh morning, because our update policy is
> daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
> {code}
> $ mvn -nsu clean install -DskipTests
> [INFO] Scanning for projects...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> ...
> [INFO]
>
> [INFO] Building Drools Planner core 5.2.0-SNAPSHOT
> [INFO]
>
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> (2 KB at 1.8 KB/sec)
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> (6 KB at 6.0 KB/sec)
> ...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
> ...
> {code}
> Despite that I added "-nsu" (also known as "--no-snapshot-updates"), it
> downloaded snapshots.
> This is a pretty bad thing, because if I hadn't pulled in days (and just
> wanted to test my local changes before merging in remote changes),
> this would have broke my build, for example:
> - because the parent pom in downloaded SNAPSHOT had a dependency removed
> which my local pom was still using (because I hadn't pulled the changes yet)
> - because the downloaded knowledge-api changed a non-released method
> signature (and I hadn't pulled the changes to deal with that yet).
> - ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
[
https://jira.codehaus.org/browse/MNG-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274336#comment-274336
]
Geoffrey De Smet edited comment on MNG-5064 at 7/27/11 3:13 AM:
Note, we do have this is in our parent pom:
{code}
jboss-public-repository-group
...
true
daily
{code}
But the -nsu should take precedence over that updatePolicy=daily, because
command line always overwrites configuration.
The workflow is:
- Either you've just git pulled, so you mvn build to fetch the latest snapshot
(as previous snapshots might be binary incompatible)
- Or, you've haven't git pulled in a while, so you mvn -nsu build to verify
your local changes and you don't want the latest snapshot (which might be
binary incompatible)
was (Author: ge0ffrey):
Note, we do have this is in our parent pom:
{code}
jboss-public-repository-group
...
true
daily
{code}
But the -nsu should take precedence over that updatePolicy=daily
> mvn -nsu (--no-snapshot-updates) should not download snapshots (and break
> local builds)
> ---
>
> Key: MNG-5064
> URL: https://jira.codehaus.org/browse/MNG-5064
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Geoffrey De Smet
>Assignee: Benson Margulies
>Priority: Critical
>
> Here's the command I ran (on a fresh morning, because our update policy is
> daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
> {code}
> $ mvn -nsu clean install -DskipTests
> [INFO] Scanning for projects...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> ...
> [INFO]
>
> [INFO] Building Drools Planner core 5.2.0-SNAPSHOT
> [INFO]
>
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> (2 KB at 1.8 KB/sec)
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> (6 KB at 6.0 KB/sec)
> ...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
> ...
> {code}
> Despite that I added "-nsu" (also known as "--no-snapshot-updates"), it
> downloaded snapshots.
> This is a pretty bad thing, because if I hadn't pulled in days (and just
> wanted to test my local changes before merging in remote changes),
> this would have broke my build, for example:
> - because the parent pom in downloaded SNAPSHOT had a dependency removed
> which my local pom was still using (because I hadn't pulled the changes yet)
> - because the downloaded knowledge-api changed a non-released method
> signature (and I hadn't pulled the changes to deal with that yet).
> - ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
[
https://jira.codehaus.org/browse/MNG-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274336#comment-274336
]
Geoffrey De Smet edited comment on MNG-5064 at 7/27/11 3:13 AM:
Note, we do have this is in our parent pom:
{code}
jboss-public-repository-group
...
true
daily
{code}
But the -nsu should take precedence over that updatePolicy=daily, because
command line always overwrites configuration.
The workflow is:
- Either you've just git pulled, so you mvn build to fetch the latest snapshot
(as previous snapshots might be binary incompatible with the latest code)
- Or, you've haven't git pulled in a while, so you mvn -nsu build to verify
your local changes and you don't want the latest snapshot (which might be
binary incompatible because you don't have the latest code)
was (Author: ge0ffrey):
Note, we do have this is in our parent pom:
{code}
jboss-public-repository-group
...
true
daily
{code}
But the -nsu should take precedence over that updatePolicy=daily, because
command line always overwrites configuration.
The workflow is:
- Either you've just git pulled, so you mvn build to fetch the latest snapshot
(as previous snapshots might be binary incompatible)
- Or, you've haven't git pulled in a while, so you mvn -nsu build to verify
your local changes and you don't want the latest snapshot (which might be
binary incompatible)
> mvn -nsu (--no-snapshot-updates) should not download snapshots (and break
> local builds)
> ---
>
> Key: MNG-5064
> URL: https://jira.codehaus.org/browse/MNG-5064
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Geoffrey De Smet
>Assignee: Benson Margulies
>Priority: Critical
>
> Here's the command I ran (on a fresh morning, because our update policy is
> daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
> {code}
> $ mvn -nsu clean install -DskipTests
> [INFO] Scanning for projects...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> ...
> [INFO]
>
> [INFO] Building Drools Planner core 5.2.0-SNAPSHOT
> [INFO]
>
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
> (2 KB at 1.8 KB/sec)
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> Downloaded:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
> (6 KB at 6.0 KB/sec)
> ...
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
> ...
> {code}
> Despite that I added "-nsu" (also known as "--no-snapshot-updates"), it
> downloaded snapshots.
> This is a pretty bad thing, because if I hadn't pulled in days (and just
> wanted to test my local changes before merging in remote changes),
> this would have broke my build, for example:
> - because the parent pom in downloaded SNAPSHOT had a dependency removed
> which my local pom was still using (because I hadn't pulled the changes yet)
> - because the downloaded knowledge-api changed a non-released method
> signature (and I hadn't pulled the changes to deal with that yet).
> - ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT - Key: MRELEASE-699 URL: https://jira.codehaus.org/browse/MRELEASE-699 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Geoffrey De Smet The documentation http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html states "The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used." That's not true, as releaseVersion is not supported: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion This means, that if you do this: mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274900#comment-274900 ] Geoffrey De Smet commented on MRELEASE-699: --- I patched this, please pull my changes: https://github.com/apache/maven-release/pull/2 This fix also fixes the fact that RewritePomVersionsPhase.getOriginalVersionMap() was inaccurate (although that did not seem to have any bad effect). > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated MRELEASE-699: -- Attachment: 0001-MRELEASE-699-release-update-versions-should-support-.patch No problem :) I did: git format-patch 124470185de7f3218380f2d7c0a384495ebb9955 and attached that file. That's probably a git patch, not an old-school patch. If you want an old-school patch, please inform me how I can create that from a command line or intelliJ after the changes have already been committed. > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274991#comment-274991 ] Geoffrey De Smet commented on MRELEASE-699: --- I can't use the release plugin for various reasons [1], but when I am releasing, I do need to be able to change all my versions from SNAPSHOT to release, tag and deploy and then from release to SNAPSHOT again. [1] Here's why I can't use the release plugin: - Our project has several git repositories with SNAPSHOT dependencies between them: https://github.com/droolsjbpm (guvnor depends on drools, drools depends on droolsjbpm-knowledge, ...). Having them all in a single git repo (of 1.2 GB) was unworkable for many reasons, yet for the time being they do continue to share the same release lifecycle. - We use tycho for our eclipse plugin (see droolsjbpm-tools). The release plugin and tycho don't integrate as far as I know. So I am creating release scripts here (to avoid having to manually change versions, tag, etc on every single release): https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script/release and these require this patch. > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274991#comment-274991 ] Geoffrey De Smet edited comment on MRELEASE-699 at 8/4/11 7:26 AM: --- I can't use the release:prepare goal for various reasons [1], but when I am releasing, I do need to be able to change all my versions from SNAPSHOT to release, tag and deploy and then from release to SNAPSHOT again. [1] Here's why I can't use the release:prepare goal: - Our project has several git repositories with SNAPSHOT dependencies between them: https://github.com/droolsjbpm (guvnor depends on drools, drools depends on droolsjbpm-knowledge, ...). Having them all in a single git repo (of 1.2 GB) was unworkable for many reasons, yet for the time being they do continue to share the same release lifecycle. - We use tycho for our eclipse plugin (see droolsjbpm-tools). The release plugin and tycho don't integrate as far as I know. So I am creating release scripts here (to avoid having to manually change versions, tag, etc on every single release): https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script/release and these require this patch. was (Author: ge0ffrey): I can't use the release plugin for various reasons [1], but when I am releasing, I do need to be able to change all my versions from SNAPSHOT to release, tag and deploy and then from release to SNAPSHOT again. [1] Here's why I can't use the release plugin: - Our project has several git repositories with SNAPSHOT dependencies between them: https://github.com/droolsjbpm (guvnor depends on drools, drools depends on droolsjbpm-knowledge, ...). Having them all in a single git repo (of 1.2 GB) was unworkable for many reasons, yet for the time being they do continue to share the same release lifecycle. - We use tycho for our eclipse plugin (see droolsjbpm-tools). The release plugin and tycho don't integrate as far as I know. So I am creating release scripts here (to avoid having to manually change versions, tag, etc on every single release): https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script/release and these require this patch. > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=277764#comment-277764 ] Geoffrey De Smet commented on MRELEASE-699: --- There is an alternative plugin to change the versions: http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html The release plugin goal "update-versions" should probably be deprecated in favor of that plugin. http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-264) Goal war:exploded should support packagingExcludes too
Goal war:exploded should support packagingExcludes too -- Key: MWAR-264 URL: https://jira.codehaus.org/browse/MWAR-264 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Geoffrey De Smet The war:war goals supports packagingExcludes, but the war:exploded doesn't support it yet. This means the exploded war and the packaged war behave differently, which is something that shouldn't happen by default. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288008#comment-288008 ] Geoffrey De Smet commented on MRELEASE-699: --- @Tomislav: yes > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run
Geoffrey De Smet created MJAVADOC-338:
-
Summary: When includeDependencySources=true the javadoc plugin
should not download the internet every time it is run
Key: MJAVADOC-338
URL: https://jira.codehaus.org/browse/MJAVADOC-338
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Geoffrey De Smet
This is my configuration:
{code}
org.apache.maven.plugins
maven-javadoc-plugin
package
javadoc
true
true
org.drools:*
{code}
the javadoc plugins downloads a very long list of dependencies every time it is
run:
{code}
gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn
javadoc:javadoc
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
[INFO]
[INFO]
[INFO] >>> maven-javadoc-plugin:2.8:javadoc (default-cli) @
droolsjbpm-uber-distribution >>>
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (default) @
droolsjbpm-uber-distribution ---
[INFO]
[INFO] <<< maven-javadoc-plugin:2.8:javadoc (default-cli) @
droolsjbpm-uber-distribution <<<
[INFO]
[INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @
droolsjbpm-uber-distribution ---
[WARNING] Missing POM for stax:stax-ri:jar:1.0
[WARNING] Missing POM for javax.ejb:ejb:jar:3.0
[WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
[WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
[WARNING] Missing POM for
org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
[WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
Downloading:
https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
[WARNING] Missing POM for
org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
Downloading:
https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
[WARNING] Missing POM for
org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
Downloading:
https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
[WARNING] Missing POM for
org.springframework:org.springframework.core:jar:javadoc-resources:3.0.0.RELEASE
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
Downloading:
https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
[WARNING] Missing POM for
org.springframework:org.springframework.aop:jar:javadoc-resources:3.0.0.RELEASE
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aspects/3.0.0.RELEASE/org.springframework.aspects-3.0.0.RELEASE.pom
Downloading:
https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aspects/3.0.0.RELEASE/org.springframework.aspects-3.0.0.RELEASE.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/org.springframework.aspects/3.0.0.RELEASE/org.springframework.aspects-3.0.0.
[jira] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run
[
https://jira.codehaus.org/browse/MJAVADOC-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288527#comment-288527
]
Geoffrey De Smet commented on MJAVADOC-338:
---
Notice how it always looks for "javadoc-resources" artifacts. But since I am
not use those, I don't see the point.
> When includeDependencySources=true the javadoc plugin should not download the
> internet every time it is run
> ---
>
> Key: MJAVADOC-338
> URL: https://jira.codehaus.org/browse/MJAVADOC-338
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Geoffrey De Smet
>
> This is my configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> package
>
> javadoc
>
>
>
>
> true
>
> true
>
> org.drools:*
>
>
>
> {code}
> the javadoc plugins downloads a very long list of dependencies every time it
> is run:
> {code}
> gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn
> javadoc:javadoc
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution >>>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (default) @
> droolsjbpm-uber-distribution ---
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution <<<
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution ---
> [WARNING] Missing POM for stax:stax-ri:jar:1.0
> [WARNING] Missing POM for javax.ejb:ejb:jar:3.0
> [WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
> [WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
> [WARNING] Missing POM for
> org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
> [WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.core:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org
[jira] (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[
https://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288531#comment-288531
]
Geoffrey De Smet commented on MJAVADOC-280:
---
Please reopen this issue: it doesn't work in 2.8.
With this configuration it still only generates the javadocs of the current
module in target/apidocs
{code}
org.apache.maven.plugins
maven-javadoc-plugin
package
jar
true
org.drools:*
org.drools
knowledge-api
org.drools
knowledge-api
sources
...
{code}
Here's someone else having the same problem.
http://maven.40175.n5.nabble.com/Aggregating-Javadocs-from-Dependency-Sources-td126034.html
> Allow creation of aggregated javadocs source bundles from project dependencies
> --
>
> Key: MJAVADOC-280
> URL: https://jira.codehaus.org/browse/MJAVADOC-280
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.6.1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.7
>
> Attachments: aggregate-from-dependencies.patch
>
>
> It would be nice to have the ability to generate an aggregated javadoc set
> for a distribution project by resolving the -sources and -test-sources
> bundles of its dependencies (or, correspondingly, the
> project.compileSourceRoots and project.testCompileSourceRoots for modules in
> the same reactor).
> Initially, this might just mean downloading, unpacking, and adding the
> dependency sources as sourcepaths to the javadoc execution if a flag is set
> to true (includeDependencySources). Later, we could easily expand this to
> allow bundling and deployment of the src/main/javadoc directory so that this
> artifact can be used in the above aggregation approach.
> I've got an implementation of the first part that I will attach to this issue
> as a patch to illustrate what I'm talking about.
--
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] (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[ https://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288539#comment-288539 ] Geoffrey De Smet commented on MJAVADOC-280: --- In some cases it works, strange. I 'll see if I can isolate what the difference is and create a new issue > Allow creation of aggregated javadocs source bundles from project dependencies > -- > > Key: MJAVADOC-280 > URL: https://jira.codehaus.org/browse/MJAVADOC-280 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.6.1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.7 > > Attachments: aggregate-from-dependencies.patch > > > It would be nice to have the ability to generate an aggregated javadoc set > for a distribution project by resolving the -sources and -test-sources > bundles of its dependencies (or, correspondingly, the > project.compileSourceRoots and project.testCompileSourceRoots for modules in > the same reactor). > Initially, this might just mean downloading, unpacking, and adding the > dependency sources as sourcepaths to the javadoc execution if a flag is set > to true (includeDependencySources). Later, we could easily expand this to > allow bundling and deployment of the src/main/javadoc directory so that this > artifact can be used in the above aggregation approach. > I've got an implementation of the first part that I will attach to this issue > as a patch to illustrate what I'm talking about. -- 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] (MJAVADOC-339) useStrictFiltering support in javadoc plugin for dependencySourceIncludes and dependencySourceExcludes
Geoffrey De Smet created MJAVADOC-339:
-
Summary: useStrictFiltering support in javadoc plugin for
dependencySourceIncludes and dependencySourceExcludes
Key: MJAVADOC-339
URL: https://jira.codehaus.org/browse/MJAVADOC-339
Project: Maven 2.x Javadoc Plugin
Issue Type: Improvement
Reporter: Geoffrey De Smet
Like in an assembly xml, the javadoc plugin should support useStrictFiltering:
{code}
true
org.drools:*
org.drools.planner:*
true
{code}
--
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] (MJAVADOC-340) Javadoc generation with includeDependencySources=true crashes when any of those dependencies have scope=provided dependencies
Geoffrey De Smet created MJAVADOC-340:
-
Summary: Javadoc generation with includeDependencySources=true
crashes when any of those dependencies have scope=provided dependencies
Key: MJAVADOC-340
URL: https://jira.codehaus.org/browse/MJAVADOC-340
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Reporter: Geoffrey De Smet
Priority: Critical
Using this configuration in jbpm-distribution:
{code}
true
org.jbpm:*
{code}
I got this:
{code}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 13.620s
[INFO] Finished at: Tue Jan 17 15:05:07 CET 2012
[INFO] Final Memory: 17M/441M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (javadoc-javadoc) on
project jbpm-distribution: An error has occurred in JavaDocs report generation:
[ERROR] Exit code: 1 -
/home/gdesmet/projects/jboss/droolsjbpm/jbpm/jbpm-distribution/target/distro-javadoc-sources/jbpm-flow-5.3.0-SNAPSHOT-sources/org/jbpm/osgi/flow/core/Activator.java:26:
package org.osgi.framework does not exist
[ERROR] import org.osgi.framework.BundleActivator;
{code}
Workaround: Explicitly add the provided scope dependencies one by one
{code}
org.apache.felix
org.osgi.core
provided
org.apache.felix
org.osgi.compendium
provided
{code}
(and if you're doing this in an assembly, make sure your zips don't get to big
or to small)
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
Geoffrey De Smet created MENFORCER-128:
--
Summary: Fail the build if a dependency is overwriten with an
incompatible lower version (patch)
Key: MENFORCER-128
URL: https://jira.codehaus.org/browse/MENFORCER-128
Project: Maven 2.x Enforcer Plugin
Issue Type: New Feature
Components: Standard Rules
Reporter: Geoffrey De Smet
Priority: Critical
Overwriting a dependency to a lower version than any of your other dependencies
need should fail the build if this new enforcer rule is active.
For example, this is bad:
{code}
org.slf4j
slf4j-api
1.4.0
ch.qos.logback
logback-classic
0.9.9
{code}
Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey De Smet updated MENFORCER-128:
---
Attachment: MENFORCER-128.patch
Patch attached.
Please apply on this codebase:
http://svn.apache.org/repos/asf/maven/enforcer/trunk/
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291270#comment-291270
]
Geoffrey De Smet commented on MENFORCER-128:
Patch includes documentation and IT tests.
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291344#comment-291344
]
Geoffrey De Smet commented on MENFORCER-128:
To see what sort of dirt this can bring to the surface in a big project, see
this issue:
https://issues.jboss.org/browse/JBRULES-3382
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet commented on MENFORCER-128:
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" is misleading and not standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet edited comment on MENFORCER-128 at 2/13/12 2:49 AM:
-
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might not be standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
was (Author: ge0ffrey):
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might be misleading and not standard knowledge for the
average programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet edited comment on MENFORCER-128 at 2/13/12 2:48 AM:
-
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might be misleading and not standard knowledge for the
average programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
was (Author: ge0ffrey):
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" is misleading and not standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291499#comment-291499
]
Geoffrey De Smet commented on MENFORCER-128:
Ok, sounds good :)
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run
[
https://jira.codehaus.org/browse/MJAVADOC-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344088#comment-344088
]
Geoffrey De Smet commented on MJAVADOC-338:
---
@JohnCasey Although I only want to include the drools dependency's
javadoc-resources, it's also downloading those of slf4j, springframework, etc.
Any way to stop that?
> When includeDependencySources=true the javadoc plugin should not download the
> internet every time it is run
> ---
>
> Key: MJAVADOC-338
> URL: https://jira.codehaus.org/browse/MJAVADOC-338
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Geoffrey De Smet
>
> This is my configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> package
>
> javadoc
>
>
>
>
> true
>
> true
>
> org.drools:*
>
>
>
> {code}
> the javadoc plugins downloads a very long list of dependencies every time it
> is run:
> {code}
> gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn
> javadoc:javadoc
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution >>>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (default) @
> droolsjbpm-uber-distribution ---
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution <<<
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @
> droolsjbpm-uber-distribution ---
> [WARNING] Missing POM for stax:stax-ri:jar:1.0
> [WARNING] Missing POM for javax.ejb:ejb:jar:3.0
> [WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
> [WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
> [WARNING] Missing POM for
> org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
> [WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
> [WARNING] Missing POM for
> org.springframework:org.springframework.core:jar:javadoc-resources:3.0.0.RELEASE
> Downloading:
> http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
> Downloading:
> http://repo1.maven.org/maven2/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
[jira] (MNG-5663) [regression] resolution of import-scoped transitive dependencies ignores additional repositories
[
https://jira.codehaus.org/browse/MNG-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349969#comment-349969
]
Geoffrey De Smet commented on MNG-5663:
---
Might be the cause of https://issues.jboss.org/browse/DROOLS-553
> [regression] resolution of import-scoped transitive dependencies ignores
> additional repositories
>
>
> Key: MNG-5663
> URL: https://jira.codehaus.org/browse/MNG-5663
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.2.2
>Reporter: Fred Bricon
>
> We (JBoss) use BOM poms extensively, notably in a number of project
> archetypes or project examples available via JBoss Tools and Red Hat
> Developer Studio . Some of these BOM poms (and their dependencies) are
> available from a dedicated Maven repository
> (http://maven.repository.redhat.com/techpreview/all/).
> Maven 3.2.2 introduced a regression that breaks resolution of these BOM
> dependencies, by ignoring additional repositories during artifact resolution.
> {noformat}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> foo
> bar
> 0.0.1-SNAPSHOT
>
>
>
> org.jboss.bom.wfk
>
> jboss-javaee-6.0-with-tools
> 2.4.0-redhat-2
> pom
> import
>
>
>
>
>
> redhat-techpreview-all-repository
>
> http://maven.repository.redhat.com/techpreview/all/
>
>
>
> {noformat}
> yields :
> {noformat}
> ➊bar mvn compile
> [INFO] Scanning for projects...
> Downloading:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
> Downloaded:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
> (8 KB at 5.1 KB/sec)
> Downloading:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
> Downloaded:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
> (7 KB at 6.8 KB/sec)
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:0.0.1-SNAPSHOT
> (/Users/fbricon/Dev/workspaces/runtime-hosted/bar/pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-4 in central
> (http://repo.maven.apache.org/maven2) @
> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version],
> /Users/fbricon/Dev/maven/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom,
> line 42, column 25 -> [Help 2]
> [ERROR] 'dependencies.dependency.version' for
> javax.enterprise:cdi-api:jar is missing. @ line 27, column 15
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> ➊bar
> {noformat}
> This kind of resolution used to work in maven 3.2.1 and before. The missing
> pom is available at
> http://maven.repository.redhat.com/techpreview/all/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5663) [regression] resolution of import-scoped transitive dependencies ignores additional repositories
[
https://jira.codehaus.org/browse/MNG-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350016#comment-350016
]
Geoffrey De Smet commented on MNG-5663:
---
Great! :)
> [regression] resolution of import-scoped transitive dependencies ignores
> additional repositories
>
>
> Key: MNG-5663
> URL: https://jira.codehaus.org/browse/MNG-5663
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.2.2
>Reporter: Fred Bricon
>Assignee: Jason van Zyl
> Fix For: 3.2.3
>
>
> We (JBoss) use BOM poms extensively, notably in a number of project
> archetypes or project examples available via JBoss Tools and Red Hat
> Developer Studio . Some of these BOM poms (and their dependencies) are
> available from a dedicated Maven repository
> (http://maven.repository.redhat.com/techpreview/all/).
> Maven 3.2.2 introduced a regression that breaks resolution of these BOM
> dependencies, by ignoring additional repositories during artifact resolution.
> {noformat}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> foo
> bar
> 0.0.1-SNAPSHOT
>
>
>
> org.jboss.bom.wfk
>
> jboss-javaee-6.0-with-tools
> 2.4.0-redhat-2
> pom
> import
>
>
>
>
>
> redhat-techpreview-all-repository
>
> http://maven.repository.redhat.com/techpreview/all/
>
>
>
> {noformat}
> yields :
> {noformat}
> ➊bar mvn compile
> [INFO] Scanning for projects...
> Downloading:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
> Downloaded:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
> (8 KB at 5.1 KB/sec)
> Downloading:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
> Downloaded:
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
> (7 KB at 6.8 KB/sec)
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:0.0.1-SNAPSHOT
> (/Users/fbricon/Dev/workspaces/runtime-hosted/bar/pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-4 in central
> (http://repo.maven.apache.org/maven2) @
> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version],
> /Users/fbricon/Dev/maven/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom,
> line 42, column 25 -> [Help 2]
> [ERROR] 'dependencies.dependency.version' for
> javax.enterprise:cdi-api:jar is missing. @ line 27, column 15
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> ➊bar
> {noformat}
> This kind of resolution used to work in maven 3.2.1 and before. The missing
> pom is available at
> http://maven.repository.redhat.com/techpreview/all/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (MNG-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly
[
http://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247187#action_247187
]
Geoffrey De Smet commented on MNG-4893:
---
Drools recently dumped the bad snapshot way (.SNAPSHOT) for the good way
(-SNAPSHOT) because maven 3 couldn't deal with it and it's better to do it
right.
> [regression] Version x.y.z.SNAPSHOT does not deploy correctly
> -
>
> Key: MNG-4893
> URL: http://jira.codehaus.org/browse/MNG-4893
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.0
>Reporter: Paul Gier
>Priority: Critical
> Fix For: 3.x / Backlog
>
>
> When using a version that ends with ".SNAPSHOT" instead of the usual
> "-SNAPSHOT", Maven 3.0 changes the project version to the timestamped
> version. So "5.2.0.SNAPSHOT" becomes something like
> "5.2.0.20101109.215833-1". A Nexus snapshot repository will reject this
> deployment because the version in the directory name does not end with
> "SNAPSHOT".
> I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not
> work in Maven 3.0. The build returns an HTTP 400 error when deploying to
> Nexus.
> Error from Nexus log
> {noformat}
> 2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing
> of item snapshots:/org/drools
> /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
> forbidden by Maven Repository
> policy. Because snapshots is a SNAPSHOT repository
> 2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got
> exception during processing
> request "PUT
> http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
> /5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom": Storing of
> item snapshots:/org/drools
> /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
> forbidden by Maven Repository
> policy. Because snapshots is a SNAPSHOT repository
> {noformat}
--
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-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local
builds)
---
Key: MNG-5064
URL: http://jira.codehaus.org/browse/MNG-5064
Project: Maven 2 & 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.0.3
Reporter: Geoffrey De Smet
Priority: Critical
Here's the command I ran (on a fresh morning, because our update policy is
daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
{code}
$ mvn -nsu clean install -DskipTests
[INFO] Scanning for projects...
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
...
[INFO]
[INFO] Building Drools Planner core 5.2.0-SNAPSHOT
[INFO]
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
Downloaded:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
(2 KB at 1.8 KB/sec)
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
Downloaded:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
(6 KB at 6.0 KB/sec)
...
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
...
{code}
Despite that I added "-nsu" (also known as "--no-snapshot-updates"), it
downloaded snapshots.
This is a pretty bad thing, because if I hadn't pulled in days (and just wanted
to test my local changes before merging in remote changes),
this would have broke my build, for example:
- because the parent pom in downloaded SNAPSHOT had a dependency removed which
my local pom was still using (because I hadn't pulled the changes yet)
- because the downloaded knowledge-api changed a non-released method signature
(and I hadn't pulled the changes to deal with that yet).
- ...
--
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] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
Geoffrey De Smet created MCOMPILER-270:
--
Summary: Support release=8 on JDK 9 (with fallback on source=8 and
target=8 on JDK 8)
Key: MCOMPILER-270
URL: https://issues.apache.org/jira/browse/MCOMPILER-270
Project: Maven Compiler Plugin
Issue Type: New Feature
Affects Versions: 3.5.1
Reporter: Geoffrey De Smet
Priority: Blocker
JDK 9 now supports the the follow argument:
{code}
javac -release 7
{code}
This replaced both `-source 7` and `-target 7`. And it prevents from using
methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
`-release 8` basically better in every way than `-source 7 -target 7`.
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
Support this in the maven-compiler plugin, something like:
{code}
maven-compiler-plugin
7
{code}
When compiling with JDK 9, it should just do `javac -release 7`.
When compiling with JDK 8, it should fallback to `javac -source 7 -target 7`,
so it behaves exactly like:
{code}
maven-compiler-plugin
7
7
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey De Smet updated MCOMPILER-270:
---
Description:
JDK 9 now supports the the follow argument:
{code}
javac -release 7
{code}
This replaced both `-source 7` and `-target 7`. And it prevents from using
methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
`-release 8` basically better in every way than `-source 7 -target 7`.
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
Support this in the maven-compiler plugin, something like:
{code}
maven-compiler-plugin
7
{code}
When compiling with JDK 9, it should just do `javac -release 7`.
When compiling with JDK 8 or lower, it should fallback to `javac -source 7
-target 7`, so it behaves exactly like:
{code}
maven-compiler-plugin
7
7
{code}
was:
JDK 9 now supports the the follow argument:
{code}
javac -release 7
{code}
This replaced both `-source 7` and `-target 7`. And it prevents from using
methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
`-release 8` basically better in every way than `-source 7 -target 7`.
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
Support this in the maven-compiler plugin, something like:
{code}
maven-compiler-plugin
7
{code}
When compiling with JDK 9, it should just do `javac -release 7`.
When compiling with JDK 8, it should fallback to `javac -source 7 -target 7`,
so it behaves exactly like:
{code}
maven-compiler-plugin
7
7
{code}
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's that doen't support release.
was (Author: ge0ffrey):
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet commented on MCOMPILER-270:
not translate source/target to release, but translate release to source/target
on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's.
was (Author: ge0ffrey):
Great :)
Note: not translate source/target to release, but translate release to
source/target on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but translate release to
source/target on older JDK's.
was (Author: ge0ffrey):
not translate source/target to release, but translate release to source/target
on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295433#comment-295433
]
Geoffrey De Smet commented on MASSEMBLY-557:
@Christoph Can you reproduce it consistently? I cannot: one mvn install might
have it, while the next doesn't.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296202#comment-296202
]
Geoffrey De Smet commented on MASSEMBLY-557:
Reproduced by building on Toni's mac. But Toni doesn't see the problem when
unzipping that zip, but I do on Linux when I unzip the zip build by him.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296226#comment-296226
]
Geoffrey De Smet commented on MASSEMBLY-557:
@Rick That sounds like a different issue. With our zips, all the content is in
the zips, but there's something wrong with some of the directory permissions in
some builds, which makes them lose file as the are unzip on linux, ok when
unzipped on mac and not unzippable on windows.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296800#comment-296800
]
Geoffrey De Smet commented on MASSEMBLY-557:
I've upgraded our assembly plugin to 2.2.2 (from 2.2.1) to check if it still
happens.
@Christoph Your 2.3.0 problem is definitely different then ours. I recommend
you open a different jira and since you can reproduce it consistently, you
might want to extract a simple project to reproduce it.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296800#comment-296800
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 5/14/12 3:57 AM:
-
Reproduced with assembly plugin 2.2.2 too (after upgrading from 2.2.1).
@Christoph Your 2.3.0 problem is definitely different then ours. I recommend
you open a different jira and since you can reproduce it consistently, you
might want to extract a simple project to reproduce it.
was (Author: ge0ffrey):
I've upgraded our assembly plugin to 2.2.2 (from 2.2.1) to check if it
still happens.
@Christoph Your 2.3.0 problem is definitely different then ours. I recommend
you open a different jira and since you can reproduce it consistently, you
might want to extract a simple project to reproduce it.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298607#comment-298607
]
Geoffrey De Smet commented on MASSEMBLY-557:
Reproduced with assembly plugin 2.3, even with explicitly stating
755.
However I did notice something important: It only happens with
with true.
This code can have it:
{code}
org.drools.planner:drools-planner-core:*:javadoc
javadoc
true
true
org.drools.planner:drools-planner-docs:jdocbook
reference_manual
true
META-INF/**
true
{code}
This code does not have it:
{code}
${project.build.directory}/aggregated-javadocs/apidocs
javadocs
{code}
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298613#comment-298613
]
Geoffrey De Smet commented on MASSEMBLY-557:
@Christoph I 've found a possible workaround, can you check if it works for you
too?
{code}
...
755
755
true
...
{code}
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298613#comment-298613
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 5/14/12 9:04 AM:
-
@Christoph I 've found a possible workaround, can you check if it works for you
too?
{code}
...
755
755
true
...
{code}
was (Author: ge0ffrey):
@Christoph I 've found a possible workaround, can you check if it works for
you too?
{code}
...
755
755
true
...
{code}
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298644#comment-298644
]
Geoffrey De Smet commented on MASSEMBLY-557:
SUMMARY of the issue: *the assembly zip is randomly corrupted if
together with true is used without explicitly setting the
...*.
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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] (MWAR-286) Please make test-jar also run for "war" packages
[ https://jira.codehaus.org/browse/MWAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308205#comment-308205 ] Geoffrey De Smet commented on MWAR-286: --- @Robert that would work: it fixes the problem of having to overwrite the jar plugin on every war module just to deploy the test-jar. But personally, I believe that if the jar plugin is configured to generate a test-jar, it should do that for war modules too. > Please make test-jar also run for "war" packages > > > Key: MWAR-286 > URL: https://jira.codehaus.org/browse/MWAR-286 > Project: Maven 2.x WAR Plugin > Issue Type: Wish >Affects Versions: 2.2 >Reporter: Marco rietveld >Priority: Minor > > If you configure the jar plugin to also run the test-jar goal, it will only > run that if the package type in the pom of the project is "jar". > However, in the case of wars it's would also be handy to be able to make the > test-jars (by simply changing the configuration in one mother pom). > We realize that this is an edge-case. However, we (drools/jbpm) work with a > project that has _lots_ or submodules including a couple "war" submodules. > Being able to simply have all war submodules generate test-jars without > having to modify each individual war submodule's pom.xml would be nice. > Thanks! -- 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] (MJAVADOC-340) Javadoc generation with includeDependencySources=true crashes when any of those dependencies have scope=provided dependencies
[
https://jira.codehaus.org/browse/MJAVADOC-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308643#comment-308643
]
Geoffrey De Smet commented on MJAVADOC-340:
---
Which version did you test? Please set it as fix version.
> Javadoc generation with includeDependencySources=true crashes when any of
> those dependencies have scope=provided dependencies
> -
>
> Key: MJAVADOC-340
> URL: https://jira.codehaus.org/browse/MJAVADOC-340
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Reporter: Geoffrey De Smet
>Assignee: Benson Margulies
>Priority: Critical
>
> Using this configuration in jbpm-distribution:
> {code}
>
> true
>
> org.jbpm:*
>
>
> {code}
> I got this:
> {code}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 13.620s
> [INFO] Finished at: Tue Jan 17 15:05:07 CET 2012
> [INFO] Final Memory: 17M/441M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (javadoc-javadoc)
> on project jbpm-distribution: An error has occurred in JavaDocs report
> generation:
> [ERROR] Exit code: 1 -
> /home/gdesmet/projects/jboss/droolsjbpm/jbpm/jbpm-distribution/target/distro-javadoc-sources/jbpm-flow-5.3.0-SNAPSHOT-sources/org/jbpm/osgi/flow/core/Activator.java:26:
> package org.osgi.framework does not exist
> [ERROR] import org.osgi.framework.BundleActivator;
> {code}
> Workaround: Explicitly add the provided scope dependencies one by one
> {code}
>
> org.apache.felix
> org.osgi.core
> provided
>
>
> org.apache.felix
> org.osgi.compendium
> provided
>
> {code}
> (and if you're doing this in an assembly, make sure your zips don't get to
> big or to small)
--
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] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313239#comment-313239
]
Geoffrey De Smet commented on MASSEMBLY-557:
@Kristian it's random (not always reproducable). However, since no one linked a
commit to the assembly plugin that defaults the directoryMode correctly, it's
probably still in there.
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
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: (MDEPLOY-115) Deploy should not fail if and does not exist when used with -DaltDeploymentRepository
Deploy should not fail if and does not
exist when used with -DaltDeploymentRepository
---
Key: MDEPLOY-115
URL: http://jira.codehaus.org/browse/MDEPLOY-115
Project: Maven 2.x Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.4
Reporter: Geoffrey De Smet
I have a pom with no section.
When I do:
{code}
mvn -DskipTests -DupdateReleaseInfo=true
-DaltDeploymentRepository=ggg-deploy::default::scp://ggg/maven/maven2/deploy
clean deploy
{code}
I get this error:
{code}
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-deploy-plugin:2.4
check that the following section of the pom.xml is present and correct:
repo
Repository Name
scp://host/path/to/repo
repo
Repository Name
scp://host/path/to/repo
Cause: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot
be instantiated
{code}
However, since I supply the altDeploymentRepository parameter, it shouldn't
require that section in the pom.xml
--
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-2727) Fix Logging in threadsafe components
[ http://jira.codehaus.org/browse/MNG-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205729#action_205729 ] Geoffrey De Smet commented on MNG-2727: --- log4j has been unchanged (=dead?) for 4 years. It's creator created slf4j with logback (AKA log4j 2), similar license, much better code, still maintained, but due to politics it never got the name "log4j 2". > Fix Logging in threadsafe components > > > Key: MNG-2727 > URL: http://jira.codehaus.org/browse/MNG-2727 > Project: Maven 2 & 3 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-7 > > -- 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] (MRESOURCES-31) Dependency resolution for resource filtering
[
https://jira.codehaus.org/browse/MRESOURCES-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=330625#comment-330625
]
Geoffrey De Smet commented on MRESOURCES-31:
We have a use case related to osgi/karaf.
We have a filtered features.xml file which needs to be able to use
{code}
${project.dependencies["org.mvel:mvel"].version}
{code}
Note: we can't declare a property ${verson.mvel}, because we're getting most of
our dependency versions (including this one) by importing a single target
platform bom.
> Dependency resolution for resource filtering
>
>
> Key: MRESOURCES-31
> URL: https://jira.codehaus.org/browse/MRESOURCES-31
> Project: Maven Resources Plugin
> Issue Type: Wish
>Affects Versions: 2.2
>Reporter: Daniel Holmen
>Priority: Minor
>
> I've been trying to use the project.compileClasspathElements property in a
> filtered resource, but discovered that Resources plugin isn't set up to
> require dependency resolution. The result of this is that i cannot use any of
> the classpath properties in my filtered resources.
> The solution is quite simple, just add a @requiresDependencyResolution
> annotation to ResourcesMojo. I have no idea if this causes any bad
> side-effects - but it seemed to work properly when I tested it locally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MVERIFIER-1) Verify that all dependencies are available in one of the remote repositories
Verify that all dependencies are available in one of the remote repositories Key: MVERIFIER-1 URL: http://jira.codehaus.org/browse/MVERIFIER-1 Project: Maven 2.x Verifier Plugin Type: New Feature Reporter: Geoffrey De Smet One problem I 've encountered a few times now is that everything builds locally on my pc but team mates can't build because my local repository differs from theirs. For example, I am working on 2 different projects A & B, each with it's own internal remote repo. The internal repo of A contains the ejb3 jar, but the other repo (the one of B) doesn't. When I created an indirect dependency on the ejb3 jar in the B project, it works locally because I 've already downloaded it for the project A. My team mates who are only working on project B, can't build and then send me angry e-mails :) It would be very nice that "mvn verify" verified that all dependencies are available in on of the pom defined (+ central) 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: (MIDEA-40) war module-dependencies are jarred and copied to /WEB-INF/classes
[ http://jira.codehaus.org/browse/MIDEA-40?page=comments#action_72563 ] Geoffrey De Smet commented on MIDEA-40: --- It's fixed in 2.0 as module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar This is probably indeed the best way in most cases. Can be closed, although having a property to switch to the first way would be nice. > war module-dependencies are jarred and copied to /WEB-INF/classes > - > > Key: MIDEA-40 > URL: http://jira.codehaus.org/browse/MIDEA-40 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Reporter: Geoffrey De Smet > > A mulitproject with a jar module A and a war module B, where B depends on A, > will be configured so that: > In web module settings, under "Modules and libraries to package": > module A : JAR module output and copy file to: /WEB-INF/classes > This should either be > module A : copy module output to: /WEB-INF/classes > or > module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar > Both should be supported a believe, as the second one mimics maven and the > real way of doing it, but the first one is a lot faster -- 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: (MIDEA-64) Provided dependencies are also copied to /WEB-INF/lib
Provided dependencies are also copied to /WEB-INF/lib - Key: MIDEA-64 URL: http://jira.codehaus.org/browse/MIDEA-64 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Geoffrey De Smet A dependency with the scope "provided" (and probably "system" too) is also marked as to be copied to /WEB-INF/lib for webapp 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] Updated: (MIDEA-64) Provided dependencies are also copied to /WEB-INF/lib
[ http://jira.codehaus.org/browse/MIDEA-64?page=all ] Geoffrey De Smet updated MIDEA-64: -- Attachment: screenshot-1.jpg I 've made log4j provided in my case. > Provided dependencies are also copied to /WEB-INF/lib > - > > Key: MIDEA-64 > URL: http://jira.codehaus.org/browse/MIDEA-64 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Geoffrey De Smet > Attachments: screenshot-1.jpg > > > A dependency with the scope "provided" (and probably "system" too) is also > marked as to be copied to /WEB-INF/lib for webapp 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: (MRELEASE-45) release plugin removes xml comments and attributes
[ http://jira.codehaus.org/browse/MRELEASE-45?page=comments#action_73645 ] Geoffrey De Smet commented on MRELEASE-45: -- Although most of the issues are now fixed, which is a huge improvement and enables the use of release:prepare, there are still 2 problems to reopen it. 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";> turns into 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";> So: - the ?xml version ... is removed (which gives problems for some xml editors) - the newline inside the xsd is removed (which makes the pom.xml a little bit unreadable. > release plugin removes xml comments and attributes > -- > > Key: MRELEASE-45 > URL: http://jira.codehaus.org/browse/MRELEASE-45 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Vincent Siveton > Assigned To: Brett Porter > Fix For: 2.0-beta-4 > > > I noticed that maven-release-plugin has removed some elements in pom.xml > files, during beta1 transition : > * xml encoding; > * Apache license; > * xsd reference (Regression bug MNG-596) > Try a svn diff between 289378 and 289532 revisions for > components\maven-plugins\maven-site-plugin\pom.xml -- 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: (MSITE-180) Missing url tag in (parent) pom make it ignore the site inheritence system
Missing url tag in (parent) pom make it ignore the site inheritence system -- Key: MSITE-180 URL: http://jira.codehaus.org/browse/MSITE-180 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Geoffrey De Smet IF none of the poms (module or parent) don't have an url tag, like this: ... ... ... (It doesn't matter if they have url tags in scm, distribution etc) THEN site inheritence quitely isn't applied, for example in the parent's site.xml http://www.mavenblogs.org/"/> isn't inherited in the childe module's site. proposed solutions: - or fix it :) - or document this wanted behaviour in the site plugin's documentation at http://maven.apache.org/plugins/maven-site-plugin/howto.html with something like "Site inheritence only works if you have a url tag in your parent pom." because this can cost people many hours - it did for me But once site inheritence works, it's very nice though :) -- 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-2572) Support for unversioned third party JARs
[ http://jira.codehaus.org/browse/MNG-2572?page=comments#action_75664 ] Geoffrey De Smet commented on MNG-2572: --- You're basically asking for a the jar-override system from Maven 1. Which was indeed handy for quick&dirty stuff. One side effect that I can think of is what happens once you deploy your artifact with a dependency that has such an obscure version, download location etc? The central repo should surely not accept anything that uses jar-override... Better support (and a documented example...) for remote-local repositories in the project dir, in a multiproject setup, would be more usefull I think. E.g: foo src foo-web foo-ear foo-ejb repo org.hibernate hibernate-annotations 3.2.0 hibernate-annotations-3.2.0.jar One would still need to do the work of writing/generating a pom for the jar, but one could create an eclipse/intellij configuration file that doesn't require knowning and using maven first to download all jars. You could just give the project directory. For example: you're teaching students hibernate-annotations without first needing to teach them maven. > Support for unversioned third party JARs > > > Key: MNG-2572 > URL: http://jira.codehaus.org/browse/MNG-2572 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Markus KARG > > Problem: > Maven's dependency management is great, but it lacks "real" support for > unversioned, third party JARs. > A Maven project declared dependencies on "foreign" JARs by adding a > dependency to the own pom.xml. That dependency declaration comprises of > groupId, atifactId, and version. In turn, Maven builds the actually used JAR > name by concatenating the version to the JAR's actual name. This is great if > the referenced JAR is built with Maven, but it is a problem whenever that > other JAR is not built by Maven. > Example: > You project needs to load some classes of FOO.jar. FOO.jar itself is a closed > source library that can be downloaded on the web, but it must not be > repackaged. Your own project will never succeed using it, since FOO.jar is > never called FOO-1.0.0.jar but always only FOO-1.0.0.jar. Since e. g. > licenceing rules restricts renaming and repackaging of FOO.jar, you cannot > use that JAR in your project and in turn, you even cannot use Maven to build > your own project. > Cause: > This is caused by Maven expecting the name of a referenced binary always > containing the version. > Solution: > Maven should allow pom.xml to specificy the actual JAR name, e. g. by adding > a new tag named that is parallel to , etc. > Once that tag is provided, it doesn't build the JAR name by adding the > version but it just uses the provided JAR name. This implies the following > two results: > (a) When FOO is provided in the section describing the > own project, then "mvn package" will create FOO.jar instead of > ArtifactId-VersionId.jar. > (b) When FOO is provided within a section, > then "mvn package" will add FOO.jar to Class-Path: instead of > ArtifactId-VersionId.jar, and the dependency loader will try to download > FOO.jar instead of ArtifactId-VersionId.jar. > Notes: > This new feature is optional. It is not intended to replace the dependency > mechanism as it currently exists, but it is only an additional option that > can be used whenever it is necessary to have the JAR name explicitely told. > The repository will still be organized and scanned using the information > found in groupId, artifactId and version. This mechanism is not touched. Only > the JAR's actual name is touched by this change. > Side Effects: > There should be no side effects besides solving the told problems, since the > original mechanism is not changed. The new feature is completely optional. -- 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: (MAVENUPLOAD-1053) Upload hibernate-tools 3.2.0-beta6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1053?page=comments#action_75757 ] Geoffrey De Smet commented on MAVENUPLOAD-1053: --- Here's the link to the related hibernate3-maven-plugin issue: MHIBERNATE-7 hibernate-entitymanager also isn't on Ibiblio, it' 2 bad the hibernate guys don't care about maven. > Upload hibernate-tools 3.2.0-beta6 > -- > > Key: MAVENUPLOAD-1053 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1053 > Project: maven-upload-requests > Issue Type: Task >Reporter: Johann Reyes > > Just found out that hibernate-tools is not dependant in official releases of > hibernate and hibernate-annotations artifacts, it needs the ones that came > bundle with, so here they are. -- 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: (MAVENUPLOAD-1053) Upload hibernate-tools 3.2.0-beta6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1053?page=comments#action_75752 ] Geoffrey De Smet commented on MAVENUPLOAD-1053: --- hibernate-tools beta7 is out (a while) While the new hibernate and hibernate-annotations where uploaded, tools wasn't. Using all latest versions together probably solves this issue? > Upload hibernate-tools 3.2.0-beta6 > -- > > Key: MAVENUPLOAD-1053 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1053 > Project: maven-upload-requests > Issue Type: Task >Reporter: Johann Reyes > > Just found out that hibernate-tools is not dependant in official releases of > hibernate and hibernate-annotations artifacts, it needs the ones that came > bundle with, so here they are. -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105686 ] Geoffrey De Smet commented on MIDEA-102: same here: win xp + idea 6 + maven 2.0.7 + maven-idea-plugin 2.1 (and 2.0 too I believe) = wrong iml paths in the ipr of a multimodule project. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MJAR-82) Class-Path manifest entry should support maven repository layout
Class-Path manifest entry should support maven repository layout Key: MJAR-82 URL: http://jira.codehaus.org/browse/MJAR-82 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Geoffrey De Smet Fix For: 2.2 The assembly plugin supports outputting all dependencies in a repository layout. The jar plugin should support adding the classpath manifest entry based on the repository layout. The combination of the two makes it easy to write a script to run the app: "java -jar org/domain/project/projectApp.jar" at the base of the repository layout. Example of a Class-Path entry: ClassPath: org/springframework/spring-core/2.0/spring-core-2.0.jar;org/drools/drools-core/4.0/drools-core-4.0.jar;org/domain/project/projectApp.jar Also see maven user mailing list "maven-jar-plugin: how to avoid conflicts in " -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108101 ] Geoffrey De Smet commented on MIDEA-102: Confirming it doesn't work for idea 2.0 or 2.1. It's maven 2.0.7 and win xp combination that is breaking. Workaround == Make sure you still have maven 2.0.6 still installed. Do this in your cygwin shell: export M2_HOME=/cygdrive/c/develop/build/maven-2.0.6 mvn idea:idea or if you're using cmd: set M2_HOME=C:\develop\build\maven-2.0.6 mvn idea:idea Afterwards throw away that shell instance, as it won't be using maven 2.0.7. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MDEPLOY-49) Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo
[ http://jira.codehaus.org/browse/MDEPLOY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet closed MDEPLOY-49. --- Resolution: Duplicate Fix Version/s: 2.5 Withdrawing issue, fixed in stage plugin, according to Wendy. I 'll have to try out that stage plugin :) Currently we're using a custom hacky script which also copies sources etc > Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo > - > > Key: MDEPLOY-49 > URL: http://jira.codehaus.org/browse/MDEPLOY-49 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Geoffrey De Smet >Priority: Minor > Fix For: 2.5 > > > The deploy plugin supports deploying from a local file with > deploy:deploy-file, > but it would be easier if it also supports fetching that file from another > remote repo. > Now we're using inhouse scripts to do this (which have problems). > Archiva will support proxying the remote repo, but some orginazations don't > want to automate adding artifacts to their release repo (only to their > snapshot repo). -- 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-65) Direct report generation breaks on skin version even though it is specified
Direct report generation breaks on skin version even though it is specified --- Key: MPIR-65 URL: http://jira.codehaus.org/browse/MPIR-65 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.0.1 Reporter: Geoffrey De Smet Fix For: 2.1 /ggg/src/site/site.xml contains the skin declaration like this: org.apache.maven.skins maven-default-skin 1.0 In /ggg I can run mvn site without a problem (it does compile the code though). but if I run mvn project-info-reports:dependencies That breaks with this error message: [INFO] The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file org.apache.maven.skins:maven-default-skin:jar:RELEASE -- 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-159) Add FAQ about building multi-module assemblies from the top using Maven 2.0
[ http://jira.codehaus.org/browse/MASSEMBLY-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93988 ] Geoffrey De Smet commented on MASSEMBLY-159: Why can "mvn package assembly:directory" be run, but it cannot be added like this? maven-assembly-plugin 2.2-beta-1 make-assembly install directory > Add FAQ about building multi-module assemblies from the top using Maven 2.0 > --- > > Key: MASSEMBLY-159 > URL: http://jira.codehaus.org/browse/MASSEMBLY-159 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Maven 2.0 >Reporter: Wendy Smoak > > John's post about why 'assembly:assembly' needs to be run separately with > Maven 2.0 should be adapted for the FAQ. > http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html > Related Threads: > > http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html > > http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.html -- 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-204) Make a single goal (assembly:assembly) that covers all cases of assembly:attached, directory, ...
Make a single goal (assembly:assembly) that covers all cases of assembly:attached, directory, ... - Key: MASSEMBLY-204 URL: http://jira.codehaus.org/browse/MASSEMBLY-204 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Geoffrey De Smet It shouldn't be that hard to check wheter it's a multiproject or not. >From a users perspective, when I bind the assembly plugin like this: maven-assembly-plugin assembly it should just work, without having to figure out if it's a multiproject, etc. Ps: I 've read the 7 different assembly goals 5 times, and I only understand the difference between unpack, attached and assembly... Great improvements in 2.2's descriptor though :) -- 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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
(False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6. - Key: MNG-2962 URL: http://jira.codehaus.org/browse/MNG-2962 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: windows Reporter: Geoffrey De Smet Since m2.0.6 builds that work perfectly on linux machine A and sometimes even on a windows machine B, breaks on another windows machine C. We have some "false transitive dependencies": transitive dependencies that should be direct dependencies. (We currently do this to avoid having to duplicate the version number as the different projects don't have a common superpom.) Making those dependencies direct dependencies fixes the problem with windows machine C, but the real problem is that the guy on linux machine A should get the problems too, before committing. The compiler plugin version is locked down to 2.0.2, but are using maven 2.0.6. This did not occur in maven 2.0.5. Attached you'll find the "mvn -X install" logs of the 2 windows machines. The log of machine C is specifically interesting, as it shows "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the classpath in the compiler plugin: [DEBUG] Adding managed depedendencies for unknown:atlas-spring ... [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile ... [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes .. (no org.springframework:spring-beans:jar:2.0.2) Machine B instead has instead this at the classpath log part: [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes ... C:\Documents and Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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: (MNG-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated MNG-2962: -- Attachment: m2.0.6-failing-compile-machineC.log > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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: (MNG-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated MNG-2962: -- Attachment: m2.0.6-working-compile-machineB.log > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94063 ] Geoffrey De Smet commented on MNG-2962: --- There is thread @user called "m2.0.6 with false transitive dependencies fails on windows, works on linux": http://www.nabble.com/m2.0.6-with-false-transitive-dependencies-fails-on-windows%2C-works-on-linux-tf3643824.html#a10176290 > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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-190) Problem with dependency conflict resolution on multi-module project
[
http://jira.codehaus.org/browse/MASSEMBLY-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94069
]
Geoffrey De Smet commented on MASSEMBLY-190:
I also have this issue.
I include 2 modules, both have a conflict resolution that ends up on
xstream-1.2.1; nevertheless xstream-1.1.3 stil appears in my lib dir.
(I make the jar plugin generate of both modules the classpath in the
manifest.MF, both times it's 1.2.1.)
ggg:ggg-distro
ggg:ggg-uploader
/lib
false
660
${artifactId}-${baseVersion}.${extension}
runtime
> Problem with dependency conflict resolution on multi-module project
> ---
>
> Key: MASSEMBLY-190
> URL: http://jira.codehaus.org/browse/MASSEMBLY-190
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Using maven 2.0.5 and assembly 2.2-SNAPSHOT
>Reporter: Frédéric ESNAULT
>
> Hi,
> I'm trying to use the assembly plugin to gather all the jars of my project,
> including all dependencies.
> As the project is composed of several modules, I use a descriptor which looks
> like this :
>
> bin
>
> zip
>
> false
>
>
>
> /
> false
> true
>
>
>
>
> It seems to work fine at first sight - it creates a zip containing all the
> jar files. However, I find in the archive several instances of the same
> dependency with differents versions, for instance asm-1.5.3 and asm-2.2.3.
> This is a surprise as maven is supposed to take care of conflict resolution.
> When I look at a detailed trace, it appears that conflict resolution is done
> but on each module independently. But my modules are intended to work
> together and I expect to get an assembly with only one version of each
> dependency found on the whole set of mudules. It seems to me that conflict
> resolution is not managed properly in this use case.
--
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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94100 ] Geoffrey De Smet commented on MNG-2962: --- At one point, machine A and machine C removed their local repo's and made sure they had the same poms (with "svn update"), nevertheless machine A would build and machine C would not. Between machine B and machine C we used the same poms and our settings.xml differ little or not, there are no claims of a repository. I have no explenation why machine B would skip our dev repo (and not our deploy repo) and machine C didn't. Our dev repo does not contain org.springframework:spring-beans whatever (no meta data about it either). > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[
http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94101
]
Geoffrey De Smet commented on MNG-2962:
---
However, if we - instead of adding the false transitive dependences - removed
the test-jar dependency it would also build on machine C (if test-compiling was
disabled at least):
${project.groupId}
atlas-spring
test-jar
If m2.0.6 fixed the unrandomizing handling of "the dependency path resolution",
how can the path differ between machines?
It looks like a randomizing factor has crept into transitive dependencies
combined with compile en test scope?
> (False) transitive dependencies don't appear on the compiler classpath in
> some windows environments since m2.0.6.
> -
>
> Key: MNG-2962
> URL: http://jira.codehaus.org/browse/MNG-2962
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.6
> Environment: windows
>Reporter: Geoffrey De Smet
> Attachments: m2.0.6-failing-compile-machineC.log,
> m2.0.6-working-compile-machineB.log
>
>
> Since m2.0.6 builds that work perfectly on linux machine A and sometimes even
> on a windows machine B, breaks on another windows machine C.
> We have some "false transitive dependencies": transitive dependencies that
> should be direct dependencies.
> (We currently do this to avoid having to duplicate the version number as the
> different projects don't have a common superpom.)
> Making those dependencies direct dependencies fixes the problem with windows
> machine C, but the real problem is that the guy on linux machine A should get
> the problems too, before committing.
> The compiler plugin version is locked down to 2.0.2, but are using maven
> 2.0.6. This did not occur in maven 2.0.5.
> Attached you'll find the "mvn -X install" logs of the 2 windows machines.
> The log of machine C is specifically interesting, as it shows
> "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the
> classpath in the compiler plugin:
> [DEBUG] Adding managed depedendencies for unknown:atlas-spring
> ...
> [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile
> ...
> [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes
> .. (no org.springframework:spring-beans:jar:2.0.2)
> Machine B instead has instead this at the classpath log part:
> [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes
> ...
> C:\Documents and
> Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar
--
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: (MECLIPSE-79) exclude dependencies from the Classpath Container
[ http://jira.codehaus.org/browse/MECLIPSE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95320 ] Geoffrey De Smet commented on MECLIPSE-79: -- At drools they have a use case for excluded dependencies: http://jira.jboss.com/jira/browse/JBRULES-833 The dependencies are already there throught the drools-plugin-in-eclipse which is added as a build nature. > exclude dependencies from the Classpath Container > - > > Key: MECLIPSE-79 > URL: http://jira.codehaus.org/browse/MECLIPSE-79 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Environment: Windows, Eclipse 3.1.2 >Reporter: Martin Goldhahn > Attachments: MECLIPSE-79.patch > > > There are some dependencies that need to be in the POM in order to compile > the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an > error because the servlet classes from the POM are included in the classpath > via the classpath container. -- 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: (MECLIPSE-79) exclude dependencies from the Classpath Container
[ http://jira.codehaus.org/browse/MECLIPSE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95329 ] Geoffrey De Smet commented on MECLIPSE-79: -- Putting them on scope "provided" won't work in the drools use case though - they need to be able to exclude them as the drools build nature already adds them. > exclude dependencies from the Classpath Container > - > > Key: MECLIPSE-79 > URL: http://jira.codehaus.org/browse/MECLIPSE-79 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Environment: Windows, Eclipse 3.1.2 >Reporter: Martin Goldhahn > Attachments: MECLIPSE-79.patch > > > There are some dependencies that need to be in the POM in order to compile > the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an > error because the servlet classes from the POM are included in the classpath > via the classpath container. -- 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: (MDEPLOY-46) "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace date.buildnumber
[ http://jira.codehaus.org/browse/MDEPLOY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95880 ] Geoffrey De Smet commented on MDEPLOY-46: - Even setting -DupdateReleaseInfo=true doesn't help, try it yourself: mvn deploy -DaltDeploymentRepository=ggg-deploy::default::file:///D:/tmp/delete/repo/ -DupdateReleaseInfo=true > "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace > date.buildnumber > -- > > Key: MDEPLOY-46 > URL: http://jira.codehaus.org/browse/MDEPLOY-46 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > I 've checkouted a m2 project (spring-richclient) and deployed it to my local > repo using the altDeploymentRepository parameter (from MDEPLOY-41). > But the checkout is a SNAPSHOT version and the deployer should replace it > with something like spring-richclient-core-0.3.0-20070101.160450-2.jar > like the mvn deploy without altDeploymentRepository does, > but it doesn't: > [INFO] [deploy:deploy] > altDeploymentRepository = ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Using alternate deployment repository > ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Retrieving previous build number from ggg-dev > Uploading: > scp://mvn.ggg.be/maven/maven2/dev/org/springframework/richclient/spring-richclient-core/0.3.0-SNAPSHOT/spring-richclient-core-0.3.0-SNAPSHOT.jar > 50K uploaded -- 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: (MDEPLOY-46) "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace date.buildnumber
[ http://jira.codehaus.org/browse/MDEPLOY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95881 ] Geoffrey De Smet commented on MDEPLOY-46: - -DupdateReleaseInfo=true doesn't even seem to work on a normal: mvn deploy -DupdateReleaseInfo=true with pom ggg-deploy gggDeployment Repository file:///D:/tmp/delete/deployrepo/ ggg-dev gggDevelopment Repository file:///D:/tmp/delete/devrepo/ if the version ends in -SNAPSHOT, as it creates D:\tmp\delete\devrepo\org\springframework\richclient\spring-richclient\0.3.0-SNAPSHOT\spring-richclient-0.3.0-20070515.075943-1.pom It should be: ...\deployrepo\.. instead of devrepo and not have SNAPSHOT in it's directory name. > "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace > date.buildnumber > -- > > Key: MDEPLOY-46 > URL: http://jira.codehaus.org/browse/MDEPLOY-46 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > I 've checkouted a m2 project (spring-richclient) and deployed it to my local > repo using the altDeploymentRepository parameter (from MDEPLOY-41). > But the checkout is a SNAPSHOT version and the deployer should replace it > with something like spring-richclient-core-0.3.0-20070101.160450-2.jar > like the mvn deploy without altDeploymentRepository does, > but it doesn't: > [INFO] [deploy:deploy] > altDeploymentRepository = ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Using alternate deployment repository > ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Retrieving previous build number from ggg-dev > Uploading: > scp://mvn.ggg.be/maven/maven2/dev/org/springframework/richclient/spring-richclient-core/0.3.0-SNAPSHOT/spring-richclient-core-0.3.0-SNAPSHOT.jar > 50K uploaded -- 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: (MJAR-82) Class-Path manifest entry should support maven repository layout
[ http://jira.codehaus.org/browse/MJAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_117223 ] Geoffrey De Smet commented on MJAR-82: -- Thanks :) What's the configuration entry to turn this feature on? > Class-Path manifest entry should support maven repository layout > > > Key: MJAR-82 > URL: http://jira.codehaus.org/browse/MJAR-82 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Geoffrey De Smet >Assignee: Olivier Lamy > Fix For: 2.2 > > > The assembly plugin supports outputting all dependencies in a repository > layout. > The jar plugin should support adding the classpath manifest entry based on > the repository layout. > The combination of the two makes it easy to write a script to run the app: > "java -jar org/domain/project/projectApp.jar" at the base of the repository > layout. > Example of a Class-Path entry: > ClassPath: > org/springframework/spring-core/2.0/spring-core-2.0.jar;org/drools/drools-core/4.0/drools-core-4.0.jar;org/domain/project/projectApp.jar > Also see maven user mailing list "maven-jar-plugin: how to avoid conflicts in > " -- 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: (MJAR-82) Class-Path manifest entry should support maven repository layout
[ http://jira.codehaus.org/browse/MJAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118322 ] Geoffrey De Smet commented on MJAR-82: -- Not yet, I hope to have some time to test it this week. Is the jar plugin snapshot with Dennis's change deployed to the snapshot repo or do I just build it myself?? > Class-Path manifest entry should support maven repository layout > > > Key: MJAR-82 > URL: http://jira.codehaus.org/browse/MJAR-82 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Geoffrey De Smet >Assignee: Olivier Lamy > Fix For: 2.2 > > > The assembly plugin supports outputting all dependencies in a repository > layout. > The jar plugin should support adding the classpath manifest entry based on > the repository layout. > The combination of the two makes it easy to write a script to run the app: > "java -jar org/domain/project/projectApp.jar" at the base of the repository > layout. > Example of a Class-Path entry: > ClassPath: > org/springframework/spring-core/2.0/spring-core-2.0.jar;org/drools/drools-core/4.0/drools-core-4.0.jar;org/domain/project/projectApp.jar > Also see maven user mailing list "maven-jar-plugin: how to avoid conflicts in > " -- 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: (MJAR-82) Class-Path manifest entry should support maven repository layout
[ http://jira.codehaus.org/browse/MJAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118597 ] Geoffrey De Smet commented on MJAR-82: -- I 've tested it and it looks ok. I haven't been able to test it with the assembly plugin combined with java -jar, because of our hack for MJAR-28 which needs a , so we can't use a . I am unsure if the Class-path is taken from the current working directory or from the directory of the jar. In the second case that might mean that all entry's should be prefixed with "../../", depending on the number of dots in the groupId of the jar. I 'll create another issue and reference it here if that's the case. > Class-Path manifest entry should support maven repository layout > > > Key: MJAR-82 > URL: http://jira.codehaus.org/browse/MJAR-82 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Geoffrey De Smet >Assignee: Olivier Lamy > Fix For: 2.2 > > > The assembly plugin supports outputting all dependencies in a repository > layout. > The jar plugin should support adding the classpath manifest entry based on > the repository layout. > The combination of the two makes it easy to write a script to run the app: > "java -jar org/domain/project/projectApp.jar" at the base of the repository > layout. > Example of a Class-Path entry: > ClassPath: > org/springframework/spring-core/2.0/spring-core-2.0.jar;org/drools/drools-core/4.0/drools-core-4.0.jar;org/domain/project/projectApp.jar > Also see maven user mailing list "maven-jar-plugin: how to avoid conflicts in > " -- 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: (MAVENUPLOAD-1936) Hibernate 3.2.6 ga upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125128 ] Geoffrey De Smet commented on MAVENUPLOAD-1936: --- I saw a mail on their dev list through google which said they 'll have maven support from 3.3.x (which is really good news :) and that 3.2.6 will be left out in the cold (2 bad). > Hibernate 3.2.6 ga upload > - > > Key: MAVENUPLOAD-1936 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1936 > Project: maven-upload-requests > Issue Type: Task >Reporter: Emil A. Lefkof III >Assignee: Carlos Sanchez > > Not a member of the Hibernate team but thought the new 3.2.6 ga should be > uploaded to ibiblio -- 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
