[MARTIFACT-80] Apply ignore configuration to main project artifact as well#71
[MARTIFACT-80] Apply ignore configuration to main project artifact as well#71facboy wants to merge 2 commits intoapache:masterfrom
Conversation
…as well Previously the `ignore` configuration did not apply to the main project artifact, only to secondary attached artifacts
…gregated buildinfo in `compare` Use the per-module ignore configuration when generating buildinfo for comparison in the aggregator (usually the 'last' module). It's a bit of a bodge because it relies on the ignore config being stored when the `compare` goal runs in each module. If for some reason a module doesn't run the `compare` goal then it falls back to whatever config exists in the aggregator. There's probably a much more complex solution that involves parsing the config out of the project model that would be more consistent.
| <artifactId>@project.artifactId@</artifactId> | ||
| <version>@project.version@</version> | ||
| <configuration> | ||
| <ignore>*/ignore-modA-*.jar</ignore> |
There was a problem hiding this comment.
this should not be configured in this module's POM but in parent
There was a problem hiding this comment.
it relates to artifacts produced by this module though, isn't it better to be 'closer' to the source?
or is artifact always intended to be configured at the 'top-level' of the build?
There was a problem hiding this comment.
I never thought precisely at it in the past, but now I see it arises naturally
I'd say, yes, that it's intended to be configured at top-level, because it's a full build process that has to be checked. Partial checks run one one single module are just partial executions: it's useful to get faster feedback when testing, but at the end, it's the whole build that counts
There was a problem hiding this comment.
and TBH, I did not even expect compare goal to be configured in pom.xml: I always use this goal fully on CLI, because I compare a rebuild done on one situation with an initial build that may have been done anywhere, and the more environmental distance between the 2 builds, the better to discover unexpected discrepencies
There was a problem hiding this comment.
Yeah, it wouldn't be part of the regular build. In practice we configure it in pluginManagement.
|
Resolve #172 |
|
probably superceded by #182 |
3 participants
Also
compare