Maven 1.x Changes Plugin

Make it possible to configure the location of the changes.xml file

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.7
  • Fix Version/s: 1.7.1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

It is useful for people that are in a transition from Maven 1 to Maven 2 to be able to move the changes.xml file to another location that the default one. The attached patch introduces a new property "maven.changes.file" that can be used to configure the location of the file. The default value is the same as what has been used in the previous versions.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dennis Lundberg added a comment -

It would be nice if someone could review the patch. I can take care of committing it, if it passes the review.

Show
Dennis Lundberg added a comment - It would be nice if someone could review the patch. I can take care of committing it, if it passes the review.
Hide
Permalink
Arnaud Heritier added a comment -

It's good. Go for it. Thx.

Show
Arnaud Heritier added a comment - It's good. Go for it. Thx.
Hide
Permalink
Lukas Theussl added a comment -

Be careful: changes.xml is used hard-coded in at least the following plugins: announcement, changelog, multichanges, scm and xdoc. In particular, I recently fixed the related MPSCM-86. I think the location of the file should be ${maven.docs.src} and only the filename should be configurable. WDYT?

Show
Lukas Theussl added a comment - Be careful: changes.xml is used hard-coded in at least the following plugins: announcement, changelog, multichanges, scm and xdoc. In particular, I recently fixed the related MPSCM-86. I think the location of the file should be ${maven.docs.src} and only the filename should be configurable. WDYT?
Hide
Permalink
Arnaud Heritier added a comment -

Good catch !!! We have to update/release all these plugins.
We have to be able to put the changes.xml somewhere else because in maven 2, the directory (maven.docs.src) must contains only xdocs files (there's one directory per file type). It's the same problem for the navigation.xml

Show
Arnaud Heritier added a comment - Good catch !!! We have to update/release all these plugins. We have to be able to put the changes.xml somewhere else because in maven 2, the directory (maven.docs.src) must contains only xdocs files (there's one directory per file type). It's the same problem for the navigation.xml
Hide
Permalink
Dennis Lundberg added a comment -

I also think that we need to make this configurable in all plugins. It was pretty straight forward for the changes plugin. I'll look at creating patches for the other ones as well. A quick search in the plugins tree revealed the same plugins that Lukas mentioned.

We should use the same property for all plugins. Is the name "maven.changes.file" that I used in my patch a good one?

Should I create one issue for each of the affected plugins and link those issues to this one as being related?

Show
Dennis Lundberg added a comment - I also think that we need to make this configurable in all plugins. It was pretty straight forward for the changes plugin. I'll look at creating patches for the other ones as well. A quick search in the plugins tree revealed the same plugins that Lukas mentioned. We should use the same property for all plugins. Is the name "maven.changes.file" that I used in my patch a good one? Should I create one issue for each of the affected plugins and link those issues to this one as being related?
Hide
Permalink
Arnaud Heritier added a comment -

Yes, the name of the property you proposed is fine for me.
You can use this issue in others plugins (for the issue # in the changes file).
You can also add on these plugins a constraint like :

<!-- fake test because the assert:assertPluginAvailable tag is avalaible in the maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not present. -->  
<assert:assertPluginAvailable groupId="maven" artifactId="maven-plugin-plugin" minRelease="1.7" neededBy="${plugin.artifactId}"/>
<assert:assertPluginAvailable groupId="maven" artifactId="maven-changes-plugin" minRelease="1.7.1" neededBy="${plugin.artifactId}"/>
Show
Arnaud Heritier added a comment - Yes, the name of the property you proposed is fine for me. You can use this issue in others plugins (for the issue # in the changes file). You can also add on these plugins a constraint like : 
<!-- fake test because the assert:assertPluginAvailable tag is avalaible in the maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not present. -->  
<assert:assertPluginAvailable groupId="maven" artifactId="maven-plugin-plugin" minRelease="1.7" neededBy="${plugin.artifactId}"/>
<assert:assertPluginAvailable groupId="maven" artifactId="maven-changes-plugin" minRelease="1.7.1" neededBy="${plugin.artifactId}"/>

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.