Jenkins Plugin pom (future of)

[James Nord]

Hi all,

firstly apologies about the recent messiness with consuming the jenkins bom in the plugin-pom.

For those of you that are not aware the jenkins bom is trying to solve to problem of not consuming newer versions of libraries that are shipped in Jenkins core as this can cause unexpected failure at runtime, and to make keeping the versions used in step with the Jenkins version targeted in the POM.

Now the previous attempt revealed a couple of issues mainly that you should not enable dependencies in a profile when the resulting pom is to be consumed later.  Also Profile activation (applies to incrementals) via environment/system properties is a bad idea when that changes what can be consumed/produced. The reason for this is when you want to aggregate several plugins in a build to perform batch testing of all their masters and some want to use one profile and others don't (but you can only set one property for the whole of the aggregation).

So to get a parent that works for plugins I need to break some eggs.  And this is the email about what eggs we want to also break, and which eggs are created by Fabergé and are too valuable to throw away. 

for my part we have a lot of properties that are overloaded in profiles (skipTests is a surefire flag but we abuse it to also skip spotbugs which when you know how maven works becomes surprising), we have findbugs properties as well (to cope with people that are have used a findbugs flag in their build and we now use spotbugs.

There is also the support for javascript builds, but a quick search of repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that use this (the javascript ecosystem moves much faster so I would argue this is better handled by documentation or another possibly another pom) so I think this should be a candidate for removal.

Given we are breaking eggs, I do not see a reason for the new parent not to use the jenkins-bom unconditionally.

Is there any other legacy that people think can be cleaned up / removed, or other points of view that people want to put forward before a PR lands as a surprise?

Regards

/James

[Jeff Thompson]

On 12/12/19 2:23 PM, James Nord wrote:

For those of you that are not aware the jenkins bom is trying to solve to problem of not consuming newer versions of libraries that are shipped in Jenkins core as this can cause unexpected failure at runtime, and to make keeping the versions used in step with the Jenkins version targeted in the POM.

I really like the goals you are pursuing here, to produce a parent pom that is more consistent and reduces problems at build and run time. It's a hard task to get everything lined up right and it does require "breaking some eggs".

(skipTests is a surefire flag but we abuse it to also skip spotbugs which when you know how maven works becomes surprising)

I would really like to break that egg. That overloading is just confusing and it causes problems when people aren't aware of its non-standard behavior. If people need they can create local aliases or whatever to achieve the same result. It shouldn't be in a parent pom like this.

we have findbugs properties as well (to cope with people that are have used a findbugs flag in their build and we now use spotbugs.

I'm in favor of breaking this egg, also. Findbugs is dead and has been for a while. We're past the point of needing to support a migration period.

Jeff

[Devin Nusbaum]

Some housekeeping in the plugin POM sounds good to me.

for my part we have a lot of properties that are overloaded in profiles (skipTests is a surefire flag but we abuse it to also skip spotbugs which when you know how maven works becomes surprising)

I was always a bit confused by that behavior, but never realized it was specific to the plugin POM. +1 for removing it.

There is also the support for javascript builds, but a quick search of repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that use this (the javascript ecosystem moves much faster so I would argue this is better handled by documentation or another possibly another pom) so I think this should be a candidate for removal.

I agree that given how infrequently this profile is used, it makes sense to remove it. I do have one concern though - If one of the plugins currently using the profile updates to a version of the plugin POM in which it has been removed, will the plugin’s build continue to work silently even though the produced artifacts will be broken? (I saw this happen at least once after https://github.com/jenkinsci/plugin-pom/pull/36 changed the profile used for this functionality)? If so, would it be possible to replace the profile with one that just fails the build if `.mvn_exec_node` is present to avoid this issue, since if downstream plugins copied the profile into their POM, it would make more sense for them to activate it by default anyway?

Devin

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2ce40a15-fe85-475a-8218-255140d4e1f5%40googlegroups.com.

[Jesse Glick]

On Thu, Dec 12, 2019 at 4:24 PM James Nord <jn...@cloudbees.com> wrote:
> There is also the support for javascript builds, but a quick search of repos showed only 29 repositories … that use this … so I would argue this is better handled by documentation or another possibly another pom

29 repositories is quite a lot, I think. If this is handled by
“documentation” then we will have no straightforward way of making
sure those plugins use up-to-date mojos or best practices. And we
cannot easily use another POM as Maven does not support multiple
inheritance (without a somewhat scary extension that IDEs and other
tools would not grok). I understand your desire to simplify, but this
sounds like it could just be making more maintenance work for us
overall. No strong opinion about it though, beyond Devin’s request
that a POM update must not _silently_ cease to package JS assets.

Regarding `-DskipTests`, I would perhaps propose some profile like
`-Pquick` that skips running tests, SpotBugs, Enforcer, and anything
else that is a sort of a test: i.e., could break the build but could
not affect the content of artifacts if the build passes. I wish this
were built in to / standardized by Maven itself so that mojos and IDEs
and everything else could agree on a single flag. (Note that you still
need to _compile_ tests, at least if `no-test-jar=false`.)

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
hiding all these things from the plugin “classpath” at both compile
time and runtime. Core could then use whatever library versions it
felt like with no impact on plugins, no BOM would be needed, and those
plugins actually requiring (say) Guava would need to declare a
dependency on some version of some library wrapper plugin once they
update `jenkins.version` past the split. I do not believe there is
anything all that technically difficult here, except to the extent
that functional tests might get messy (JENKINS-41827); it is more
about summoning the will to do it and follow up with various issues
afterwards.

[James Nord]

On Friday, December 13, 2019 at 3:34:05 PM UTC, Jesse Glick wrote:

On Thu, Dec 12, 2019 at 4:24 PM James Nord <jn...@cloudbees.com> wrote:
> There is also the support for javascript builds, but a quick search of repos showed only 29 repositories … that use this … so I would argue this is better handled by documentation or another possibly another pom

29 repositories is quite a lot, I think. If this is handled by
“documentation” then we will have no straightforward way of making
sure those plugins use up-to-date mojos or best practices.

it does not look like the javascript parts have been updated in over 3 years, I doubt we are following best practices at all here, but I accept your alternative POV.

 

And we
cannot easily use another POM as Maven does not support multiple
inheritance (without a somewhat scary extension that IDEs and other
tools would not grok).

Sure we can,   we can have a base parent, then we have another parent with specialisation that has the base parent as it's own pom.  
Then you pick your parent from the possible options. (generic, specialist etc)

 

I understand your desire to simplify, but this
sounds like it could just be making more maintenance work for us
overall. No strong opinion about it though, beyond Devin’s request
that a POM update must not _silently_ cease to package JS assets.

ack

 

Regarding `-DskipTests`, I would perhaps propose some profile like
`-Pquick` that skips running tests, SpotBugs, Enforcer, and anything
else that is a sort of a test: i.e., could break the build but could
not affect the content of artifacts if the build passes. I wish this
were built in to / standardized by Maven itself so that mojos and IDEs
and everything else could agree on a single flag. (Note that you still
need to _compile_ tests, at least if `no-test-jar=false`.)

ok - seems trivial enough (so long as all the mojos have a skip option)

 

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
hiding all these things from the plugin “classpath” at both compile
time and runtime. Core could then use whatever library versions it
felt like with no impact on plugins, no BOM would be needed, and those
plugins actually requiring (say) Guava would need to declare a
dependency on some version of some library wrapper plugin once they
update `jenkins.version` past the split. I do not believe there is
anything all that technically difficult here, except to the extent
that functional tests might get messy (JENKINS-41827); it is more
about summoning the will to do it and follow up with various issues
afterwards.

I disagree with you in thinking this is easier - especially as the Jenkins APIs expose some of the internals of its libraries as API.
(acegi security, jelly, XStream )  you can not easily have multiple slf4j implementations either - it's going to blow up at some point.
thus even if you did do this isolation I beleive there is still a need for some form of jenkins-bom (perhaps with a more limited set of libraries).

There is also the issue that a plugin may include some library and may depend on another plugin, at somepoint later this other plugin also depends on the library but at an incompatable version and it becomes part of its API.

 
I'm happy to be proven wring but for the moment I can make improvements in the plugin pom and use the benefits immediately, and I would expect a lot more breakage in changing the class loaders.

[James Nord]

As far as I can tell https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L120-L126 no longer needs to have the type set to executable-war (can just be type war) 
(original commit and hpi-plugin code, mode code) or am I missing something?

/James

[Ullrich Hafner]

I use:

<profile>
  <id>skip</id>
  <properties>
    <maven.javadoc.skip>true</maven.javadoc.skip>
    <pmd.skip>true</pmd.skip>
    <spotbugs.skip>true</spotbugs.skip>
    <checkstyle.skip>true</checkstyle.skip>
    <skipTests>true</skipTests>
    <skipITs>true</skipITs>
    <revapi.skip>true</revapi.skip>
  </properties>
</profile>

 

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
hiding all these things from the plugin “classpath” at both compile
time and runtime. Core could then use whatever library versions it
felt like with no impact on plugins, no BOM would be needed, and those
plugins actually requiring (say) Guava would need to declare a
dependency on some version of some library wrapper plugin once they
update `jenkins.version` past the split. I do not believe there is
anything all that technically difficult here, except to the extent
that functional tests might get messy (JENKINS-41827); it is more
about summoning the will to do it and follow up with various issues
afterwards.

I disagree with you in thinking this is easier - especially as the Jenkins APIs expose some of the internals of its libraries as API.
(acegi security, jelly, XStream )  you can not easily have multiple slf4j implementations either - it's going to blow up at some point.
thus even if you did do this isolation I beleive there is still a need for some form of jenkins-bom (perhaps with a more limited set of libraries).

There is also the issue that a plugin may include some library and may depend on another plugin, at somepoint later this other plugin also depends on the library but at an incompatable version and it becomes part of its API.

 
I'm happy to be proven wring but for the moment I can make improvements in the plugin pom and use the benefits immediately, and I would expect a lot more breakage in changing the class loaders.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1a8dcb62-349f-4f1e-b3dd-32a125869c13%40googlegroups.com.

[Ullrich Hafner]

+1 on removing findbugs and using spotbugs

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into the verify phase as well. So plugin developers will get the results automatically by running mvn verify (or mvn install).

This will make the buildPlugin step also simpler, see discussions in:

- https://issues.jenkins.io/browse/INFRA-2294

- https://issues.jenkins.io/browse/INFRA-2000

- https://github.com/jenkins-infra/pipeline-library/pull/121

[Jesse Glick]

On Mon, Dec 16, 2019 at 7:14 AM James Nord <jn...@cloudbees.com> wrote:
>> we cannot easily use another POM as Maven does not support multiple inheritance
>

> Sure we can, we can have a base parent, then we have another parent with specialisation that has the base parent as it's own pom.
> Then you pick your parent from the possible options. (generic, specialist etc)

Right, you can do this, so long as there is at most one useful
addition needed by a given plugin. As soon as you want to (say) manage
JS asset bundling and use managed versions of PowerMock in the same
plugin, you are going to need to start copying and pasting.

> the Jenkins APIs expose some of the internals of its libraries as API.
> (acegi security, jelly, XStream )

Yes these are all effectively part of the Jenkins core API surface.
But they should not be controlled by a BOM either, because a plugin
should not be attempting to use its own copies. The libraries which
are eligible for _either_ JENKINS-30685 or BOM management are those
which are used as implementation details and which plugins would
plausibly want to override, such as Guava.

> you can not easily have multiple slf4j implementations either

This one seems to be in a special category if I understand correctly
(but I probably do not).

> I can make improvements in the plugin pom and use the benefits immediately, and I would expect a lot more breakage in changing the class loaders.

Yes, in the short term anyway.

[Oleg Nenashev]

I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation would be to start from a 4.0-rc so that we can do some evaluation and incremental cleanup before 4.0

My suggestions:

• Change its groupId to "io.jenkins.main.pom" (and artifact ID = plugin-pom as now). It would protect users from picking up the RC and give us some space to introduce more parent POMs if needed. It will also allow to workaround the issue with Dependabot where filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not being updated. And we definitely do want it to be updated (and not so much - for plugin minimum dependencies)
• I will be also fine if 4.0 uses 2.204+ as a required baseline so that we remove the Java 7- remainders (e.g. `org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to finalize the Java 11-only plugins support PR (core patches are done in 2.160.x, but we still have no tooling to deliver such plugins to [custom?] update centers).
• Bump Maven requirement to 3.6.0+ or so. There is no point in supporting 3.3.1 (and 3.5.4 for incrementals)
• Remove JGit profiles (YAGNI?)
• Keep profiles for integration tests and JMH
• MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended way to manage test dependencies. This makes sense if and only if we find that the Plugin BOM is maintainable enough to keep it running

There is also the support for javascript builds, but a quick search of repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that use this (the javascript ecosystem moves much faster so I would argue this is better handled by documentation or another possibly another pom) so I think this should be a candidate for removal

I would highly recommend to bring it up in the UX SIG before going forward with it. Since there is a planned effort to streamline and revamp the Jenkins Frontend, it might be a good topic for discussion.

I see no problem if a new Parent POM was introduced for such purpose, but -0.5 for just removing is (see Jesse's concern). We could also keep the profile for now and kick the topic down the road.

BR, Oleg

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,

I would say it is a separate topic . It is a pretty big change inside the core, and Parent POM

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into the verify phase as well. So plugin developers will get the results automatically by running mvn verify (or mvn install).

 

 

[James Nord]

I have a draft PR at https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves the javascript builders untouched.

Shall we take the rest of the conversation there (but answered here for completeness) ?

On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:

I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation would be to start from a 4.0-rc so that we can do some evaluation and incremental cleanup before 4.0

My suggestions:

• Change its groupId to "io.jenkins.main.pom" (and artifact ID = plugin-pom as now). It would protect users from picking up the RC and give us some space to introduce more parent POMs if needed.

not sure why that helps in this case.  

• It will also allow to workaround the issue with Dependabot where filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not being updated. And we definitely do want it to be updated (and not so much - for plugin minimum dependencies)

Won't that cause dependabot to not update the parent when it can - because the groupId has changed?

 

• I will be also fine if 4.0 uses 2.204+ as a required baseline so that we remove the Java 7- remainders (e.g. `org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to finalize the Java 11-only plugins support PR (core patches are done in 2.160.x, but we still have no tooling to deliver such plugins to [custom?] update centers).

not yet done - will do

 

• Bump Maven requirement to 3.6.0+ or so. There is no point in supporting 3.3.1 (and 3.5.4 for incrementals)

3.6.3 is required for excludes wildcard matching which is in use in the wild - so I guess a push would maek sense - but its not yet on ci.jenkins.io (unable to fetch link because issues.jenkins.io is unhappy)

 

• Remove JGit profiles (YAGNI?)

they've already gone 

 

• Keep profiles for integration tests and JMH

JMH has not gone - not sure what it you where on about there was no profile for plugins but its now there by default.

 

• MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended way to manage test dependencies.

Erm...  though shalt not manage dependencies in a profile....  that's what started this mess :)

• This makes sense if and only if we find that the Plugin BOM is maintainable enough to keep it running

There is also the support for javascript builds, but a quick search of repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that use this (the javascript ecosystem moves much faster so I would argue this is better handled by documentation or another possibly another pom) so I think this should be a candidate for removal

I would highly recommend to bring it up in the UX SIG before going forward with it. Since there is a planned effort to streamline and revamp the Jenkins Frontend, it might be a good topic for discussion.

I see no problem if a new Parent POM was introduced for such purpose, but -0.5 for just removing is (see Jesse's concern). We could also keep the profile for now and kick the topic down the road.

kicked it down the road.

 

BR, Oleg

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,

I would say it is a separate topic . It is a pretty big change inside the core, and Parent POM

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into the verify phase as well. So plugin developers will get the results automatically by running mvn verify (or mvn install).

not sure where that comment was made - spotbugs is already in the verify stage?

[Oleg Nenashev]

Looks like there is a consensus in this thread about the new POM, apart from "minor" implementation details

What is my suggestion is:

1. I cut the 3.55 release of Plugin POM today
2. We start integration 4.0 changes into master. First versions will be "beta". It will stay in Beta until we all agree that the desired breaking changes are done
3. Initial changes to be merged
• Bulk PR from James Nord: https://github.com/jenkinsci/plugin-pom/pull/269 
• GMaven to GMavenPlus: https://github.com/jenkinsci/plugin-pom/pull/209
• JTH 2.58 with breaking changes in HTML Unit: https://github.com/jenkinsci/plugin-pom/pull/271
• (?) Group ID change. Will submit a PR for discussion
4. If a new release of 3.x is needed, we will create a new branch for it

BR, Oleg

[Oleg Nenashev]

4.0-beta-1 is here: https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 . It includes only the pul lrequest from James Nord, but I will integrate other changes into beta-2.

Regarding the Group ID change, I retract my proposal. Although it would be useful in general, the scope of changes in docs and development tools is way too big.

My particular concerns like Dependabot can be addressed in Dependabot Core itself, it will take much less time.

Best regards,

Oleg

[Oleg Nenashev]

And... 4.0-beta-2: https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2

All discussed changes have been integrated. It would be great to have some testing before we cut final 4.0.

If someone has more ideas which you would like to integrate, please suggest in the thread (or submit pull requests!)

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into the verify phase as well. So plugin developers will get the results automatically by running mvn verify (or mvn install).

 This one has not been implemented yet IIUC. +1 for doing so

BR, Oleg

[Ullrich Hafner]

While testing the new pom it appears that it requires at least LTS 2.190.x (due to the jenkins-bom dependency).

Isn’t this version too new?

Best regards,

Oleg

3.6.3 is required for excludes wildcard matching which is in use in the wild - so I guess a push would maek sense - but its not yet on ci.jenkins.io(unable to fetch link because issues.jenkins.io is unhappy)

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f1b9d76c-e7af-4618-8c2f-ba50b40dc7da%40googlegroups.com.

[Oleg Nenashev]

IIUC James was about retrospectively doing releases for older versions.

https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now lists only 2.190.x indeed

On Friday, January 17, 2020 at 11:49:19 AM UTC+1, Ullrich Hafner wrote:

While testing the new pom it appears that it requires at least LTS 2.190.x (due to the jenkins-bom dependency).

Isn’t this version too new?

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Ullrich Hafner]

Would its make sense to remove that part from the pom until we have older Jenkins versions supported? Otherwise we will hardly find some testers for the changes...

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ed535b59-41cb-4637-bcdd-8bf5184c949b%40googlegroups.com.

[James Nord]

On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:

Would its make sense to remove that part from the pom until we have older Jenkins versions supported? Otherwise we will hardly find some testers for the changes...

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ed535b59-41cb-4637-bcdd-8bf5184c949b%40googlegroups.com

2.190.x was retrospectively published.  I have an internal task (now up) to publish some boms for CloudBees' fixed lines (which is pretty much 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way into repo.jenkins.org, it just got paused due to Christmas/New Year,  sickness and investigating https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).

However anything older than 2.164 should be a security risk now (I do not know of any other companies performing releases with backports of Jenkins security fixes) - so I am not intending to publish anything else other than the 2.164 line as this enables users bad habits of upgrading plugins to get new features whilst still running an insecure core, hence I would recommend bumping to at least 2.164.x in the warnings-ng plugins in preparation.

of note 93% of users who are using the latest warnings-ng plugin are on 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect this to be an issue for users of your (well at least warnings-ng) plugins.

/James

[James Nord]

On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:

On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:

Would its make sense to remove that part from the pom until we have older Jenkins versions supported? Otherwise we will hardly find some testers for the changes...

Am 17.01.2020 um 12:16 schrieb Oleg Nenashev <o.v.n...@gmail.com>:

IIUC James was about retrospectively doing releases for older versions.

https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now lists only 2.190.x indeed

2.190.x was retrospectively published.  I have an internal task (now up) to publish some boms for CloudBees' fixed lines (which is pretty much 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way into repo.jenkins.org, it just got paused due to Christmas/New Year,  sickness and investigating https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).

However anything older than 2.164 should be a security risk now (I do not know of any other companies performing releases with backports of Jenkins security fixes) - so I am not intending to publish anything else other than the 2.164 line as this enables users bad habits of upgrading plugins to get new features whilst still running an insecure core, hence I would recommend bumping to at least 2.164.x in the warnings-ng plugins in preparation.

of note 93% of users who are using the latest warnings-ng plugin are on 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect this to be an issue for users of your (well at least warnings-ng) plugins.

2.164.[1-3] and 2.176.[1-4] have now been published to repo.jenkins-ci.org.

I'm not intending to publish more versions, however if there is a demonstrable need then I can publish some more.

For trying to track down changes between versions you can still use -Djenkins.version=x.zyz if you also specify -Djenkins-bom.version=a.abc which will not be 100% correct but should be close enough. (only ant,slf4j commons-codec and spotbugs-annotations have changed between the published versions)

/James

 

[Ullrich Hafner]

Ok, thanks. 2.164 would be ok for me. 

Now I get:

mvn validate

[INFO] Scanning for projects...

[ERROR] [ERROR] Some problems were encountered while processing the POMs:

[ERROR] 'dependencies.dependency.version' for org.kohsuke:access-modifier-annotation:jar must be a valid version but is '${access-modifier-annotation.version}'. @ org.jenkins-ci.main:jenkins-bom:2.164.3, /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom, line 211, column 18

 @ 

[ERROR] The build could not read 1 project -> [Help 1]

[ERROR]   

[ERROR]   The project org.jvnet.hudson.plugins:analysis-pom:2.0.0-beta-2-SNAPSHOT (/Users/hafner/Development/git/warnings-ng-plugin-devenv/analysis-pom-plugin/pom.xml) has 1 error

[ERROR]     'dependencies.dependency.version' for org.kohsuke:access-modifier-annotation:jar must be a valid version but is '${access-modifier-annotation.version}'. @ org.jenkins-ci.main:jenkins-bom:2.164.3, /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom, line 211, column 18

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9640e383-2686-41fe-b80b-26df95d5d13e%40googlegroups.com.

[James Nord]

do you have a PR I can checkout locally?

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[James Nord]

Never mind, several of the retrospective BOMs are garbage because I used a non local parent and the resolved parent is flattened so the properties where missing :-(

I guess I can republish them (which is just awful because releases are golden).  but I don't think there is much other good solutions.

/James

[James Nord]

Hi all,

The following versions of the jenkins-bom where all garbage and have been *deleted* from the repository and republished

* 2.164.1

* 2.164.2

* 2.164.3

* 2.176.1

* 2.176.2

* 2.176.3

* 2.176.4

if you have already tried to use one of these versions then you will need to remove the version from your local repository cache (~/.m2/repository) as well as any maven proxies you may be using.

I do not think these have been pulled in builds on ci.jenkins.io yet (which uses its own cache) but if you see the failure that Ulli saw on CI but not locally due to the bom then please let me know and I will file an INFRA ticket and try and get them cleaned up).

/James