Moving it to jenkins-test-harness since that is the immediate source of the error, though the changed behavior is actually in maven-hpi-plugin + plugin-pom and the fix probably needs to be in https://github.com/stapler/idea-stapler-plugin for which we have no apparent bug tracker.

BTW the change was introduced in 2.30, not 2.31.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jvnet/hudson/test/WarExploder.java
http://jenkins-ci.org/commit/jenkins-test-harness/d0f8b511b66233a09c023060a4405de1485600e8
Log:
JENKINS-45245 Improve messaging.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jvnet/hudson/test/WarExploder.java
http://jenkins-ci.org/commit/jenkins-test-harness/2f425413932db5e1b7455a2d3a82d38c9d75035b
Log:
Merge pull request #65 from jglick/messaging-JENKINS-45245

JENKINS-45245 Improve messaging

Compare: https://github.com/jenkinsci/jenkins-test-harness/compare/aa1f33b652a1...2f425413932d

Wishfully assigning to Kohsuke Kawaguchi in hopes that he might know what to do. =)

fwiw, a workaround is to add the actual war file as a library for the module directly. Not from Maven - then it wants to add the dependencies, not the war itself. So that's something.

EDIT: Maybe not. This breaks WebClient stuff.

This was filed as IDEA-175538.

Jesse Glick So, what can we do from the Jenkins end to fix this?  Saying "tell IntelliJ to implement custom ArtifactHandlers" is all good and well, but right now we can't consistently run tests in the current [most popular Java IDE|http://www.baeldung.com/java-in-2017|http://www.baeldung.com/java-in-2017]...] – unless we do dirty hacks like kicking the plugin pom dependency back to 2.29 while testing.  Which will not be suitable forever. 

Unless I'm missing something,  https://github.com/jenkinsci/maven-hpi-plugin/pull/65 just reduces the copies of the WAR present, which hardly seems worth losing the ability to run tests in the IDE.  Is this a case where we could simply revert that until broader support of the ArtifactHandlers is available?  Or at least offer a fallback option if the ArtifactHandler isn't fully supported?

This issue hit me trying to upgrade plugin-pom to ver 2.33 and I can't run tests from inside IntellijIDEA. IDEA is what most java developers use, not able to run tests from inside IDE is huge productivity loss . With modern cheap hard drive and download speed, saving of extra war-for-test is not worth it.

Yeah - Stephen Connolly - I assume you haven't heard anything from JetBrains regarding the issue in IntelliJ? If not, I'd say we should roll this back and wait until IntelliJ can actually support this properly. (cc Jesse Glick)

I wonder if we could apply a hack that would let intellij run the tests...

Ooooh.... I wonder now... dependency types... what happens if we add executable-war as a hack

False dawn

ok, Jesse Glick, what do we need to do revert this? Core needs to start building the war for test again, right?

Well, yes (among other things), but that will not solve the issue for existing core baseline versions.

Better than nothing.

Idea (no pun intended): add a profile to plugin-pom that gets activated under some conditions (say, a property that you as an IDEA user would define in ~/.m2/settings.xml) and which in a very early phase uses dependency:copy / install:install-file or something similar to create an executable-war in your local repository based on the regular war artifact; and which also adds some dependencies which are enough to convince IDEA to add appropriate stuff to the test classpath. Basically the hacks would be limited to this profile (perhaps with the help of some additional mojo in maven-hpi-plugin), unless and until IDEA can be fixed, while CI builds and users of other development environments would be unaffected.

Won't work - the executable-war dependency still breaks everything. This really needs to be rolled back and release-noted for the offending core versions.

First phase of the rollback is up in https://github.com/jenkinsci/jenkins/pull/3029 - which starts building/deploying the war-for-test artifact again.

the executable-war dependency still breaks everything

Can you be more specific? My understanding was that IDEA simply complained that a dependency could not be found in the local repository. So, we change that.

Well, maybe there's magic I don't know how to do, but the following didn't work:

    <profile>
      <id>idea</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>3.0.2</version>
            <executions>
              <execution>
                <id>copy-war</id>
                <phase>validate</phase>
                <goals>
                  <goal>copy</goal>
                </goals>
                <configuration>
                  <artifactItems>
                    <artifactItem>
                      <groupId>org.jenkins-ci.main</groupId>
                      <artifactId>jenkins-war</artifactId>
                      <version>${jenkins.version}</version>
                      <outputDirectory>${project.build.directory}</outputDirectory>
                      <overWrite>true</overWrite>
                      <destFileName>tmp-jenkins.war</destFileName>
                    </artifactItem>
                    <artifactItem>
                      <groupId>org.jenkins-ci.main</groupId>
                      <artifactId>jenkins-war</artifactId>
                      <version>${jenkins.version}</version>
                      <classifier>pom</classifier>
                      <outputDirectory>${project.build.directory}</outputDirectory>
                      <overWrite>true</overWrite>
                      <destFileName>tmp-jenkins.pom</destFileName>
                    </artifactItem>
                  </artifactItems>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.5.2</version>
            <executions>
              <execution>
                <id>install-fake-war</id>
                <phase>validate</phase>
                <goals>
                  <goal>install-file</goal>
                </goals>
                <configuration>
                  <file>${project.build.directory}/tmp-jenkins.war</file>
                  <repositoryLayout>default</repositoryLayout>
                  <classifier>war-for-test</classifier>
                  <packaging>jar</packaging>
                  <pomFile>${project.build.directory}/tmp-jenkins.pom</pomFile>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
      <dependencies>
        <dependency>
          <groupId>org.jenkins-ci.main</groupId>
          <artifactId>jenkins-war</artifactId>
          <version>${jenkins.version}</version>
          <classifier>war-for-test</classifier>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </profile>

(ignore the activeByDefault - just easier for testing)
The war-for-test gets installed but the same Intellij error occurs:

java.lang.AssertionError: jenkins.war is not in the classpath. If you are running this from the core workspace, run 'mvn install' to create the war image in war/target/jenkins

The core point here is that JENKINS-24064 broke stuff, so it should be reverted until a new implementation that doesn't break stuff is found. I really don't think we should be expecting Intellij users to jump through tons of hoops just to save some disk space.

And if need be, we can retroactively deploy war-for-test for the core versions currently missing them, since it's just a copy of the war file with a different file extension and classifier. Trivial enough to do. And I'm happy to have the plugin, jenkins-test-harness, and maven-hpi-plugin changes wait until that's done so that we don't break anything.

PR reverting in plugin-pom up at https://github.com/jenkinsci/plugin-pom/pull/75

and maven-hpi-plugin revert up at https://github.com/jenkinsci/maven-hpi-plugin/pull/77

And finally, jenkins-test-harness at https://github.com/jenkinsci/jenkins-test-harness/pull/72. Obviously these have interwoven dependency fun.

Actually the dependencies there are going to be too late. Try adding a system-scoped dependency to the WAR you have downloaded to the project’s temp dir.

How would that help? Depending on the war in the first place is why we're in this situation in the first place.

Another plausible option: patch WarExploder to fall back to locating jenkins-core.jar, which presumably is there, and then locating the WAR on the assumption that …/jenkins-core/$v/jenkins-core-$v.jar corresponds to …/jenkins-war/$v/jenkins-war-$v.war. You may need another special case for JTH being used inside of jenkinsci/jenkins/test since that is handled a little differently.

...or we could just revert JENKINS-24064. That seems immeasurably simpler.

No, depending on jenkins.war is not a problem. The problem is that IDEA does not understand that this is supposed to be in java.class.path. So you need to either hack up the POM so that it also contains something with a JAR extension, which I think system scope can do; or patch WarExploder so that it can tolerate a malformed classpath.

Note that without the jenkins-war dependency being properly processed, you will be missing some transitive dependencies not present in jenkins-core, such as the various jenkins-module we bundle, and things with core-assets packaging whatever those are. But these are probably irrelevant to most tests—good enough for now.

And no, reverting is not actually simple at all. Working around the problem for IDEA is likely to be significantly more straightforward and less risky.

How is reverting not simple? Serious question. It seems awfully trivial to me.

Also, system scope doesn't work either.

and fwiw, I feel pretty strongly that requiring any manual hacks to settings.xml or Intellij settings in order to run unit tests for a Jenkins plugin isn't an acceptable solution. If a new dev finds that they can't run unit tests for Jenkins plugins in Intellij, but can for, like, every other Java project, we're at best creating friction/pain for them as they google to find out how to make it work, and at worst, we discourage them from running unit tests at all. That's goofy when reverting really does appear to be absolutely trivial.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jvnet/hudson/test/WarExploder.java
http://jenkins-ci.org/commit/jenkins-test-harness/4c9b50065ab49870293680cd47802c56de86f4f2
Log:
JENKINS-45245 Work around failure of IDEA to add jenkins-war.war to the test CP.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jvnet/hudson/test/WarExploder.java
http://jenkins-ci.org/commit/jenkins-test-harness/b45ae9bb02999e82d14dd16f95c1b8fd2b277343
Log:
Merge pull request #73 from jglick/IDEA-is-broken-JENKINS-45245

JENKINS-45245 Work around failure of IDEA to add jenkins-war.war to the test CP

Compare: https://github.com/jenkinsci/jenkins-test-harness/compare/2a12efb35ad1...b45ae9bb0299

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
http://jenkins-ci.org/commit/plugin-pom/8ba282fa56c33266be81bfd21643a2eca369497b
Log:
Update jenkins-test-harness to 2.27 to pick up JENKINS-45245 fix.

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
http://jenkins-ci.org/commit/plugin-pom/ad2a3715aa4c52d7aa7a80ab4ea4eee3431ecbe1
Log:
Merge pull request #76 from jglick/JTH-JENKINS-45245

Update jenkins-test-harness to 2.27 to pick up JENKINS-45245 fix

Compare: https://github.com/jenkinsci/plugin-pom/compare/bd1cf68495e8...ad2a3715aa4c

Should be fixed for users of parent 2.35.

Code changed in jenkins
User: Pavel Grigorenko
Path:
pom.xml
http://jenkins-ci.org/commit/token-macro-plugin/65aec126153cf839602b3ae4c12cf50e027a4eff
Log:
Bumped json-path version to 2.4.0 to solve dependency issue (#32)

• Updated json-path to 2.4.0

• Updated pom parent to 2.35 due to JENKINS-45245

• Fixed NoClassDefFoundErrors in tests

• Parent pom version to 3.2