[BUILD-46] Figure out parent pom for Forge projects Created: 28/Oct/10  Updated: 13/Apr/17  Resolved: 23/Nov/10

Status: Closed
Project: Build
Component/s: Poms
Affects Version/s: None
Fix Version/s: POMs 18

Type: Task Priority: Blocker
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon BUILD-53 Provide an "ignore" header template Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

While we don't want to make the use of our parent pom mandatory, some projects might want to use that, at least as a quickstart.

One of the problems is that our other parent poms define stuff like "magnoliaEdition", "magnoliaLicenceStyle", and this might not be relevant for these projects.

  • magnoliaLicenceStyle might work (perhaps the property could be renamed), as it just drives the configuration of some other plugins... (to be validated)
  • magnoliaEdition seems to be only used when generating README, and only in the context of pom, war, and installer packages...

Another issue has to do with license headers. Forge projects are not owned by Magnolia International, and as such, their using our license header makes no sense. The checkstyle rules checking those headers are driven by the above magnoliaLicenseStyle property. Should we provide another set of headers, so that forge modules can use our checkstyle rules if they want ? (Matt Dertinger expressed interest) and/or should we add rules to enforce the non-usage of these headers ?

Need to investigate deeper to check if there are other implications. If so, we could also maintain such a pom at a higher level than our existing ones.



 Comments   
Comment by Matt Dertinger [ 29/Oct/10 ]

Couldn't forge projects override the checkstyleHeader property, with their own?
For example:

<parent>
  <groupId>info.magnolia.forge</groupId>
  <artifactId>magnolia-parent-pom-forge</artifactId>
  <version>18-SNAPSHOT</version>
</parent>
<groupId>info.magnolia.forge.module.twigs</groupId>
<artifactId>magnolia-twigs</artifactId>
<packaging>pom</packaging>
<version>1.0.0-SNAPSHOT</version>
<name>Magnolia Twigs (parent pom)</name>
<description>Magnolia Twigs is ...</description>
<inceptionYear>2010</inceptionYear>
<organization>
  <name>Magnolia Forge</name>
  <url>http://forge.magnolia-cms.com</url>
</organization>
<properties>
  <magnoliaVersion>4.3.7</magnoliaVersion>
  <magnoliaSTKVersion>1.3.5</magnoliaSTKVersion>
  <magnoliaLicenseStyle>cc-by-sa</magnoliaLicenseStyle>
  <checkstyleHeader>$PATH_TO_MY_PROJECTS_HEADER_FILES/license-header-${magnoliaLicenseStyle}.regex</checkstyleHeader>
</properties>
...

Thoughts?

Cheers,
Matt

Comment by Matt Dertinger [ 29/Oct/10 ]

Ok, sorry, after looking at the Magnolia Build Tools, I think I understand why the above approach won't work. I'm still thinking though.

Comment by Magnolia International [ 29/Oct/10 ]

Yeah, we probably do something.. tbh, even though I came up with it, I'm not too fond of this property-prefix-suffix-mess-driven type of configuration.

Comment by Magnolia International [ 01/Nov/10 ]

I had to set the magnoliaLicenseStyle to dual for the build to pass. This is not correct.
(see http://hudson.magnolia-cms.com/job/magnolia-poms-trunk/69/ )

Comment by Magnolia International [ 23/Nov/10 ]

The magnoliaEdition property was removed from parent poms with BUILD-52
The magnoliaLicenceStyle property is set to generic, so nothing Magnolia-specific should infiltrate remote-resources (README.txt etc)
The checkstyle header can be customized but by default is ignored (see BUILD-53)

Comment by Magnolia International [ 23/Nov/10 ]

Matt, I'm marking this as resolved, but I'm still looking forward for your input on this matter.

I created a sample project to check if things work as I expect. Have a look and let me know what you think: http://svn.magnolia-cms.com/svn/forge/forge-sample/trunk/

Generated at Sun Feb 11 23:38:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.