accumulo-notifications mailing list archives

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

    [ https://issues.apache.org/jira/browse/ACCUMULO-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687026#comment-13687026
] 

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: https://issues.apache.org/jira/browse/ACCUMULO-1521
>             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: http://www.atlassian.com/software/jira

Mime
View raw message