Enforce rules defined outside the pom.xml or its parent

[Martin D'Aloia <ma...@gmail.com>]

Hello,

Is it possible to enforce a set of rules defined outside the pom.xml being
built (i.e. not defined in the current pom or in a parent pom)?

Ideally, I would like to define maven-enforcer-plugin rules in an external
pom.xml and evaluate them over the pom.xml being build in order to not
force to use a specific parent pom.

*CONTEXT:*
I'm defining a CI/CD pipeline and I would like to enforce a set of rules
over the pom.xml in order to be deployed to our internal repository (sort
of validations performed to publish to Maven Central).

Thanks in advance for any suggestions!

Re: Enforce rules defined outside the pom.xml or its parent

[ma...@gmail.com, ma...@gmail.com]

@Bernd and @Anthony, thanks to both for the suggestions and sorry for the delayed reply (I didn't have an email notification as I was not subscribed).

@Bernd: Thanks for pointing out that issue, I wasn't aware of it. Though, it seems to be only useful for execute rules with the default config and/or already defined in the pom.xml of the artifact being built. From the point of view of validations performed during the CI pipeline, it would be great to have those rules configured outside the pom.xml of the project and apply them to every build that needs to be deployed into the internal repository.

@Anthony: Thanks for the comments. I knew the benefits of having a Corporate Parent POM. I think that it can be a good complementary use. Although, for the use case that I'm trying to achieve I see 2 issues: 

1) If we want to update the ruleset we need to generate a new version and "ask" to all the projects maintainers to update the parent version in their projects or find a way to enforce a validation of the version used as parent for new builds.

2) The maven-enforcer-plugin could be overridden by the users of the parent pom. For example they can set <skip>true</skip> config or bind the plugin to a "none" phase to disable them.

Does anyone knows if it is feasible to read another pom.xml or a subset of it in order to read the rules configuration and obtain the list of EnforceRule beans populated with the corresponding configuration for each rule?

Thanks!

On 2019/03/27 18:12:04, Anthony Whitford <an...@whitford.com> wrote: 
> Personally, I have done this with a Parent POM.  Every corporate project must directly, or indirectly, inherit a Corporate Parent POM.  This is generally useful because you can define common properties that Maven can leverage, even for local builds.  For example, one can declare properties for your JIRA host or Git host to avoid hard coding.  Most valuable is that POMs need to be explicit with plugin versions to ensure repeatable and reliable builds, and doing that for every project is very tedious, so a common Corporate Parent POM can define specific plugin versions and settings to minimize the burden for each project.
> 
> The alternate way is to use Profiles <http://maven.apache.org/guides/introduction/introduction-to-profiles.html>.  You can configure settings on your CI/CD servers — see “global Maven-settings.”
> 
> Pro tip:  think about evolution!  Things will change; assuming that ONE set of standards will apply universally will usually lead to issues.  (Incompatibilities will arise, and assuming that ALL projects can evolve instantly is unrealistic when you have more than a handful of projects.)  The nice thing about a Corporate Parent POM is that it can be versioned like any other Maven Artifact, so each Project can evolve at its own pace.  (If you are going with the Profile approach on your CI/CD server(s), you may need to leverage Project Metadata maintained at the CI/CD solution.)
> 
> Hope this helps,
> 
> Anthony
> 
> 
> > On Mar 26, 2019, at 7:04 AM, Martin D'Aloia <ma...@gmail.com> wrote:
> > 
> > Hello,
> > 
> > Is it possible to enforce a set of rules defined outside the pom.xml being
> > built (i.e. not defined in the current pom or in a parent pom)?
> > 
> > Ideally, I would like to define maven-enforcer-plugin rules in an external
> > pom.xml and evaluate them over the pom.xml being build in order to not
> > force to use a specific parent pom.
> > 
> > *CONTEXT:*
> > I'm defining a CI/CD pipeline and I would like to enforce a set of rules
> > over the pom.xml in order to be deployed to our internal repository (sort
> > of validations performed to publish to Maven Central).
> > 
> > Thanks in advance for any suggestions!
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Enforce rules defined outside the pom.xml or its parent

[Anthony Whitford <an...@whitford.com>]

Personally, I have done this with a Parent POM.  Every corporate project must directly, or indirectly, inherit a Corporate Parent POM.  This is generally useful because you can define common properties that Maven can leverage, even for local builds.  For example, one can declare properties for your JIRA host or Git host to avoid hard coding.  Most valuable is that POMs need to be explicit with plugin versions to ensure repeatable and reliable builds, and doing that for every project is very tedious, so a common Corporate Parent POM can define specific plugin versions and settings to minimize the burden for each project.

The alternate way is to use Profiles <http://maven.apache.org/guides/introduction/introduction-to-profiles.html>.  You can configure settings on your CI/CD servers — see “global Maven-settings.”

Pro tip:  think about evolution!  Things will change; assuming that ONE set of standards will apply universally will usually lead to issues.  (Incompatibilities will arise, and assuming that ALL projects can evolve instantly is unrealistic when you have more than a handful of projects.)  The nice thing about a Corporate Parent POM is that it can be versioned like any other Maven Artifact, so each Project can evolve at its own pace.  (If you are going with the Profile approach on your CI/CD server(s), you may need to leverage Project Metadata maintained at the CI/CD solution.)

Hope this helps,

Anthony


> On Mar 26, 2019, at 7:04 AM, Martin D'Aloia <ma...@gmail.com> wrote:
> 
> Hello,
> 
> Is it possible to enforce a set of rules defined outside the pom.xml being
> built (i.e. not defined in the current pom or in a parent pom)?
> 
> Ideally, I would like to define maven-enforcer-plugin rules in an external
> pom.xml and evaluate them over the pom.xml being build in order to not
> force to use a specific parent pom.
> 
> *CONTEXT:*
> I'm defining a CI/CD pipeline and I would like to enforce a set of rules
> over the pom.xml in order to be deployed to our internal repository (sort
> of validations performed to publish to Maven Central).
> 
> Thanks in advance for any suggestions!

Re: Enforce rules defined outside the pom.xml or its parent

[Bernd Eckenfels <ec...@zusammenkunft.net>]

It’s not what you where asking, but many rules can  and should be put into a common parent - helps with local builds as well.

Maven enforcer can use rules on the command line it seems: https://issues.apache.org/jira/plugins/servlet/mobile#issue/MENFORCER-142

Besides that some static analysis with your own plugin or tools like jqassist can be run in CI Jobs also.

Gruß
Bernd

--
https://Bernd.eckenfels.net

________________________________
Von: Martin D'Aloia <ma...@gmail.com>
Gesendet: Mittwoch, März 27, 2019 6:46 PM
An: users@maven.apache.org
Betreff: Enforce rules defined outside the pom.xml or its parent

Hello,

Is it possible to enforce a set of rules defined outside the pom.xml being
built (i.e. not defined in the current pom or in a parent pom)?

Ideally, I would like to define maven-enforcer-plugin rules in an external
pom.xml and evaluate them over the pom.xml being build in order to not
force to use a specific parent pom.

*CONTEXT:*
I'm defining a CI/CD pipeline and I would like to enforce a set of rules
over the pom.xml in order to be deployed to our internal repository (sort
of validations performed to publish to Maven Central).

Thanks in advance for any suggestions!