• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • plugin-proposals
    • None
    • Platform: All, OS: All

      Please consider refactoring CVS, Subversion SCM plugins into downloadable
      standalone components separated from Hudson core. Thanks

          [JENKINS-3101] Refactor CVS support into standalone plugin

          This is obviously a good change, but unfortunately the priority is relatively low.

          If anyone is willing to volunteer, that would be greatly appreciated.

          Kohsuke Kawaguchi added a comment - This is obviously a good change, but unfortunately the priority is relatively low. If anyone is willing to volunteer, that would be greatly appreciated.

          Jesse Glick added a comment -

          .

          Jesse Glick added a comment - .

          gliptak added a comment -

          I committed the initial setup as hudson/plugins/cvs

          Kohsuke,

          The JUnit testcase fails with:

          java.lang.ClassCastException: hudson.scm.NullSCM
          at hudson.plugins.cvs.CVSSCMTest.testConfigRoundtrip(CVSSCMTest.java:20)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

          Is this because of a clash between the current and new CVSSCMTest implementation?

          Thanks

          gliptak added a comment - I committed the initial setup as hudson/plugins/cvs Kohsuke, The JUnit testcase fails with: java.lang.ClassCastException: hudson.scm.NullSCM at hudson.plugins.cvs.CVSSCMTest.testConfigRoundtrip(CVSSCMTest.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Is this because of a clash between the current and new CVSSCMTest implementation? Thanks

          Jesse Glick added a comment -

          I presume you would need to delete all CVS-related code in main/core, not just
          copy it into a plugin. You might need to keep the same class names for
          config.xml compatibility. And you would need to make the CVS plugin a bundled
          plugin in main/war.

          Jesse Glick added a comment - I presume you would need to delete all CVS-related code in main/core, not just copy it into a plugin. You might need to keep the same class names for config.xml compatibility. And you would need to make the CVS plugin a bundled plugin in main/war.

          gliptak added a comment -

          > I presume you would need to delete all CVS-related code in main/core, not just
          copy it into a plugin.

          I hoped to allow transition by implementing in parallel ... But you imply here
          that this is not possible to do.

          > You might need to keep the same class names for config.xml compatibility

          I'm changing package names only.

          > And you would need to make the CVS plugin a bundled plugin in main/war.

          Could you point me to the right direction on this?

          Thanks

          gliptak added a comment - > I presume you would need to delete all CVS-related code in main/core, not just copy it into a plugin. I hoped to allow transition by implementing in parallel ... But you imply here that this is not possible to do. > You might need to keep the same class names for config.xml compatibility I'm changing package names only. > And you would need to make the CVS plugin a bundled plugin in main/war. Could you point me to the right direction on this? Thanks

          Jesse Glick added a comment -

          Of course you can and should get the plugin ready before deleting the original
          code from main/core, but the transition should occur relatively soon to make
          sure there are no changes made only to the main/core copy.

          By "class names" I meant FQNs, which would include the package names. Probably
          best to leave these untouched so that config.xml elements from existing jobs
          will continue to load under the plugin. (I am not sure if it is possible to
          register name translations under XStream. Probably it is, but why bother if you
          don't need to? The Subversion plugin refactoring kept the same class names IIRC.)

          Regarding bundling plugins, it is best to look at how Subversion is handled.
          Look in main/war/pom.xml under "bundled plugins".

          Jesse Glick added a comment - Of course you can and should get the plugin ready before deleting the original code from main/core, but the transition should occur relatively soon to make sure there are no changes made only to the main/core copy. By "class names" I meant FQNs, which would include the package names. Probably best to leave these untouched so that config.xml elements from existing jobs will continue to load under the plugin. (I am not sure if it is possible to register name translations under XStream. Probably it is, but why bother if you don't need to? The Subversion plugin refactoring kept the same class names IIRC.) Regarding bundling plugins, it is best to look at how Subversion is handled. Look in main/war/pom.xml under "bundled plugins".

          Partial changes by gliptak went in as r21458 and r21459.

          r21459 in particular is broken because the CVS code is not yet packaged as a
          plugin, so I'm rolling it back. This change can be only made after CVS is
          successfully converted into a plugin, or else those links would be 404.

          r21548 would likely need to be rolled back, too, as additional changes have
          already been made to the code — such as r21545, r21549, r21601.

          Conversion into a plugin needs to be done in a relatively short time window to
          avoid this kind of overlap. My apologies for not getting back to your
          ClassCastException sooner, but I don't monitor all the issue updates.

          Kohsuke Kawaguchi added a comment - Partial changes by gliptak went in as r21458 and r21459. r21459 in particular is broken because the CVS code is not yet packaged as a plugin, so I'm rolling it back. This change can be only made after CVS is successfully converted into a plugin, or else those links would be 404. r21548 would likely need to be rolled back, too, as additional changes have already been made to the code — such as r21545, r21549, r21601. Conversion into a plugin needs to be done in a relatively short time window to avoid this kind of overlap. My apologies for not getting back to your ClassCastException sooner, but I don't monitor all the issue updates.

          r21459 is already rolled back in r21601, just for a record.

          Kohsuke Kawaguchi added a comment - r21459 is already rolled back in r21601, just for a record.

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/plugins/cvs/pom.xml
          http://fisheye4.cenqua.com/changelog/hudson/?cs=24913
          Log:
          JENKINS-3101 Moving CVS into a separate plugin.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/plugins/cvs/pom.xml http://fisheye4.cenqua.com/changelog/hudson/?cs=24913 Log: JENKINS-3101 Moving CVS into a separate plugin.

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=24930
          Log:
          [FIXED JENKINS-3101] in 1.340. The actual changes for this spread across several changes prior to this (all done within the same day.)

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=24930 Log: [FIXED JENKINS-3101] in 1.340. The actual changes for this spread across several changes prior to this (all done within the same day.)

            kohsuke Kohsuke Kawaguchi
            gliptak gliptak
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: