[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=16517370#comment-16517370
]
Matt Benson commented on MENFORCER-306:
---
I must have misunderstood the requirements of the plugin. So it does not take
into account plugin versions that are specified by the super POM or by
lifecycle definitions?
BTW, I could not find the pom lifecycle def but even switching packaging to jar
I did indeed encounter a failure with my sample pom using enforcer 1.4.1, so
I'm just trying to understand the rule. Surely a plugin version is permitted to
be specified by a parent pom, just not the super pom?
Thanks,
Matt
> [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: 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] [Updated] (MENFORCER-306) [REGRESSION] RequirePluginVersions fails
[
https://issues.apache.org/jira/browse/MENFORCER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated MENFORCER-306:
--
Attachment: pom.xml
> [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: 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] [Commented] (MENFORCER-306) [REGRESSION] RequirePluginVersions fails
[
https://issues.apache.org/jira/browse/MENFORCER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516448#comment-16516448
]
Matt Benson commented on MENFORCER-306:
---
I find that the attached pom fails with 3.0.0-M1 and M2 alike.
> [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: 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] [Closed] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
[
https://issues.apache.org/jira/browse/MJAVADOC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson closed MJAVADOC-471.
Resolution: Cannot Reproduce
Well, I've tried but I can't seem to reproduce the original problem. Hopefully
I never will! :)
> When aggregator filters out artifacts of current reactor projects, only the
> primary artifact is considered
> --
>
> Key: MJAVADOC-471
> URL: https://issues.apache.org/jira/browse/MJAVADOC-471
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Matt Benson
> Fix For: 3.0.0
>
> Attachments: MJAVADOC-471.patch.txt
>
>
> given project structure
> {code}
> foo-parent
> - foo-child-1
> - foo-child-2
> {code}
> If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
> build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
[
https://issues.apache.org/jira/browse/MJAVADOC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090490#comment-16090490
]
Matt Benson commented on MJAVADOC-471:
--
Right; I'm looking into it. I'd really like to make 3.0.0-final and should be
able to devote the time needed.
> When aggregator filters out artifacts of current reactor projects, only the
> primary artifact is considered
> --
>
> Key: MJAVADOC-471
> URL: https://issues.apache.org/jira/browse/MJAVADOC-471
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Matt Benson
> Fix For: 3.0.0
>
> Attachments: MJAVADOC-471.patch.txt
>
>
> given project structure
> {code}
> foo-parent
> - foo-child-1
> - foo-child-2
> {code}
> If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
> build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
[
https://issues.apache.org/jira/browse/MJAVADOC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated MJAVADOC-471:
-
Attachment: MJAVADOC-471.patch.txt
Patch to address MJAVADOC-471. Obviously, intended for inclusion and my Apache
ICLA is on file.
> When aggregator filters out artifacts of current reactor projects, only the
> primary artifact is considered
> --
>
> Key: MJAVADOC-471
> URL: https://issues.apache.org/jira/browse/MJAVADOC-471
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Matt Benson
> Attachments: MJAVADOC-471.patch.txt
>
>
> given project structure
> {code}
> foo-parent
> - foo-child-1
> - foo-child-2
> {code}
> If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
> build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
[
https://issues.apache.org/jira/browse/MJAVADOC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425564#comment-15425564
]
Matt Benson commented on MJAVADOC-471:
--
You might notice that given the example structure, you would expect that
{{foo-child-2}} would depend on {{foo-child-1:tests}} only in {{test}} scope,
and therefore that the problem reported would actually apply not to
{{aggregate}} but instead to {{test-aggregate}}. With this in mind, my
recommendation is that, additionally, {{AbstractJavadocMojo}} should filter
dependencies by scope and my forthcoming patch will reflect this.
> When aggregator filters out artifacts of current reactor projects, only the
> primary artifact is considered
> --
>
> Key: MJAVADOC-471
> URL: https://issues.apache.org/jira/browse/MJAVADOC-471
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Matt Benson
>
> given project structure
> {code}
> foo-parent
> - foo-child-1
> - foo-child-2
> {code}
> If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
> build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
Matt Benson created MJAVADOC-471:
Summary: When aggregator filters out artifacts of current reactor
projects, only the primary artifact is considered
Key: MJAVADOC-471
URL: https://issues.apache.org/jira/browse/MJAVADOC-471
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 2.10.4
Reporter: Matt Benson
given project structure
{code}
foo-parent
- foo-child-1
- foo-child-2
{code}
If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARCHETYPE-507) create-from-project fails on Windows
Matt Benson created ARCHETYPE-507:
-
Summary: create-from-project fails on Windows
Key: ARCHETYPE-507
URL: https://issues.apache.org/jira/browse/ARCHETYPE-507
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.4
Reporter: Matt Benson
When the {{FilesetArchetypeCreator}} attempts to invoke the created project, it
runs afoul of https://issues.apache.org/jira/browse/MSHARED-413 . Solution is
to upgrade the maven-invoker dependency to v2.2; this can be done locally in
the plugin configuration as a workaround.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5601) multimodule plugin configuration e.g. "build-tools" pattern broken
[
https://issues.apache.org/jira/browse/MNG-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055042#comment-15055042
]
Matt Benson commented on MNG-5601:
--
Original prescription is:
{code}
./pom.xml references build-tools, setting for child projects
build-tools/pom.xml parent ..
module1/pom.xml parent ..
module2/pom.xml parent ..
etc.
{code}
To work around:
{code}
./pom.xml
build-tools/pom.xml parent ..
parent/pom.xml parent .. references build-tools, setting for child projects
module1/pom.xml parent ../parent
module2/pom.xml parent ../parent
etc.
{code}
> multimodule plugin configuration e.g. "build-tools" pattern broken
> --
>
> Key: MNG-5601
> URL: https://issues.apache.org/jira/browse/MNG-5601
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Matt Benson
> Attachments: cyclic-ref-test.tar.gz
>
>
> The recommendation at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> breaks down in projects that use the pattern more than once, e.g. for
> checkstyle/findbugs/PMD alike. I have boiled this down to a super-simple test
> project that defines a build-tools module, and in separate profiles declares
> each of these plugins with a dependency on that submodule. Activating any one
> of these profiles and calling `mvn validate` works fine, but as soon as you
> activate two or more of them the command fails with "The projects in the
> reactor contain a cyclic reference".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5776) Drop support for Win9x in mvn launch scripts
[
https://issues.apache.org/jira/browse/MNG-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511465#comment-14511465
]
Matt Benson commented on MNG-5776:
--
Is there another issue open for the broken
{{org.apache.maven.shared.invoker.MavenCommandLineBuilder}} then?
> Drop support for Win9x in mvn launch scripts
> -
>
> Key: MNG-5776
> URL: https://issues.apache.org/jira/browse/MNG-5776
> Project: Maven
> Issue Type: Task
> Components: Command Line
> Environment: Windows
>Reporter: Andreas Gudian
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 3.3.1
>
>
> The scripts mvn.bat / mvnDebug.bat contain a lot of clutter to maintain
> compatibility with Win9x/ME and the "4NT shell".
> Removing support for both will make the scripts a bit more maintainable and
> allow to reduce the duplication found in mvn.bat and mvnDebug.bat, which
> could also be renamed to *.cmd.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MSHADE-167) [PATCH] When individual classes are renamed, they are not debuggable
[
https://jira.codehaus.org/browse/MSHADE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated MSHADE-167:
---
Description:
One can rename a given class using, e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated,
the {{.java}} file will be moved accordingly. The proposed patch changes the
source information in the relocated class to use the new basename of the Java
source file, making it possible to debug again. My Apache ICLA is on file,
rights are granted, and a test of the functionality is included.
was:
you are correct, George, in thatOne can rename a given class using, e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated,
the {{.java}} file will be moved accordingly. The proposed patch changes the
source information in the relocated class to use the new basename of the Java
source file, making it possible to debug again. My Apache ICLA is on file,
rights are granted, and a test of the functionality is included.
> [PATCH] When individual classes are renamed, they are not debuggable
>
>
> Key: MSHADE-167
> URL: https://jira.codehaus.org/browse/MSHADE-167
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Matt Benson
> Attachments: shade-srcfile.patch.txt
>
>
> One can rename a given class using, e.g.:
> {code}
>
> com.example.foo.
> com.uber._foo.__
>
> {code}
> Using the above relocation, {{com.example.foo.Bar}} will be relocated to
> {{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated,
> the {{.java}} file will be moved accordingly. The proposed patch changes the
> source information in the relocated class to use the new basename of the Java
> source file, making it possible to debug again. My Apache ICLA is on file,
> rights are granted, and a test of the functionality is included.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-167) [PATCH] When individual classes are renamed, they are not debuggable
[
https://jira.codehaus.org/browse/MSHADE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated MSHADE-167:
---
Description:
you are correct, George, in thatOne can rename a given class using, e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated,
the {{.java}} file will be moved accordingly. The proposed patch changes the
source information in the relocated class to use the new basename of the Java
source file, making it possible to debug again. My Apache ICLA is on file,
rights are granted, and a test of the functionality is included.
was:
One can rename a given class using, e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber._foo.__Bar}} and this is fine. If the source jar is generated, the
{{.java}} file will be moved accordingly. The proposed patch changes the source
information in the relocated class to use the new basename of the Java source
file, making it possible to debug again. My Apache ICLA is on file, rights are
granted, and a test of the functionality is included.
> [PATCH] When individual classes are renamed, they are not debuggable
>
>
> Key: MSHADE-167
> URL: https://jira.codehaus.org/browse/MSHADE-167
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Matt Benson
> Attachments: shade-srcfile.patch.txt
>
>
> you are correct, George, in thatOne can rename a given class using, e.g.:
> {code}
>
> com.example.foo.
> com.uber._foo.__
>
> {code}
> Using the above relocation, {{com.example.foo.Bar}} will be relocated to
> {{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated,
> the {{.java}} file will be moved accordingly. The proposed patch changes the
> source information in the relocated class to use the new basename of the Java
> source file, making it possible to debug again. My Apache ICLA is on file,
> rights are granted, and a test of the functionality is included.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-167) [PATCH] When individual classes are renamed, they are not debuggable
Matt Benson created MSHADE-167:
--
Summary: [PATCH] When individual classes are renamed, they are not
debuggable
Key: MSHADE-167
URL: https://jira.codehaus.org/browse/MSHADE-167
Project: Maven Shade Plugin
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Matt Benson
Attachments: shade-srcfile.patch.txt
One can rename a given class using, e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber._foo.__Bar}} and this is fine. If the source jar is generated, the
{{.java}} file will be moved accordingly. The proposed patch changes the source
information in the relocated class to use the new basename of the Java source
file, making it possible to debug again. My Apache ICLA is on file, rights are
granted, and a test of the functionality is included.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-78) Possibility to rename classes, e.g. to define a name prefix, to avoid classes with same names
[
https://jira.codehaus.org/browse/MSHADE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344055#comment-344055
]
Matt Benson commented on MSHADE-78:
---
Note that you _can_ rename classes, if a bit clumsily, by specifying e.g.:
{code}
com.example.foo.
com.uber._foo.__
{code}
I do agree that there should be some mechanism for smarter relocations. It's
very likely that someone well-versed in the art of Maven plugin configuration
customization could figure out a way to direct the {{ShadeMojo}} to, e.g., use
a custom {{Relocator}} implementation specified by the user.
> Possibility to rename classes, e.g. to define a name prefix, to avoid classes
> with same names
> -
>
> Key: MSHADE-78
> URL: https://jira.codehaus.org/browse/MSHADE-78
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Tim Ducheyne
>Priority: Minor
>
> It would be nice if there was an option to, next to relocating the classes,
> also rename them, for example by giving them a certain prefix.
> Suppose you bundle a third-party lib in your own lib. Suppose a project uses
> your lib and also uses the third-party lib. If you then start looking up
> classes in your IDE, 2 classes with the same name (but different package)
> will pop-up.
> Renaming them would avoid this.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344053#comment-344053
]
Matt Benson commented on MSHADE-120:
Sounds like this should be resolved {{INVALID}}
> createSourceJar does not include sources from current module
>
>
> Key: MSHADE-120
> URL: https://jira.codehaus.org/browse/MSHADE-120
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Saurabh Ajmera
> Attachments: maven-shade-problem-solution.zip, maven-shade-problem.zip
>
>
> {quote}
> In such case the best approach is to create an issue with a sample project
> to reproduce the trouble .
> And the best of the best attaching a patch which fix the issue :-)
> --
> Olivier
> Le 25 mai 2012 17:40, "Saurabh Ajmera" a écrit :
> Hi,
> Is there anyone using the shade plugin? are you facing this issue?
> On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
> Hi,
> I am using the maven shade plugin to produce a jar which includes
> contents of one dependency artifact plus the contents of my current maven
> module, such that the contents of my maven module override the files with
> the same name in the dependency jar.
> The shade plugin generates the jar file correctly as needed. However,
> the source files from the current maven modules does not get included in
> the generated source jar. Am I doing something wrong?
> Following is the extract from my pom.xml
> {code:xml}
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> {code}
> Thank you,
> Saurabh Ajmera.
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5601) multimodule plugin configuration e.g. "build-tools" pattern broken
[ https://jira.codehaus.org/browse/MNG-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MNG-5601: - Attachment: cyclic-ref-test.tar.gz Profiles: cs -> checkstyle pmd -> PMD fb -> findbugs > multimodule plugin configuration e.g. "build-tools" pattern broken > -- > > Key: MNG-5601 > URL: https://jira.codehaus.org/browse/MNG-5601 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 3.2.1 >Reporter: Matt Benson > Attachments: cyclic-ref-test.tar.gz > > > The recommendation at > https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html > breaks down in projects that use the pattern more than once, e.g. for > checkstyle/findbugs/PMD alike. I have boiled this down to a super-simple test > project that defines a build-tools module, and in separate profiles declares > each of these plugins with a dependency on that submodule. Activating any one > of these profiles and calling `mvn validate` works fine, but as soon as you > activate two or more of them the command fails with "The projects in the > reactor contain a cyclic reference". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5601) multimodule plugin configuration e.g. "build-tools" pattern broken
Matt Benson created MNG-5601: Summary: multimodule plugin configuration e.g. "build-tools" pattern broken Key: MNG-5601 URL: https://jira.codehaus.org/browse/MNG-5601 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle Affects Versions: 3.2.1 Reporter: Matt Benson The recommendation at https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html breaks down in projects that use the pattern more than once, e.g. for checkstyle/findbugs/PMD alike. I have boiled this down to a super-simple test project that defines a build-tools module, and in separate profiles declares each of these plugins with a dependency on that submodule. Activating any one of these profiles and calling `mvn validate` works fine, but as soon as you activate two or more of them the command fails with "The projects in the reactor contain a cyclic reference". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-96) [PATCH] JXR Comment handling has several shortcomings
[
https://jira.codehaus.org/browse/JXR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293258#comment-293258
]
Matt Benson commented on JXR-96:
The third issue above, after accounting for wiki markup, is:
* does not handle /\*\*/ construct properly: recognized as javadoc but not
terminated, while it is better interpreted as /\*\[empty\]\*/.
> [PATCH] JXR Comment handling has several shortcomings
> -
>
> Key: JXR-96
> URL: https://jira.codehaus.org/browse/JXR-96
> Project: Maven JXR
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Matt Benson
> Attachments: JXR-96.patch.txt
>
>
> I have identified the following issues:
> * a // comment does not properly mask a subsequent /* on the same line.
> * explicitly tries not to terminate comments if */ is embedded in a string,
> but compilers don't behave this way.
> * does not handle /**/ construct properly: recognized as javadoc but not
> terminated, while it is better interpreted as /*[empty]*/.
> I have addressed these issues + JXR-58 by reworking the comment handling
> code. Formerly the filters were applied { multiline, inline }; my version of
> the code uses { ongoing-multiline, inline, begin-multiline } specifically to
> address the first of the issues noted above. I was unable to find any
> exhaustive tests for this code; please guide me if there is any further
> testing I can provide. I have collapsed the duplicate code in these regions
> as much as possible, and since this project is on maven-parent v21 I believe
> I was justified in replacing the StringBuffers in affected areas with
> StringBuilders (obviously the whole file might benefit minutely from this
> treatment).
--
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] (JXR-96) [PATCH] JXR Comment handling has several shortcomings
[
https://jira.codehaus.org/browse/JXR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXR-96:
---
Attachment: JXR-96.patch.txt
ICLA on file w/ ASF. I grant the ASF license to use these contributions.
> [PATCH] JXR Comment handling has several shortcomings
> -
>
> Key: JXR-96
> URL: https://jira.codehaus.org/browse/JXR-96
> Project: Maven JXR
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Matt Benson
> Attachments: JXR-96.patch.txt
>
>
> I have identified the following issues:
> * a // comment does not properly mask a subsequent /* on the same line.
> * explicitly tries not to terminate comments if */ is embedded in a string,
> but compilers don't behave this way.
> * does not handle /**/ construct properly: recognized as javadoc but not
> terminated, while it is better interpreted as /*[empty]*/.
> I have addressed these issues + JXR-58 by reworking the comment handling
> code. Formerly the filters were applied { multiline, inline }; my version of
> the code uses { ongoing-multiline, inline, begin-multiline } specifically to
> address the first of the issues noted above. I was unable to find any
> exhaustive tests for this code; please guide me if there is any further
> testing I can provide. I have collapsed the duplicate code in these regions
> as much as possible, and since this project is on maven-parent v21 I believe
> I was justified in replacing the StringBuffers in affected areas with
> StringBuilders (obviously the whole file might benefit minutely from this
> treatment).
--
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] (JXR-96) [PATCH] JXR Comment handling has several shortcomings
Matt Benson created JXR-96:
--
Summary: [PATCH] JXR Comment handling has several shortcomings
Key: JXR-96
URL: https://jira.codehaus.org/browse/JXR-96
Project: Maven JXR
Issue Type: Bug
Affects Versions: 2.3, 2.4
Reporter: Matt Benson
Attachments: JXR-96.patch.txt
I have identified the following issues:
* a // comment does not properly mask a subsequent /* on the same line.
* explicitly tries not to terminate comments if */ is embedded in a string,
but compilers don't behave this way.
* does not handle /**/ construct properly: recognized as javadoc but not
terminated, while it is better interpreted as /*[empty]*/.
I have addressed these issues + JXR-58 by reworking the comment handling code.
Formerly the filters were applied { multiline, inline }; my version of the code
uses { ongoing-multiline, inline, begin-multiline } specifically to address the
first of the issues noted above. I was unable to find any exhaustive tests for
this code; please guide me if there is any further testing I can provide. I
have collapsed the duplicate code in these regions as much as possible, and
since this project is on maven-parent v21 I believe I was justified in
replacing the StringBuffers in affected areas with StringBuilders (obviously
the whole file might benefit minutely from this treatment).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://jira.codehaus.org/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283155#comment-283155 ] Matt Benson commented on MNG-5197: -- Argh, please change description to "locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped TRANSITIVE dependency version"! > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://jira.codehaus.org/browse/MNG-5197 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version -- Key: MNG-5197 URL: https://jira.codehaus.org/browse/MNG-5197 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3, 2.2.1 Environment: OSX, Windows 7 Reporter: Matt Benson Attachments: test-versions.tar.gz This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I have opened a new issue since nothing I found while searching could be described in precisely the same way. The test project I am attaching defines three modules: thing1 thing2 thing3 thing1 depends on hamcrest-core 1.2 thing2 depends on thing1 and junit 4.10 thing3 depends on thing2 and junit 4.10 If you install these, you can then view the dependency trees for thing2 and thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. thing3, however, apparently overrides the version back to 1.1, apparently accessed transitively via junit. Thanks to Mark Struberg for his help in isolating this behavior! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2626) XOM 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195639#action_195639 ] Matt Benson commented on MAVENUPLOAD-2626: -- ERH, what say you to this: http://markmail.org/message/bb3t2yifmk2e5ouw ? > XOM 1.2.3 > - > > Key: MAVENUPLOAD-2626 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2626 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Elliotte Rusty Harold > > http://xom.nu/ -- 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-2132) Please add Morph v1.1.1 to the m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140502#action_140502 ] Matt Benson commented on MAVENUPLOAD-2132: -- I was hoping I'd be able to edit this cloned issue. The bundle URL is actually http://morph.sourceforge.net/m2/morph-1.1.1-bundle.jar . Sorry for any inconvenience. Thanks, Matt > Please add Morph v1.1.1 to the m2 repo > -- > > Key: MAVENUPLOAD-2132 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2132 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Matt Benson >Assignee: Carlos Sanchez > > I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2132) Please add Morph v1.1.1 to the m2 repo
Please add Morph v1.1.1 to the m2 repo -- Key: MAVENUPLOAD-2132 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2132 Project: Maven Upload Requests Issue Type: Wish Reporter: Matt Benson Assignee: Carlos Sanchez I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2103) Please add Morph v1.1 to the m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140455#action_140455 ] Matt Benson commented on MAVENUPLOAD-2103: -- Thanks for the quick response. :) > Please add Morph v1.1 to the m2 repo > > > Key: MAVENUPLOAD-2103 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2103 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Matt Benson >Assignee: Carlos Sanchez > > I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-2103) Please add Morph v1.1 to the m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson reopened MAVENUPLOAD-2103: -- Many apologies, but it has been brought to my attention that one of the dependencies declared in the POM had a bad group id. I have placed an updated bundle at the same location as the original. Please let me know if there is anything else I need to do to get this POM corrected (the jar is unchanged). Thanks, Matt > Please add Morph v1.1 to the m2 repo > > > Key: MAVENUPLOAD-2103 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2103 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Matt Benson >Assignee: Carlos Sanchez > > I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2101) Please add Composite v1.1 to the m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138785#action_138785 ] Matt Benson commented on MAVENUPLOAD-2101: -- Thanks! > Please add Composite v1.1 to the m2 repo > > > Key: MAVENUPLOAD-2101 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2101 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Matt Benson >Assignee: Carlos Sanchez > > On the contributor URL page, the "Project Details" section lists > "orangeherbert" as a Project Admin. If you follow that link you can see that > orangeherbert == "Matt Benson". Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2103) Please add Morph v1.1 to the m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138784#action_138784 ] Matt Benson commented on MAVENUPLOAD-2103: -- Thanks! > Please add Morph v1.1 to the m2 repo > > > Key: MAVENUPLOAD-2103 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2103 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Matt Benson >Assignee: Carlos Sanchez > > I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2103) Please add Morph v1.1 to the m2 repo
Please add Morph v1.1 to the m2 repo Key: MAVENUPLOAD-2103 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2103 Project: Maven Upload Requests Issue Type: Wish Reporter: Matt Benson I am user orangeherbert, Project Admin for this sf.net project. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2101) Please add Composite v1.1 to the m2 repo
Please add Composite v1.1 to the m2 repo Key: MAVENUPLOAD-2101 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2101 Project: Maven Upload Requests Issue Type: Wish Reporter: Matt Benson On the contributor URL page, the "Project Details" section lists "orangeherbert" as a Project Admin. If you follow that link you can see that orangeherbert == "Matt Benson". Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
