Fix the gulp bundle phase so the adjunct is included

[svanoort]

Fixes the NoSuchAdjunctExceptions with plugin-pom 2.6+ until we can update to the latest plugin parent pom & validate against it.

Fix to the plugin parent is in PR jenkinsci/plugin-pom#27

@reviewbybees especially @jglick

[oleg-nenashev]

🐝 from me

[recena]

🐛, missing JSHint

[oleg-nenashev]

@recena
Maybe it should be passed via parent POM

[recena]

@svanoort You can find a similar example jenkinsci/jenkins#2367

@oleg-nenashev Yes, I'll send a PR.

[jglick]

Why not just release the parent POM?

[svanoort]

@recena Surely you meant to make that an ant, since it's a desirable but unrelated and separate change? I agree with @oleg-nenashev that it would be better to simply pass this via the parent POM with our next release, if we can add it there in some fashion (I think sensible, since it should be global to all plugins).

@jglick As the need for this PR demonstrates, upgrades to the parent POM version can carry along unintended consequences and need some extra verification. I'd like to cut a plugin release today for stage view if possible, and do the next round of parent POM bumps with the version after (to isolate the changes and allow time for further verification).

[recena]

@svanoort No, I mean 🐛 since JSHint should be active.

[svanoort]

@recena Maybe I do not understand you -- where did this commit modify the JSHint behavior?

[recena]

@svanoort If you want to use gulp bundle though frontend-maven-plugin you should active JSHint. Other option, as @jglick mentioned, Why not just release the parent POM?

[jglick]

upgrades to the parent POM version can carry along unintended consequences

Which is why it is a good thing you can freely back out an update to a given POM version. Roll forward.

[svanoort]

@recena What you are saying still does not make sense to me. How would releasing the parent POM change the JSHint behavior? How does this commit modify the JSHint behavior? I understand that you feel strongly about JSHint, but unless I am misunderstanding the impact this has on the Maven build, this change is merely duplicating logic from the current parent pom (but correcting the phase used).

If you think it's absolutely critical to use JSHint, it must be important enough to modify the parent POM as Oleg has suggested and that is the right place to add it (rather than on an ad-hoc basis to individual plugins).

[svanoort]

@jglick I do not wish to delay release until a new parent pom can be released and this can be thoroughly tested against it and all the bugs introduced fixed, since we have users explicitly waiting on release of #14 If you think delaying for a parent pom release and upgrade here is 100% necessary, raise a bug and I'll shelve plans to cut a release until I have enough bandwidth to do full enough testing to have confidence (probably a week out).

[jglick]

If you think delaying for a parent pom release and upgrade here

That is not what I suggested at all. I said to just merge your upstream PR, release it, and use the release here. If there are problems with it, we will find them and reconsider. No one is being forced to update to a parent POM version which breaks their plugin’s build.

For that matter, you could just back out this aspect of #13.

[recena]

@svanoort

...this change is merely duplicating logic from the current parent pom...

The Parent POM configuration is wrong (incomplete). For that, I recommend you:

1. Do the proper changes in Parent POM and update the dependency in this plugin
2. Override the configuration and use JSHint

[svanoort]

@recena Since you appear to be the only person that considers that change a priority and I still haven't seen an explanation of how this commit modifies the JSHints behavior vs. parent or why this change is even needed:

• Please submit the appropriate PR to the parent pom, as others have suggested
• I will be happy to incorporate it with the next release of stage view.

[jglick]

FWIW you can have a 🐝, my advice was merely to keep it simple and release the fix that we know we need.

[svanoort]

@jglick Thanks - I agree in principle too, just trying to play it safe with upgrades until I can do it right with proper testing.

I have created https://issues.jenkins-ci.org/browse/JENKINS-35676 to reflect the upgrade to the next iteration of parent POM (and track testing against it and removing this workaround).

After consulting with others, majority opinion is that the JSHints change should go in the parent POM not in the PR itself.

[recena]

No comment!