Can you elaborate on "evil job type"? Is there a specific reason why we should avoid maven jobs and go with freestyle?
Yes, setting up a REST service is a valid alternative to remoting. I'm still interested in PlexusModuleContributor though. That makes it a lot easier to actually get the build extension loaded inside maven. Otherwise I would have to make sure all jobs modify their poms. Of course that still requires maven style jobs... On Wed, Sep 10, 2014 at 4:21 PM, Stephen Connolly < [email protected]> wrote: > Forgot to add, if you do it the way I am suggesting then freestyle builds > will get the enhancements for free > > On 10 September 2014 15:20, Stephen Connolly < > [email protected]> wrote: > >> I think that is a very silly way to go about things. Here is why: >> >> 1. It forces people to use the "evil job type" >> 2. It exposes you to all the issues of classloading hell >> 3. I'll say it again: classloading hell >> >> What I think you should do instead is develop a Jenkins plugin that >> exposes a REST api (on the build slave or on the master at a push... but >> you get more issues with firewalls when you force slaves to connect to the >> master). You can then have a BuildWrapper start up the REST api for that >> specific project and set an environment variable to the REST endpoint. >> >> Then you write your Maven plugin to do no-op if the environment variable >> is not defined, or to connect to the REST api if it is defined. >> >> That has the advantage of allowing very fine grained control of security >> of the operations performed... only those operations you choose to expose >> will be available. >> >> It doesn't need to be a REST api by the way, it could be a simple socket >> based protocol >> >> On 10 September 2014 15:09, Wannes Sels <[email protected]> wrote: >> >>> I want to create a jenkins-aware maven build extension. Specifically I >>> want to keep some global state during builds, and transfer files between >>> slaves. Using remoting seems like the obvious and easiest way to go. I have >>> a few questions on how to proceed. >>> >>> Remoting only happens in maven project. Most of our project are now >>> freestyle projects with maven calls, but they can probably be converted to >>> maven projects. Is there concensus on freestyle vs maven style projects? Is >>> there a reason for no remoting on maven call in freestyle projects? >>> >>> I can use a PlexusModuleContributorFactory to load .jar files in maven. >>> With some maven voodoo (dependency:copy-dependencies & >>> dependency:build-classpath) I can probably package all needed jars in a >>> jenkins plugin. How do I use that to provide a list of URLs for the >>> PlexusModuleContributor? Do I point to >>> ${JENKINS_CONTEXT_PATH}/plugin/SHORTNAME/dependencies.jar ? That seems >>> inefficient, and could potentially run in to authorization issues. Or >>> should I somehow copy the .jar files to the slave? In that case I would >>> rather have PlexusModuleContributor return a list of FilePaths, and let >>> MavenXProcessFactory.InstallPlexusModulesTask take care of local file/url >>> setup. >>> Is there an example of a plugin using PlexusModuleContributorFactory? >>> >>> For now I've sidestepped this issue and just dropped my build extension >>> + dependencies in MAVEN_HOME/lib/ext. Now I get ClassNotFoundException: >>> Channel because the remoting.jar is loaded in realm "hudson-remoting", a >>> child of realm "plexus.core". MavenXMain.addPlexusComponents() has the same >>> behaviour. Should it perhaps use a new child realm of "hudson-remoting"? Or >>> should PlexusModuleContributor be able to specify its realm? >>> >>> An alternative solution would be to include my own copy of remoting.jar >>> and have the jenkins plugin set up a separate channel to the slave computer >>> (or directly to master?), passing tcp port via environment properties. It's >>> not the cleanest solution, but it looks like it would be a lot easier to >>> implement. >>> >>> >>> >>> Wannes >>> >>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
