Re: how does -Dscijava.enforce.skip work?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: how does -Dscijava.enforce.skip work?

Mark Hiner
Hi Tobias,

>I do not understand the reason why RequireReproducibleBuilds must be in the core rules. Can you elaborate a bit more on this?

So, we wanted the default configuration of RequireReproducibleBuilds to only fail by default on first party groupIds: pom-scijava tests org.scijava, pom-imagej adds net.imagej, net.imglib2 and io.scif, and pom-fiji adds sc.fiji.

Since the intent of this rule is to be configured by project-level poms, I didn't want to hide that configuration in a profile (and at the time I wasn't sure how overriding profile xml blocks worked).

>then the -Dscijava.enforce.skip is kind of useless, isn’t it?

There are other rules besides SNAPSHOT checking that are disabled by this flag, but yes - it is kind of useless and overly clunky. It should have just been removed in the last release, in favor of -Denforcer.skip. Basically scijava.enforce.skip failed to provide its original intent: granular control over individual rules.

scijava.enforce.skip will be removed in the next release. Use enforcer.skip for local testing in the mean time.

Sorry for the confusion!
- Mark



On Mon, Nov 17, 2014 at 9:20 AM, Tobias Pietzsch <[hidden email]> wrote:
Hi Mark,

thanks for explaining.

I know that I should not release the SNAPSHOT versions. I’m using this (as intended, I assume) to figure out things locally while working on several projects at the same time. I will bump dependencies to release versions when I release all of the stuff in order.

I do not understand the reason why RequireReproducibleBuilds must be in the core rules. Can you elaborate a bit more on this?
If it is in the core rules, then the -Dscijava.enforce.skip is kind of useless, isn’t it? Because the RequireReproducibleBuilds will catch anyway the stuff that the disabled RequireReleaseDeps would have caught?

best regards,
Tobias

On 17 Nov 2014, at 15:24, Mark Hiner <[hidden email]> wrote:

Hi Tobias,

 I apologize for the confusion over enforcer skipping. I wanted to revise (and document) its operation last week but decided it wasn't critical to block pom-scijava 5.1 and its children.

 In pom-scijava, there is maven-enforcer-plugin configuration in two places. The first is in the base <plugins> block. Rules defined in this block - let's call them core rules - will ALWAYS run.

 The second definition is in profiles as you saw. These are supplementary rules. The profile is disabled if scijava.enforce.skip is set, causing the supplementary rules to not run. However, the core rules will still be executed.

 enforcer.skip is a property defined in the Maven enforcer:enforce goal itself itself. This completely disables all enforcer activation.

 Last week I created a RequireReproducibleBuilds enforcer rule which does more thorough SNAPSHOT checking than the default Maven-enforcer rule set. I put its activation in the core rules instead of the supplementary, because each child of pom-scijava requires different configuration (different groupIds being checked).

 I can only speculate that it is possible that the thorough, recursive nature of this check caused the additional dependencies to be downloaded. I would be interested in cross-checking the results of a "mvn dependency:tree -Dverbose" with what was downloaded - to see if unnecessary dependencies were some how downloaded.

 Anyway, I assume subsequent runs will/did not require any downloads. The requireReproducibleBuilds rule is kind of slow with lots of dependencies, even without the downloads, but I will be adding some speed enhancements shortly.

 I hope this clarifies the different skip flags for the enforcer configuration. That said, you should not release if you have enforcer failures. The skip flags are only intended for local testing, which is one of many reasons we have Jenkins deploy all of our projects - so we ensure that these rules are not skipped. These failures indicate that the current state of BDV is unreproducible, due to a SNAPSHOT parent and direct dependency:

> sc.fiji:spim_data:1.0.0-beta-3-SNAPSHOT
> sc.fiji:pom-bigdataviewer:1.0.0-SNAPSHOT

I assume something between runs, as your first list of SNAPSHOT dependencies was more exhaustive. Note that you did not get the duplicate class failure because that rule is declared in the scijava.enforce.skip profile.

 Please let us know if anything here is unclear. Happy to Skype as well if that's easier.

Best,
Mark

On Mon, Nov 17, 2014 at 7:27 AM, Tobias Pietzsch <[hidden email]> wrote:

On 17 Nov 2014, at 14:03, Tobias Pietzsch <[hidden email]> wrote:

After browsing the maven enforcer documentation http://maven.apache.org/enforcer/maven-enforcer-plugin/enforce-mojo.html
I tried “mvn -Denforcer.skip" which worked.

Then, I tried “mvn -Dscijava.enforcer.skip” and Maven starts downloading *a lot* of stuff from maven.imagej.net. Absolutely crazy. Looks like maybe everything that is on maven.imagej.net?
I’m still waiting for it to finish. I’ll let you know whether it works in the end…

Hmm, no.
In the end it doesn’t work.
Here is the output (also showing the maven.image.net download as far back as my terminal could remember…):

[WARNING] Checksum validation failed, expected 7c798b9edd7a744e042def51c31eef256556eee6 but is ddc682a2b219fcb896732e8ff3546415d708e12e for http://maven.imagej.net/content/groups/public/org/multiverse/multiverse-beta/0.7-RC-1/multiverse-beta-0.7-RC-1.pom
[WARNING] Checksum validation failed, expected 7c798b9edd7a744e042def51c31eef256556eee6 but is ddc682a2b219fcb896732e8ff3546415d708e12e for http://maven.imagej.net/content/groups/public/org/multiverse/multiverse-beta/0.7-RC-1/multiverse-beta-0.7-RC-1.pom
...

[Message clipped]  


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel