Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45245

Cannot run tests in IntelliJ IDEA with plugin parent POM 2.30

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Specifically seems to be maven-hpi-plugin 2.0 that's causing this, with the JENKINS-24064 fix. Now we get an error like

      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
      

      whenever trying to run tests. Jesse Glick says this is due to Intellij not honoring https://github.com/jenkinsci/maven-hpi-plugin/blob/137e435d0770f78edbbd2ed54d91809b7e7be5aa/src/main/resources/META-INF/plexus/components.xml#L134, so we need to figure out how to, like, get it to honor that.

        Attachments

          Issue Links

            Activity

            abayer Andrew Bayer created issue -
            abayer Andrew Bayer made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-24064 [ JENKINS-24064 ]
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            jglick Jesse Glick made changes -
            Component/s jenkins-test-harness [ 21462 ]
            Component/s core [ 15593 ]
            jglick Jesse Glick made changes -
            Remote Link This issue links to "jenkins-test-harness PR 65 (Web Link)" [ 17194 ]
            Hide
            jglick Jesse Glick added a comment -

            BTW the change was introduced in 2.30, not 2.31.

            Show
            jglick Jesse Glick added a comment - BTW the change was introduced in 2.30, not 2.31.
            jglick Jesse Glick made changes -
            Summary Cannot run tests in Intellij with plugin parent POM 2.31+ Cannot run tests in IntelliJ IDEA with plugin parent POM 2.30
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            abayer Andrew Bayer made changes -
            Assignee Kohsuke Kawaguchi [ ci_jenkinsci_org ]
            abayer Andrew Bayer made changes -
            Assignee Kohsuke Kawaguchi [ ci_jenkinsci_org ] Kohsuke Kawaguchi [ kohsuke ]
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Wishfully assigning to Kohsuke Kawaguchi in hopes that he might know what to do. =)
            Hide
            abayer Andrew Bayer added a comment - - edited

            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.

            Show
            abayer Andrew Bayer added a comment - - edited 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.
            jglick Jesse Glick made changes -
            Assignee Kohsuke Kawaguchi [ kohsuke ]
            Hide
            jglick Jesse Glick added a comment -

            This was filed as IDEA-175538.

            Show
            jglick Jesse Glick added a comment - This was filed as IDEA-175538 .
            jglick Jesse Glick made changes -
            Resolution Not A Defect [ 7 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            svanoort Sam Van Oort added a comment -

            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?

            Show
            svanoort Sam Van Oort added a comment - 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?
            svanoort Sam Van Oort made changes -
            Resolution Not A Defect [ 7 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            vivek Vivek Pandey added a comment -

            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.

            Show
            vivek Vivek Pandey added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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)

            Show
            abayer Andrew Bayer added a comment - 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 )
            abayer Andrew Bayer made changes -
            Priority Minor [ 4 ] Critical [ 2 ]
            Hide
            stephenconnolly Stephen Connolly added a comment -

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

            Show
            stephenconnolly Stephen Connolly added a comment - I wonder if we could apply a hack that would let intellij run the tests...
            stephenconnolly Stephen Connolly made changes -
            Hide
            stephenconnolly Stephen Connolly added a comment -

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

            Show
            stephenconnolly Stephen Connolly added a comment - Ooooh.... I wonder now... dependency types... what happens if we add executable-war as a hack
            stephenconnolly Stephen Connolly made changes -
            Attachment sad panda2.png [ 39729 ]
            Hide
            stephenconnolly Stephen Connolly added a comment - - edited

            False dawn

            Show
            stephenconnolly Stephen Connolly added a comment - - edited False dawn
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - ok, Jesse Glick , what do we need to do revert this? Core needs to start building the war for test again, right?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Well, yes (among other things), but that will not solve the issue for existing core baseline versions.
            Hide
            abayer Andrew Bayer added a comment -

            Better than nothing.

            Show
            abayer Andrew Bayer added a comment - Better than nothing.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "jenkins.git PR #3029 (Web Link)" [ 17736 ]
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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
            
            Show
            abayer Andrew Bayer added a comment - 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
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment - - edited

            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.

            Show
            abayer Andrew Bayer added a comment - - edited 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.
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - PR reverting in plugin-pom up at https://github.com/jenkinsci/plugin-pom/pull/75
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "plugin-pom PR #75 (Web Link)" [ 17737 ]
            Hide
            abayer Andrew Bayer added a comment -
            Show
            abayer Andrew Bayer added a comment - and maven-hpi-plugin revert up at https://github.com/jenkinsci/maven-hpi-plugin/pull/77
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "maven-hpi PR #77 (Web Link)" [ 17738 ]
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "jenkins-test-harness PR #72 (Web Link)" [ 17739 ]
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - And finally, jenkins-test-harness at https://github.com/jenkinsci/jenkins-test-harness/pull/72 . Obviously these have interwoven dependency fun.
            abayer Andrew Bayer made changes -
            Assignee Andrew Bayer [ abayer ]
            abayer Andrew Bayer made changes -
            Status Reopened [ 4 ] In Progress [ 3 ]
            abayer Andrew Bayer made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            abayer Andrew Bayer made changes -
            Link This issue relates to INFRA-1342 [ INFRA-1342 ]
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - How would that help? Depending on the war in the first place is why we're in this situation in the first place.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - ...or we could just revert JENKINS-24064 . That seems immeasurably simpler.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - How is reverting not simple? Serious question. It seems awfully trivial to me.
            Hide
            abayer Andrew Bayer added a comment -

            Also, system scope doesn't work either.

            Show
            abayer Andrew Bayer added a comment - Also, system scope doesn't work either.
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            jglick Jesse Glick made changes -
            Remote Link This issue links to "jenkins-test-harness PR 73 (Web Link)" [ 17740 ]
            jglick Jesse Glick made changes -
            Assignee Andrew Bayer [ abayer ] Jesse Glick [ jglick ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            jglick Jesse Glick made changes -
            Remote Link This issue links to "plugin-pom PR 76 (Web Link)" [ 17744 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            jglick Jesse Glick added a comment -

            Should be fixed for users of parent 2.35.

            Show
            jglick Jesse Glick added a comment - Should be fixed for users of parent 2.35.
            jglick Jesse Glick made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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
            • Fixed NoClassDefFoundErrors in tests
            • Parent pom version to 3.2
            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              abayer Andrew Bayer
              Votes:
              4 Vote for this issue
              Watchers:
              11 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: