[jira] (MJAVADOC-379) Reactor order changed
Frank Cornelis created MJAVADOC-379: --- Summary: Reactor order changed Key: MJAVADOC-379 URL: https://jira.codehaus.org/browse/MJAVADOC-379 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.8 Environment: Maven 3.1.1, Maven javadoc plugin 2.8, 2.9.1 Reporter: Frank Cornelis For somehow reason the maven-javadoc-plugin changes the build order when doing: mvn clean install site site:stage Causing the build to fail of course. Had to switch back to maven-javadoc-plugin version 2.7. PS: first make sure that the local maven repo does not contain the artifacts that you're about to build. This bug also makes the maven-release-plugin to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-96) Skip option for install-file
[
https://jira.codehaus.org/browse/MINSTALL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334340#comment-334340
]
Robert Scholte commented on MINSTALL-96:
I'm not sure if the conditional/dynamic stuff is really that weak. The
{{}}-tag for plugins is powerfull when you understand how to use
it. If you combine it with the [combine.*
attributes|http://blog.sonatype.com/people/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects]
inside the configuration, almost every combination is possible. But this
requires the
{{sourcestests}}
format, as most plugins do at both Apache Maven and Codehaus Mojo.
I don't understand the issue of not knowing classifiers beforehand. One should
know what is attachted right? It won't be a problem, if the exclude contains
classifiers, which don't exist.
> Skip option for install-file
>
>
> Key: MINSTALL-96
> URL: https://jira.codehaus.org/browse/MINSTALL-96
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install-file
>Affects Versions: 2.4
>Reporter: Tiemo Vorschütz
> Attachments: InstallFileMojo.java.patch
>
>
> For my process it would be helpful to also introduce a skip option for
> install:install-file to be able to disable install-file creation by setting a
> pom property.
> This could be necessary if the build chain is designed by a parent pom and
> should by simply modified inside the child pom.
> In my case all plugin definitions are outsourced to the parent pom file and
> should only be set by properties by the developers to take care that
> modifications to the build chain are inherited.
> I attached a patch to enable skipping also for install-file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-798) Commit additional files with release plugin
[ https://jira.codehaus.org/browse/MRELEASE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334338#comment-334338 ] Robert Scholte commented on MRELEASE-798: - Since it's a workaround I'm not going to accept the pullrequest, because these Maven plugins must stay backwards compatible. There's no such thing as a temporary workaround, but users are free to use your fork of course. I haven't collected all the requirements, but I think your idea is indeed a good start. Very clever to think of the rollback as well. > Commit additional files with release plugin > --- > > Key: MRELEASE-798 > URL: https://jira.codehaus.org/browse/MRELEASE-798 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare, scm >Affects Versions: 2.3.2 >Reporter: Thorsten Hoeger > Attachments: maven-release-2.4.1-additionalCommitted.patch > > > Hi, > is there any possibility to have the release-plugin commit additional files > which were > generated/modified in the preparationGoals. > Now only the pom.xml is commited. Using scm-plugin has some serious drawbacks > in this > situation. > If it is not possible at the moment, is there any chance to get this in the > future. Maybe > there could be a parameter additionalCommitFiles with a list of files to > commit along with > pom.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-365) Filtered directory filesets try to include files from ancestor projects in a multi-module build
[
https://jira.codehaus.org/browse/MASSEMBLY-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334337#comment-334337
]
Brian Brooks commented on MASSEMBLY-365:
I just lost an hour of time due to this defect. The ${basedir} workaround
worked for me.
> Filtered directory filesets try to include files from ancestor projects in a
> multi-module build
> ---
>
> Key: MASSEMBLY-365
> URL: https://jira.codehaus.org/browse/MASSEMBLY-365
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.2-beta-2
> Environment: Mac OS X 10.5.5, Java 1.5.0_16, Maven 2.0.9
>Reporter: Christopher Maier
>Priority: Minor
> Attachments: assembly-bug.tar.bz
>
>
> When interpreting assembly descriptors, it looks like Maven is resolving
> fileSet directories relative to where the build was started, rather than
> relative to the project or module the descriptor is defined in. This might
> cause problems in multi-module builds where a file exists in the same
> directory listed in the descriptor, but in an ancestor module. The attached
> file has a small project that illustrates this. This project has one
> sub-module, in which an assembly descriptor is defined. It declares a
> {{fileSet}}, using the {{directory}} tag, that points to {{src/main/shell}}.
> There is a shell file here ({{b.sh}}) that is to be included in the assembly.
> There is a also a {{src/main/shell}} directory in the parent project as
> well, containing a file ({{a.sh}}) that does not exist in the shell directory
> of the sub-module. The assembly plugin is attached to the package phase.
> When the sub-module is built from its own directory, everything works as
> expected. However, if it is built from the parent directory as part of a
> reactor build, Maven complains that it cannot find {{a.sh}} in the
> sub-module's {{src/main/shell directory}}.
> This looks like it only happens if the assembly specifies that the
> {{fileSet}} be filtered.
> There is an easy workaround; instead of setting the directory as
> {{src/main/shell}}, use {{${basedir}/src/main/shell}} in the assembly
> descriptor. I discovered this behavior when I was transitioning one of my
> projects from a single project to a multi-module project, and I left some
> files behind in the new parent project. I'm going to get rid of those
> eventually, and I realize this is probably a pathological structure, but this
> behavior is unexpected and may impact other, less pathological projects.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-87) Add possibility to refer to external CSS in fluido skin configuration
Laurent Gauthier created MSKINS-87: -- Summary: Add possibility to refer to external CSS in fluido skin configuration Key: MSKINS-87 URL: https://jira.codehaus.org/browse/MSKINS-87 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Laurent Gauthier This is a proposed and tested enhancement to the fluido skin custom config to allow the addition of one or more links to CSS files in generated html. The enhanced custom config supports a element as in the following example: true     http://server.name.domaine/path/to/stylesheet.css     The site.vm velocity template file must be modified to include the following snippet at line 783 (v1.3.0): #if ( $decoration.custom.getChild( 'fluidoSkin' )    && $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'cssLinks' ))   #foreach( $item in $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'cssLinks').getChildren() )                 #end      #end -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
