[jira] (MSHADE-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
Shay Banon created MSHADE-123: - Summary: 1.7 Causes failures in other plugins make "basedir" point to the build dir Key: MSHADE-123 URL: https://jira.codehaus.org/browse/MSHADE-123 Project: Maven 2.x Shade Plugin Issue Type: Bug Reporter: Shay Banon Priority: Blocker Upgrading the 1.7 causes other plugins to have basedir now pointing to build dir, or something similar. The attached test case shows that with shade plugin 1.5, the assembly plugins successfully finds the sample.txt file (in basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not to find it. -- 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-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
[ https://jira.codehaus.org/browse/MSHADE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shay Banon updated MSHADE-123: -- Attachment: mvn-shade.zip Attached the project, simply extract and run, you will see the failure. Change the shade version to 1.5, and it works well. > 1.7 Causes failures in other plugins make "basedir" point to the build dir > -- > > Key: MSHADE-123 > URL: https://jira.codehaus.org/browse/MSHADE-123 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Shay Banon >Priority: Blocker > Attachments: mvn-shade.zip > > > Upgrading the 1.7 causes other plugins to have basedir now pointing to build > dir, or something similar. The attached test case shows that with shade > plugin 1.5, the assembly plugins successfully finds the sample.txt file (in > basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not > to find it. -- 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-619) release:branch doesn't work as expected with multi-module projects
[ https://jira.codehaus.org/browse/MRELEASE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-619. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Robert Scholte Fixed in [r1353151|http://svn.apache.org/viewvc?rev=1353151&view=rev] Thanks! > release:branch doesn't work as expected with multi-module projects > --- > > Key: MRELEASE-619 > URL: https://jira.codehaus.org/browse/MRELEASE-619 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0, 2.1 >Reporter: Emilio Jose Mena Cebrian >Assignee: Robert Scholte > Fix For: 2.4 > > Attachments: ScmBranchPhase.java.patch > > > The goal release:branch doesn't work as release:prepare with multi-module > projects with flat layout (with parent project and modules at same level in > URL path) > While release:prepare takes into account the project layout using > ReleaseUtil.createBasedirAlignedReleaseDescriptor, the goal release:branch > doesn't > The involved calss is org.apache.maven.shared.release.phase.ScmBranchPhase > which is similar to org.apache.maven.shared.release.phase.ScmTagPhase, so > I've assumed I can invoke ReleaseUtil.createBasedirAlignedReleaseDescriptor > to obtain the corrected ReleaseDescriptor. > I've corrected this behaviour in a local copy of maven-release-manager module > and seems to work, but i have not fully tested the patch > The patch is relative to maven-release-manager module -- 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-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
[ https://jira.codehaus.org/browse/MSHADE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MSHADE-123: --- Assignee: Benson Margulies > 1.7 Causes failures in other plugins make "basedir" point to the build dir > -- > > Key: MSHADE-123 > URL: https://jira.codehaus.org/browse/MSHADE-123 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Shay Banon >Assignee: Benson Margulies >Priority: Blocker > Attachments: mvn-shade.zip > > > Upgrading the 1.7 causes other plugins to have basedir now pointing to build > dir, or something similar. The attached test case shows that with shade > plugin 1.5, the assembly plugins successfully finds the sample.txt file (in > basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not > to find it. -- 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-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
[ https://jira.codehaus.org/browse/MSHADE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301765#comment-301765 ] Benson Margulies commented on MSHADE-123: - OK, I see how this happens. The question is going to be how to fix it. The d-r-p becomes 'the pom', and its location is now in target to avoid build collisions, but now basedir tracks it. I believe I can fix this by fixing the basedir for the d-r-p model. > 1.7 Causes failures in other plugins make "basedir" point to the build dir > -- > > Key: MSHADE-123 > URL: https://jira.codehaus.org/browse/MSHADE-123 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Shay Banon >Assignee: Benson Margulies >Priority: Blocker > Attachments: mvn-shade.zip > > > Upgrading the 1.7 causes other plugins to have basedir now pointing to build > dir, or something similar. The attached test case shows that with shade > plugin 1.5, the assembly plugins successfully finds the sample.txt file (in > basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not > to find it. -- 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-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
[ https://jira.codehaus.org/browse/MSHADE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301767#comment-301767 ] Benson Margulies commented on MSHADE-123: - Workaround: explicitly set the location of the dependency-reduced-pom to be in the basedir instead of in target. > 1.7 Causes failures in other plugins make "basedir" point to the build dir > -- > > Key: MSHADE-123 > URL: https://jira.codehaus.org/browse/MSHADE-123 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Shay Banon >Assignee: Benson Margulies >Priority: Blocker > Attachments: mvn-shade.zip > > > Upgrading the 1.7 causes other plugins to have basedir now pointing to build > dir, or something similar. The attached test case shows that with shade > plugin 1.5, the assembly plugins successfully finds the sample.txt file (in > basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not > to find it. -- 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-123) 1.7 Causes failures in other plugins make "basedir" point to the build dir
[ https://jira.codehaus.org/browse/MSHADE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301766#comment-301766 ] Benson Margulies commented on MSHADE-123: - Drat. project.getBasedir() returns the parent dir of the pom file, period, alternative. This seems to require a change to the MavenProject class. > 1.7 Causes failures in other plugins make "basedir" point to the build dir > -- > > Key: MSHADE-123 > URL: https://jira.codehaus.org/browse/MSHADE-123 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Shay Banon >Assignee: Benson Margulies >Priority: Blocker > Attachments: mvn-shade.zip > > > Upgrading the 1.7 causes other plugins to have basedir now pointing to build > dir, or something similar. The attached test case shows that with shade > plugin 1.5, the assembly plugins successfully finds the sample.txt file (in > basedir), while upgrading to 1.7 shade plugin causes the assembly plugin not > to find it. -- 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] (MRESOURCES-169) Silently fails to import properties from a properties file
[
https://jira.codehaus.org/browse/MRESOURCES-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301768#comment-301768
]
Tim Pizey commented on MRESOURCES-169:
--
The problem seems to be in the tomcat plugin - the variables are in the
context, but the tomcat plugin is only reading the initial context, not the
final one.
> Silently fails to import properties from a properties file
> --
>
> Key: MRESOURCES-169
> URL: https://jira.codehaus.org/browse/MRESOURCES-169
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Components: filtering
> Environment: ubuntu/openjdk6/maven 3.0.4
>Reporter: Tim Pizey
>
> I have tried inherited from parent, defined in pom and with and without
> encoding:
>
> org.apache.maven.plugins
> maven-resources-plugin
> 2.5
>
> ${project.build.sourceEncoding}
>
>
> invoked with
>
> /etc/${project.artifactId}/repository.properties
>
> This fails if the file does not exist, but if it does exist the properties
> are not included.
> I have tried the properties file as a normal key=value file and as an XML
> properties file.
> This mechanism would be REALLY useful if it worked, as it would enable
> passwords not to be stored in our SCM, nor in settings.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] (MRESOURCES-169) Silently fails to import properties from a properties file
[
https://jira.codehaus.org/browse/MRESOURCES-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Pizey closed MRESOURCES-169.
Resolution: Not A Bug
Fix Version/s: 2.5
The symptom, Tomcat plugin not seeing properties, is not caused by the
resources plugin.
> Silently fails to import properties from a properties file
> --
>
> Key: MRESOURCES-169
> URL: https://jira.codehaus.org/browse/MRESOURCES-169
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Components: filtering
> Environment: ubuntu/openjdk6/maven 3.0.4
>Reporter: Tim Pizey
> Fix For: 2.5
>
>
> I have tried inherited from parent, defined in pom and with and without
> encoding:
>
> org.apache.maven.plugins
> maven-resources-plugin
> 2.5
>
> ${project.build.sourceEncoding}
>
>
> invoked with
>
> /etc/${project.artifactId}/repository.properties
>
> This fails if the file does not exist, but if it does exist the properties
> are not included.
> I have tried the properties file as a normal key=value file and as an XML
> properties file.
> This mechanism would be REALLY useful if it worked, as it would enable
> passwords not to be stored in our SCM, nor in settings.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] (MSKINS-40) left column is too big since fluido 1.2
[ https://jira.codehaus.org/browse/MSKINS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-40. Resolution: Fixed Fix Version/s: fluido-1.2.2 Assignee: Robert Scholte Fixed in [r1353177|http://svn.apache.org/viewvc?rev=1353177&view=rev] > left column is too big since fluido 1.2 > --- > > Key: MSKINS-40 > URL: https://jira.codehaus.org/browse/MSKINS-40 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.2, fluido-1.2.1 >Reporter: Herve Boutemy >Assignee: Robert Scholte > Fix For: fluido-1.2.2 > > > if you compare the rendered result from > 1. fuido 1.1: http://maven.apache.org/skins/maven-fluido-skin-1.1/ > 2. and fluido 1.2: http://maven.apache.org/skins/maven-fluido-skin-1.2/ > the left column was well sized in 1.1 but has grown in 1.2 for non-obvious > reasons -- 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] (MSKINS-41) Links from site.xml are rendered in reverse order
[
https://jira.codehaus.org/browse/MSKINS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSKINS-41.
Resolution: Fixed
Fix Version/s: fluido-1.2.2
Assignee: Robert Scholte
Fixed in [r1353196|http://svn.apache.org/viewvc?rev=1353196&view=rev]
Thanks for the patch!
> Links from site.xml are rendered in reverse order
> --
>
> Key: MSKINS-41
> URL: https://jira.codehaus.org/browse/MSKINS-41
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.2
>Reporter: Andreas Sewe
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: fluido-1.2.2
>
> Attachments: mskins-41-it.patch
>
>
> If one defines multiple links in the {{site.xml}} (project/body/links/item),
> they are rendered in reverse order, i.e., what comes first in the
> {{site.xml}} comes last in the rendered page.
--
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] (MSKINS-54) Upgrade to bootstrap-2.0.4
Robert Scholte created MSKINS-54: Summary: Upgrade to bootstrap-2.0.4 Key: MSKINS-54 URL: https://jira.codehaus.org/browse/MSKINS-54 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.2.1 Reporter: Robert Scholte -- 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] (MSKINS-51) Github ribbon image broken
[ https://jira.codehaus.org/browse/MSKINS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301772#comment-301772 ] Orien Madgwick commented on MSKINS-51: -- These URLs still work: https://github.com/blog/273-github-ribbons > Github ribbon image broken > -- > > Key: MSKINS-51 > URL: https://jira.codehaus.org/browse/MSKINS-51 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.2.1 >Reporter: Julien Nicoulaud > > The Github ribbon image has changed address (example here: > http://nicoulaj.github.com/checksum-maven-plugin) -- 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
