Maven 1

Allow more than one mailing list archive in Maven project file

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.1-beta-1
  • Component/s: model additions
  • Labels:
    None
  • Number of attachments :
    0

Description

In the schema for the Maven project descriptor, it only allows for one archive sub-element in each mailingList element. We have some mailing lists which are archived in a few places, in particular Sourceforge's "official" archives, and Geocrawler (which has frequently been keeping up to date better recently). It would be nice if all these archive locations could be specified for the lists in the descriptor.

Changing the schema to have
<xs:element name="mailingList">
<xs:complexType>
<xs:sequence>
<xs:element ref="name"/>
<xs:element ref="subscribe"/>
<xs:element ref="unsubscribe"/>
<xs:element ref="archive" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
would allow this, though I don't know where this actually gets used i.e. what other implications to templates etc. there might be.

Issue Links

This issue is related to:
MAVEN-1407 Add mailing list address to POM Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
dion gillard added a comment -

The short answer is that the schema is pretty much only used for validation.

The code that assumes only one archive is in src/plugins-build/xdoc/templates/mail-lists.xml

That would need a change

Show
dion gillard added a comment - The short answer is that the schema is pretty much only used for validation. The code that assumes only one archive is in src/plugins-build/xdoc/templates/mail-lists.xml That would need a change
Hide
Permalink
Felipe Leme added a comment -

Not only mail-lists.xml but also MailingList.java

I will try to do these changes as this is a relative simple fix but a good exercise on how to change Mavenīs API (so far I had only changed Jelly scripts).

Show
Felipe Leme added a comment - Not only mail-lists.xml but also MailingList.java I will try to do these changes as this is a relative simple fix but a good exercise on how to change Mavenīs API (so far I had only changed Jelly scripts).
Hide
Permalink
Brett Porter added a comment -

Felipe, I'm not sure we should be modifying the POM now. We'll make sure it is in the next version though.

Show
Brett Porter added a comment - Felipe, I'm not sure we should be modifying the POM now. We'll make sure it is in the next version though.
Hide
Permalink
Felipe Leme added a comment -

By next version you mean 1.1, right?

I will try to change it anyway (even if you don't apply the changes now), so I can get more familiar with Maven core.

But I agree the change on the POM must be better discussed, as it may break backwards compatibility. For instance, if it's changed to have a <archives> section, then the new mail-lists.xml won't work with old POMS, unless we use a pomVersion #if statement. Something like this:

#if ($project.pomVersion < 4 )
#displayLink("Archive" $list.archive)
#else
#forEach( $archive in $list.archives)
#displayLink("Archive" $archive)<br>
#end
#end

Show
Felipe Leme added a comment - By next version you mean 1.1, right? I will try to change it anyway (even if you don't apply the changes now), so I can get more familiar with Maven core. But I agree the change on the POM must be better discussed, as it may break backwards compatibility. For instance, if it's changed to have a <archives> section, then the new mail-lists.xml won't work with old POMS, unless we use a pomVersion #if statement. Something like this: #if ($project.pomVersion < 4 ) #displayLink("Archive" $list.archive) #else #forEach( $archive in $list.archives) #displayLink("Archive" $archive)<br> #end #end
Hide
Permalink
Carlos Sanchez added a comment -

Instead of an <archives> section a backwards compatible option could be 0 or more <archive> tags.

Show
Carlos Sanchez added a comment - Instead of an <archives> section a backwards compatible option could be 0 or more <archive> tags.
Hide
Permalink
Felipe Leme added a comment -

Yes, that's another option. Although it has the advantage of being backward compatible, it has 2 advantages:

  • it is inconsistent with the other collections
  • implementing it might be a little bit harder (I said might because I haven't touch that piece of code yet, but I assume it uses Digester for the task)
Show
Felipe Leme added a comment - Yes, that's another option. Although it has the advantage of being backward compatible, it has 2 advantages:
  • it is inconsistent with the other collections
  • implementing it might be a little bit harder (I said might because I haven't touch that piece of code yet, but I assume it uses Digester for the task)
Hide
Permalink
Carlos Sanchez added a comment -

Another advantage of not using <archives> is less typing. The common use case is having only one archive and I can't imagine a situation where you have more than two.

Show
Carlos Sanchez added a comment - Another advantage of not using <archives> is less typing. The common use case is having only one archive and I can't imagine a situation where you have more than two.
Hide
Permalink
Brett Porter added a comment -

I have kept <archive> as is for less typing as Carlos says - this is the "primary" archive.
I have added an element:
<otherArchives>
<otherArchive>URL</otherArchive>
</otherArchives>

These can be treated differently, or listed in addition depending on the usage.

Show
Brett Porter added a comment - I have kept <archive> as is for less typing as Carlos says - this is the "primary" archive. I have added an element: <otherArchives> <otherArchive>URL</otherArchive> </otherArchives> These can be treated differently, or listed in addition depending on the usage.

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
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.