[jira] (DOXIA-298) Confluence: Problem with relative links
[ https://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300128#comment-300128 ] Valters Vingolds commented on DOXIA-298: It seems this patch breaks possibility to link to a file, because .html is now appended to all links. I can't link to .pdf file for example. Confluence: Problem with relative links --- Key: DOXIA-298 URL: https://jira.codehaus.org/browse/DOXIA-298 Project: Maven Doxia Issue Type: Improvement Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Assignee: Lukas Theussl Fix For: 1.1.1 Attachments: MNG-298-module-confluence.patch, MNG-298-module-confluence.patch Relative links, for example [Overview|overview/index] are not generated correctly. -- 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] (DOXIA-466) confluence: can't create links to non-html resources (like .pdf of .xls files) because .html is always appended
Valters Vingolds created DOXIA-466: -- Summary: confluence: can't create links to non-html resources (like .pdf of .xls files) because .html is always appended Key: DOXIA-466 URL: https://jira.codehaus.org/browse/DOXIA-466 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.3 Reporter: Valters Vingolds Attachments: confluence-resource-links.patch Currently when trying to create link to (for example) resource.pdf file, the link is lways generated as resource.pdf.html. This seems to be a regression introduced by DOXIA-298 anchors handling. As workaround, I propose to use the Confluence's attached files [^resource.file] syntax. If ^ is in front of link, treat link as verbatim. Attaching the patch implementing this proposal. -- 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] (DOXIA-298) Confluence: Problem with relative links
[ https://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300140#comment-300140 ] Lukas Theussl commented on DOXIA-298: - Please open a new ticket, link back to this one and provide a concrete example to reproduce the issue. Confluence: Problem with relative links --- Key: DOXIA-298 URL: https://jira.codehaus.org/browse/DOXIA-298 Project: Maven Doxia Issue Type: Improvement Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Assignee: Lukas Theussl Fix For: 1.1.1 Attachments: MNG-298-module-confluence.patch, MNG-298-module-confluence.patch Relative links, for example [Overview|overview/index] are not generated correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-766) release:prepare stores settings.xml in a public directory
[
https://jira.codehaus.org/browse/MRELEASE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300141#comment-300141
]
Robert Scholte commented on MRELEASE-766:
-
Have you seen this happening or is it just a theory? All {{MavenExecutors}}
contain the following:
{code}
try
{
//
}
finally
{
if ( settingsFile != null settingsFile.exists() !settingsFile.delete() )
{
settingsFile.deleteOnExit();
}
}
{code}
release:prepare stores settings.xml in a public directory
-
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent
other users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-763) release:prepare ignores invalid dependencies in inactive profiles
[
https://jira.codehaus.org/browse/MRELEASE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-763:
Issue Type: Improvement (was: Bug)
I see your point, but this means we have to do all the dependency-resolution of
profiles inside the maven-release-plugin. And not just project-dependencies,
but also plugin-dependencies, report-dependencies, extensions, etc.
Sounds more like an improvement to me.
release:prepare ignores invalid dependencies in inactive profiles
-
Key: MRELEASE-763
URL: https://jira.codehaus.org/browse/MRELEASE-763
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.3
Reporter: Mark Hobson
{{release:prepare}} completes successfully on projects that contain invalid
dependencies in inactive profiles.
For example, a POM containing the following profile containing a non-existent
dependency will prepare without problems:
{code}
...
profiles
profile
idsilly/id
dependencies
dependency
groupIdsilly/groupId
artifactIdsilly/artifactId
version1.0/version
/dependency
/dependencies
/profile
/profiles
...
{code}
Furthermore, if this dependency was changed to a SNAPSHOT version then it
would still succeed. I would expect {{prepare}} to fail in both cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-761) [regression] release:rollback no longer works
[
https://jira.codehaus.org/browse/MRELEASE-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MRELEASE-761:
---
Assignee: Robert Scholte
[regression] release:rollback no longer works
-
Key: MRELEASE-761
URL: https://jira.codehaus.org/browse/MRELEASE-761
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: rollback
Affects Versions: 2.3
Reporter: Mark Hobson
Assignee: Robert Scholte
{{release:rollback}} no longer reverts POM changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-761) [regression] release:rollback no longer works
[
https://jira.codehaus.org/browse/MRELEASE-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-761.
---
Resolution: Fixed
Fix Version/s: 2.4
Fixed in [r1344836|http://svn.apache.org/viewvc?rev=1344836view=rev]
[regression] release:rollback no longer works
-
Key: MRELEASE-761
URL: https://jira.codehaus.org/browse/MRELEASE-761
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: rollback
Affects Versions: 2.3
Reporter: Mark Hobson
Assignee: Robert Scholte
Fix For: 2.4
{{release:rollback}} no longer reverts POM changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-635) perform does not honor updateWorkingCopiesVersion setting
[
https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300145#comment-300145
]
Robert Scholte commented on MRELEASE-635:
-
I guess you meant {{release:prepare}}, right?
perform does not honor updateWorkingCopiesVersion setting
-
Key: MRELEASE-635
URL: https://jira.codehaus.org/browse/MRELEASE-635
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Reporter: Scott Carey
release:perform modifies the working copies version when configured not to.
This was a tag directly from trunk.
configuration
autoVersionSubmodulestrue/autoVersionSubmodules
remoteTaggingfalse/remoteTagging
suppressCommitBeforeTagtrue/suppressCommitBeforeTag
suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch
updateBranchVersionstrue/updateBranchVersions
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
/configuration
Happens in both dryRun mode and normal.
After a non-dryRun pom.xml.releaseBackup files are left behind as well.
The desired behavior is to leave the working copy alone and only modify the
tag. Currently, with suppressCommitBeforeTag true, this is possible by
reverting the local changes left behind by running release:perform.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-760) updateWorkingCopyVersions=false still bumps up pom versions to next development version
[ https://jira.codehaus.org/browse/MRELEASE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-760. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Robert Scholte Fixed in [r1344903|http://svn.apache.org/viewvc?rev=1344903view=rev] updateWorkingCopyVersions=false still bumps up pom versions to next development version --- Key: MRELEASE-760 URL: https://jira.codehaus.org/browse/MRELEASE-760 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3 Reporter: Joeri Leemans Assignee: Robert Scholte Fix For: 2.4 Attachments: maven-release-plugin-testcase.zip The flag updateWorkingCopyVersions (more specifically with value false) is not handled correctly. Attached project is a simple Maven project with version 1.0-SNAPSHOT, depending on version 2.3 of the release plugin. It is configured with dryRun=true and updateWorkingCopyVersions=false. When running mvn:prepare (and accepting the versions that are proposed), you'll see that pom.xml.next file contains 1.1-SNAPSHOT (the next development version) instead of 1.0 (the tagged version). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MRELEASE-674:
-
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Fix For: 2.4
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-674.
---
Resolution: Fixed
Sounds to me you should use {{updateWorkingCopyVersions=false}}. MRELEASE-760
has been fixed, so this should work with the next release.
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Fix For: 2.4
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-674.
---
Resolution: Won't Fix
Fix Version/s: (was: 2.4)
Marking this as {{won't fix}}, since there's another parameter which should be
used.
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-525) Update-versions does not work in batch mode
[
https://jira.codehaus.org/browse/MRELEASE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300149#comment-300149
]
Robert Scholte commented on MRELEASE-525:
-
Could this be a duplicate of MRELEASE-760?
Update-versions does not work in batch mode
---
Key: MRELEASE-525
URL: https://jira.codehaus.org/browse/MRELEASE-525
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.0
Environment: Maven 2.2.1
Reporter: Damien Coraboeuf
When I run the {{release:update-versions}} goal in batch mode, it performs
the transformation and just cleans the things up...
Command which is executed:
{{mvn -B release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=0.4.0}}
The output looks like:
{noformat}
[INFO] Transforming 'ModuleA'...
[INFO] Transforming 'ModuleB'...
[INFO] Cleaning up after release...
{noformat}
If I run the command in interactive mode, everything goes fine:
{{mvn -B release:update-versions -DautoVersionSubmodules=true}}
It asks the version on the prompt and updates the pom files accordingly.
Any idea?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-766) release:prepare stores settings.xml in a public directory
[
https://jira.codehaus.org/browse/MRELEASE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300153#comment-300153
]
Joseph Walton commented on MRELEASE-766:
I've seen it happening. It's possible that the build was hung, rather than
failed, so it hadn't cleaned up. It's also possible that the JVM was killed.
But while this finally block will reduce the window the file is public for it
won't eliminate it, so I think there's room for an improvement here.
release:prepare stores settings.xml in a public directory
-
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent
other users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
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] (MPLUGIN-109) Misleading warning when creating a Maven plugin defining a custom packaging
[
https://jira.codehaus.org/browse/MPLUGIN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300156#comment-300156
]
Brett Porter commented on MPLUGIN-109:
--
This is no longer the case - you can configure
{{skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound}} to avoid
the error. This is preferable to using the {{jar}} packaging type, as when that
is used as a plugin it warns about a missing plugin descriptor on every build.
Misleading warning when creating a Maven plugin defining a custom packaging
---
Key: MPLUGIN-109
URL: https://jira.codehaus.org/browse/MPLUGIN-109
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 2.4.1
Reporter: Ludovic Claude
Assignee: John Casey
Priority: Minor
Fix For: 2.5
Attachments: console.log, test-custom-packaging.zip
When creating a custom packaging using the 2.4.1 version of the
maven-plugin-plugin, I'm getting the following warning message:
[INFO] Building foobar-maven-plugin
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[WARNING]
[WARNING]
[WARNING] ***
[WARNING] Deprecation Alert:
[WARNING] No mojo descriptors were found in this project which has a
packaging type of maven-plugin.
[WARNING] In future versions of the plugin tools, this will fail the build.
[WARNING] If this project is an archetype, change the packaging type from
maven-plugin to maven-archetype.
[WARNING]
Indeed, my project contains no Mojos, only a plexus components.xml file. Now
if you try to enforce a rule that says that a maven-plugin must contain at
least one Mojo (see MPLUGIN-106), that's fine, but which packaging am I
supposed to use to create a plugin that defines a new packaging (here, the
foobar packaging)
--
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] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[ https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=39#comment-39 ] Joseph Walton edited comment on MSHADE-103 at 6/1/12 12:23 AM: --- -This doesn't seem to occur with Maven 3.0.4. Could it be due to- MNG-5149 -or- MNG-5224? Sorry, I'm still seeing this with 3.0.4. was (Author: joewalton): This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149 or MNG-5224? maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3, 1.4 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] - [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- 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] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MSHADE-103:
-
Attachment: MSHADE-103.tar.gz
I have a case where the remote repository is a local directory and the local
repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
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] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300161#comment-300161
]
Joseph Walton edited comment on MSHADE-103 at 6/1/12 12:34 AM:
---
I have a case where the remote repository is a local directory and the local
repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds. Shading also succeeds when createDependencyReducedPom is set to false.
was (Author: joewalton):
I have a case where the remote repository is a local directory and the
local repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
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
