Can jenkins-ci.org host a plugin that is built elsewhere?

[Scott Cowan]

Hi,

I'm working on a new plugin that has a build dependency on a third party library that isn't available in any public maven repository.  I'd like to host it at jenkins-ci.org but wondering if I can build it myself and "release" the .hpi file so it is available by default in a Jenkins install.  Is this possible, and how does it work?

Thanks in advance,
Scott

[Jesse Glick]

On 01/30/2013 10:26 AM, Scott Cowan wrote:
> I'm working on a new plugin that has a build dependency on a third party library that isn't available in any public maven repository.

So deploy that dependency to the Jenkins repository, then you are all set.

[Scott Cowan]

The terms of the third party library license doesn't allow for that.

[Slide]

So, you can distribute it on the Jenkins update server inside your plugin archive, but you can't put it into a Maven repo? That doesn't seem to jive with me.

--
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 jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Website: http://earl-of-code.com

[KEVIN FLEMING (BLOOMBERG/ 731 LEXIN)]

Yeah, that sounds a bit fishy. In addition, even if the plugin archive didn't include the dependency and required the user to install it in their CLASSPATH some other way (which would be ugly), it seems like such a license would also infect derivative works (such as a plugin that uses the library). Without seeing the license in question that's only a guess, but it would not be surprising.

---

From:	jenkin...@googlegroups.com
To:	jenkin...@googlegroups.com
Date:	1/30 13:53

---

[Jesse Glick]

On 01/30/2013 02:24 PM, KEVIN FLEMING (BLOOMBERG/ 731 LEXIN) wrote:
> even if the plugin archive didn't include the dependency and required the user to install it in their CLASSPATH some other way

…in which case the Maven build probably does not need it, either.

[Scott Cowan]

Jesse, slide & Kevin,

Thank you all for your input.  My understanding is that the terms of use in the license for Rational Team Concert does not allow for redistribution.  I am getting clarification on that, and whether or not deploying it to the Jenkins repository constitutes redistribution.  There's a link to the license from this link, but you have to have a jazz.net account.  Feel free to check it out if you're curious, but be forewarned it is thorough.  ;-)

https://jazz.net/downloads/rational-team-concert/releases/4.0.1/RTC-BuildSystem-Toolkit-Win-4.0.1.zip

We really want to integrate our build support with that of Jenkins.  The two tools complement each other nicely.  IBM and Rational really do promote open source software and integrations with our products.  And if jazz.net can host a public maven repository, we will probably go that route.  In the short term we're just wondering of we can work around the problem by building it ourselves and releasing it periodically.

We're thinking we won't distribute our libraries inside our plugin archive, but rather have a global configuration property that will point to our build toolkit install directory.  Kind of like other source control systems require pointing to the command line executable.  The difference is we want to create a tighter integration than just with source control.  We want to also integrate with our own build results and work items, and none of this integration is currently available in our command line tool.

Does this make sense?  Am I the first person to request this?  Again, thanks for any input/advice you can provide,
Scott

[nicolas de loof]

2013/1/31 Scott Cowan <scott.c...@gmail.com>

Jesse, slide & Kevin,

Thank you all for your input.  My understanding is that the terms of use in the license for Rational Team Concert does not allow for redistribution.  I am getting clarification on that, and whether or not deploying it to the Jenkins repository constitutes redistribution.  There's a link to the license from this link, but you have to have a jazz.net account.  Feel free to check it out if you're curious, but be forewarned it is thorough.  ;-)

https://jazz.net/downloads/rational-team-concert/releases/4.0.1/RTC-BuildSystem-Toolkit-Win-4.0.1.zip

We really want to integrate our build support with that of Jenkins.  The two tools complement each other nicely.  IBM and Rational really do promote open source software and integrations with our products.  And if jazz.net can host a public maven repository, we will probably go that route.  In the short term we're just wondering of we can work around the problem by building it ourselves and releasing it periodically.

We're thinking we won't distribute our libraries inside our plugin archive, but rather have a global configuration property that will point to our build toolkit install directory.  Kind of like other source control systems require pointing to the command line executable.  The difference is we want to create a tighter integration than just with source control.  We want to also integrate with our own build results and work items, and none of this integration is currently available in our command line tool.

Would then be even better to provide an auto-installer for this runtime

 

Does this make sense?  Am I the first person to request this?  Again, thanks for any input/advice you can provide,
Scott

On Wednesday, January 30, 2013 2:43:50 PM UTC-5, Jesse Glick wrote:

On 01/30/2013 02:24 PM, KEVIN FLEMING (BLOOMBERG/ 731 LEXIN) wrote:
> even if the plugin archive didn't include the dependency and required the user to install it in their CLASSPATH some other way

…in which case the Maven build probably does not need it, either.

--

[Jan Ruzicka]

Hi,

The StarTeam plugin has similar problem.

Jar of the Starteam client is not freely redistributable

For same reason the plugin was grandfathered into repository.

The issue is worked around by having the StarTeam jars only in local private repository.

Is this still acceptable solution?

Jan 

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

[Jesse Glick]

On 01/31/2013 06:59 PM, Jan Ruzicka wrote:
> The issue is worked around by having the StarTeam jars only in local private repository.

Another solution would be to create a sister jar-packaging Maven project (under a pom-packaging parent) containing stubs for all the classes/methods you use from the
nonredistributable API. Then just make this a provided-scope dependency of the hpi project, and load the real JAR using a URLClassLoader at runtime based on a configured
installation location.

[Nick Edgar]

Hi, I work with Scott on Rational Team Concert.  I'm the RTC Build component lead.

That's an interesting suggestion, Jesse.  Currently we're compiling against the RTC client libraries using Eclipse Tycho, with our plugin POM configured to point to an Eclipse P2 repository containing the client libs.  At runtime, we do poof up a URLClassLoader, based on the configured path to the RTC build toolkit (a global config option for our plugin).  Having a library of stubs just to allow compilation is a possibility too.  Another option we've explored is running a script to import the client lib jars into the local Maven repo, but currently Tycho is working OK for us.  One downside is that the P2 repository is an external dependency, and thus somewhat contrary to the spirit of Maven.

We'd really like for our plugin to be included in Jenkins' library of plugins.  We're also planning to contribute the source to the Jenkins project, and are currently seeking clearance to do so.

What I'd like to understand better is what the general requirements are for compiling/building/packaging Jenkins plugins.  Is it possible to contribute just the built .hpi file?  If the source is contributed, is it normally compiled together with the main Jenkins code for each build?  What about running tests?  I assume you don't have every possible SCM system available in the Jenkins build farm.  What do you do for other plugins for other commercial SCM systems such as StarTeam, ClearCase, etc.

Also, we do realize that there's an existing Jenkins plugin for RTC, written by Deluan Quintao.  Deluan says he has moved on to other work, and is not actively maintaining the plugin.  Our current state of implementation is roughly equivalent to his, but works directly against the RTC client libraries, whereas his invokes the RTC SCM CLI, which has a significant startup cost.  We also have some other concerns about the scalability of the current plugin, and how it processes change sets.  Over the next few months, we'll be adding more features to more tightly integrate with RTC, e.g. at the level of RTC Builds, not just SCM.  Our intent is to provide an "official" IBM Rational RTC plugin, which we will continue to develop and support, in addition to accepting contributions from the Jenkins community.

Thank you all in advance for helping us through the process of getting this contributed in a way that's acceptable to all involved.

Regards,

Nick

[Nick Edgar]

Hi Jan, forgot to thank you for this info yesterday.  Can you please clarify what you mean by "grandfathered into repository"?  Do you mean that you contribute just the binary .hpi file and build it yourself?

Do you know whether this is still an option ("grandfathered" usually means it was a one-time exception)?

Thanks,

Nick

[Jesse Glick]

On 01/31/2013 08:41 PM, Nick Edgar wrote:
> what the general requirements are for compiling/building/packaging Jenkins plugins.

$ git clone git://github.com/jenkinsci/${id}-plugin.git && mvn -f ${id}-plugin/pom.xml package

Normally updates are released by developers when they feel ready, using

$ mvn -B release:prepare release:perform

> Is it possible to contribute just the built .hpi file?

Of course you can make any plugin freely downloadable from wherever you choose and, if desired, host its sources in whatever form and however you choose. But I suppose
what you are really asking is whether you can make your *.hpi available on the standard update center [1].

I do not know of any precedent for publishing a plugin in this fashion without it also being buildable in the conventional way from source. I do know of a plugin from
Sonatype [2] which just adds an extra update center to Jenkins—then they host their “real” plugins (not OSS) on their own server. So you make it straightforward for users
to obtain your integration, without any particular requirements on how it is built and deployed.

> If the source is contributed, is it normally compiled together with the main Jenkins code for each build?

No, the POM just refers to whatever baseline Jenkins release you prefer to assume. (An LTS such as 1.480 is typical.) Plugins and core are published on independent timelines.

> What about running tests?

Nothing special, handled by Maven. (The standard plugin parent POM defines a test dependency on org.jenkins-ci.main:jenkins-test-harness which allows you to write
functional tests.)

> I assume you don't have every possible SCM system available in the Jenkins build farm.

Most plugins are hosted on GitHub. A few are still kept in Subversion but this is discouraged.


[1] http://updates.jenkins-ci.org/download/plugins/
[2] https://github.com/sonatype/sonatype-ci-for-jenkins

[Jan Ruzicka]

Nick,

I compile and test the StarTeam plugin myself and then push to repository.
It is done using the release:prepare, release:perform steps.
The plugin source is on github.

The grandfathered was alluding to the history of the StarTeam plugin.
It was started in times when Jenkins was Hudson and lived happily in Sun's subversion repository.
:-)

Jan

[Nick Edgar]

Thanks for the info, Jesse and Scott.  We will proceed with getting our plugin into shape to be contributed.  We'll likely end up using stubs, as Jesse suggested, so that the plugin can be compiled separately from RTC, and functional tested wrt Jenkins (but not RTC) at package time.

When it comes to contributing the source, is it better for us to put it up in a separate github project and pull from there, or open one directly under jenkins-ci to start off?

Thanks,

Nick

[Nick Edgar]

Sorry, I meant Jesse and Jan.

[Jesse Glick]

On 02/04/2013 11:10 AM, Nick Edgar wrote:
> When it comes to contributing the source, is it better for us to put it up in a separate github project and pull from there

I guess you mean “in our own GitHub organization”. This is fine—it is simple to clone into the jenkinsci org. But if you have a local repo ready and would prefer to push
directly into a fresh repo under jenkinsci, just ask on the list for a committer on IRC to

jenkins-admin: Create whatever-plugin on github for nedgar

and an empty repo will be prepared in jenkinsci with you given push access.