accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1521) If poms need to be sorted, they just get sorted
Date Tue, 18 Jun 2013 18:16:21 GMT


Christopher Tubbs commented on ACCUMULO-1521:

{quote}things will be compiled before committing anyway{quote}
Can you guarantee this? I don't know of any way to guarantee this. But, we can check for it
by verifying the POM structure, like we are currently doing. If somebody commits a poorly
structured POM, I want the CI server to fail... not to just fix the user's failure to do their
due diligence to test before committing. This is no different than adding a checkstyle plugin
to the build as so many other projects do. I also don't want to build a clean checkout, only
to find that what was built did not match what was checked out, because the plugin just resorted
the POM without my knowledge.

{quote}If things are being edited in the pom for the release, then there's something wrong{quote}
Things aren't being edited in the pom for the release. The problem is that this plugin will
potentially *edit* the pom during a release if you make it automatically sort during a build.
The release plugin runs through the build, running all the tests. I suppose we could change
things so that the verify happens instead of sort during a release build. But that means that
the release artifacts cannot be easily reproduced without excessive documentation to explain
why a profile should be activated during a release (tagging), but not when reproducing the
release (building the tag).

I prefer the explicit practice of: when you change the POM, make sure you change it in a way
that conforms to the standards that are enforced. Then, everybody else who never want to touch
a POM can go on about their business without the concern of "why did my POM change when I
built? what changes were made and why? how do I fix them?". Those questions should be scoped
to the user who made the POM change that disrupted the sort/structure. And verify is the only
way we can enforce this.

However (in spite of my attempts to explain the potential problems in detail), I also don't
feel very strongly about this.
> If poms need to be sorted, they just get sorted
> -----------------------------------------------
>                 Key: ACCUMULO-1521
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: scripts
>            Reporter: John Vines
>             Fix For: 1.6.0
> If the pom is not sorted and you run mvn clean package, it will immediately fail stating
the poms aren't sorted. Rather than making me run mvn clean -Psort, it should just always
run the sort profile.
> Or sorted poms should not be required to package

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message