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.

Reply via email to