On 31 August 2011 13:25, Olivier Lamy <ol...@apache.org> wrote:
> 2011/8/31 sebb <seb...@gmail.com>:
>> On 31 August 2011 11:27, Olivier Lamy <ol...@apache.org> wrote:
>>> 2011/8/31 sebb <seb...@gmail.com>:
>>>> On 31 August 2011 08:29, Olivier Lamy <ol...@apache.org> wrote:
>>>>> Hello,
>>>>> The solution I see is to have an artifact (call it build-resources or
>>>>> something like that) which contains those .properties
>>>>
>>>> The modules all have a common parent pom - is it possible to use that
>>>> to contain the resources, rather than creating another module?
>>>>
>>>>> And use it tru remote-resources or dependency plugin.
>>>>
>>>> The remote-resources sharing example shows that the resources will be
>>>> made available under
>>>>
>>>> ${project.build.directory}/maven-shared-archive-resources
>>>>
>>>> but the reports customBundle expects to find the file under
>>>>
>>>> ${project.basedir}/src/site/custom/project-info-report.properties
>>>>
>>>> Looks like I would also have to configure the reports to pick up the
>>>> custom bundle from elsewhere, or change the outputDirectory (but that
>>>> would probably mess up the packaging/assembly phases).
>>>>
>>>> Seems simpler to just create copies of the bundle in each module in
>>>> the first place.
>>>>
>>>> I'm not sure how to use the dependency plugin - how do I configure the
>>>> reports to pick up the properties from a jar?
>>>
>>> use the dependency to unpack you properties file from your
>>> artifact/jar to a dedicated path in your project.
>>
>> I see - much the same as using remote-resources to unpack the file.
>>
>>> Then configure the mojo.
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-project-info-reports-plugin</artifactId>
>>> <configuration>
>>> <customBundle>path to unpacked properties file</customBundle>
>>> </configuration>
>>> </plugin>
>>>
>>> IMHO a little complicated and a lot of xml to write but should work
>>> (not tested).
>>
>> I assume that the report mojo can be configured once in the parent?``
> Yup as other plugins configured it's inherited
>> Otherwise it's a lot more work.
>>
>> And each module has to unpack the file locally.
>>
>>> I would prefer add a feature for the maven-project-info-reports-plugin
>>> (and maybe others) to be able to load properties file from
>>> artifact/jar with adding this artifact/jar in the plugin
>>> configuration.
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-project-info-reports-plugin</artifactId>
>>> <configuration>
>>> <customBundleArtifact>
>>> <artifact>org.foo:my-properties:1.0</artifact>
>>> <customBundlePath>path in the jar</customBundlePath>
>>> </customBundleArtifact>
>>> </configuration>
>>> </plugin>
>>>
>>> Makes sense ? (less xml than using dependency unpack)
>>
>> This is a generic solution and would simplify the process somewhat,
>> but one would still have to create and deploy the properties artifact.
>>
>> I would expect the reports plugin to be able to inherit properties
>> directly from the parent pom.
>>
>> Rather like the site.xml can be inherited.
>
> AFAIK site descriptor is an "artifact" which is deployed too.
> So the site plugin use the parent if found in the path tree if not one
> the needed one is downloaded.
Somehow the site.xml file is copied to the Maven repo alongside the POM.
This is presumably how it is found by depending projects.
Something similar needs to happen with the custom properties.
> In our case, I see an issue with the case of a classic svn tree.
>
> parent
> /src/main/resources/mybundle.properties
> child1
>
> With using ${project.basedir}/src/site/custom/project-info-report.properties
> a hack is possible to look at
> ${parent.baseDir}/src/site/custom/project-info-report.properties.
>
> This hack exists in the checkstyle plugin
> (http://jira.codehaus.org/browse/MCHECKSTYLE-131) but personnally I
> don't want to reproduce it.
> Because it doesn't work as maven does for everything else and cause
> some confusions.
>
> And what happend when checkout only the submodule child1 and not all
> the tree (your files won't be found).
Yes, that is a problem.
> See the case of the release plugin : only the submodule subtree is
> retrieve from svn this means your release will fail.
>
> And using a "build-tools-configuration" is IMHO a better way to do
> this. As your configuration files will be reusable everywhere even
> outside of the sources tree where they are located.
> See sample here :
> http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
That looks as though it might work for custom properties, but it is
still extra work compared with how site.xml is inherited.
> If you have time to load a jira entry for the feature, I will work on.
Will do.
>>
>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend : http://talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> 2011/8/31 sebb <seb...@gmail.com>:
>>>>>> On 23 August 2011 14:43, sebb <seb...@gmail.com> wrote:
>>>>>>> The default customBundle is located at
>>>>>>>
>>>>>>> ${project.basedir}/src/site/custom/project-info-report.properties
>>>>>>>
>>>>>>> which works fine for single module projects.
>>>>>>>
>>>>>>> However, it does not seem to work for multi-module projects.
>>>>>>>
>>>>>>> How can one share the same bundle between multiple modules?
>>>>>>>
>>>>>>> The modules all share a common parent, but do not seem to pick up the
>>>>>>> bundle from the parent.
>>>>>>
>>>>>> Anyone?
>>>>>>
>>>>>> Or is the only solution to duplicate the bundle in all projects?
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend : http://talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
