documentation on The right way to start a new plugin ?
Henrik Lynggaard
I am trying to get a firm grib of the best way to start a new plugin,
esp. given the infrastructure changes such as github. I am reading up
on the wiki pages, there is a a lot of information, but it appears a
bit scattered.Some of it is in email threads linked from wiki.
I am trying to answer relative simple questions like
* Which logins are needed to fully develop a plugin (github
+java.net?)
* Github: how to create a blank plugin repo, Is it best to start with
your own repo and let hudson fork or ?
* How to get jira, wiki page, hudson on hudson etc. setup
* What needs to be in the pom file in order to release a plugin.
* What is the requirements for being included in the update center ?
* Can I host the code anywhere, and just release to java.net ? if so
how
I was considering starting collecting the answers on a wiki page (in
my personal space as a draft), but I don't know if that is the
preferred way?
Best regards
Henrik
Ullrich Hafner
> Hi
>
> I am trying to get a firm grib of the best way to start a new plugin,
> esp. given the infrastructure changes such as github. I am reading up
> on the wiki pages, there is a a lot of information, but it appears a
> bit scattered.Some of it is in email threads linked from wiki.
>
>
> I am trying to answer relative simple questions like
> * Which logins are needed to fully develop a plugin (github
> +java.net?)
When developing a plug-in you only need access to the source code
repository, i.e. if you want to use git then you need a github account,
if you want to use subversion, then you need a java.net account.
> * Github: how to create a blank plugin repo, Is it best to start with
> your own repo and let hudson fork or ?
> * How to get jira, wiki page, hudson on hudson etc. setup
For Jira and Confluence you need to have a java.net account. Then write
to the dev list that you would like to have a Jira component and a CI job.
> * What needs to be in the pom file in order to release a plugin.
You should derive from the plugin parent pom and you should reference
the license and author of your plug-in. Maybe we should publish an
example pom in the wiki where everybody can start with. Isn't such a pom
part of the maven hpi archetype? Here is an example from one of my plug-ins:
http://fisheye.hudson-labs.org/browse/Hudson/trunk/hudson/plugins/analysis-pom/pom.xml?r=38062
> * What is the requirements for being included in the update center ?
Just one public release of your plug-in.
> * Can I host the code anywhere, and just release to java.net ? if so
> how
This is discouraged since other developers may like to improve your
plug-in or add patches which is easier if the same repository is used.
> I was considering starting collecting the answers on a wiki page (in
> my personal space as a draft), but I don't know if that is the
> preferred way?
>
Collecting that information in the wiki is very good:-) Please move your
page to the Hudson space and create a corresponding link in the
developers section so everyone will see it.
Ulli
> Best regards
> Henrik
>
>
>
>
>
>
>
>
vtintillier
Henrik Lynggaard
> > * What is the requirements for being included in the update center ?
>
> Just one public release of your plug-in.
accepted. And all the "vendor" needs to do is create a java.net
account and push the release button ?
> > * Can I host the code anywhere, and just release to java.net ? if so
> > how
>
> This is discouraged since other developers may like to improve your
> plug-in or add patches which is easier if the same repository is used.
still like to document any requirements as there might be situations
where it would be more appropriate to have the code elsewhere.. Let us
say I am developing one web application or other big projects with its
own scm, website etc. and that project want to integrate with hudson
(thinks things like jira,sonar etc). It might be better to have the
hudson plugin together with the main application rather than rest of
the plugins. relevance depends on the context and audience...
So can I have my source code anywhere as long as I have a java.net
account in order to release ?
Best regards
henrik
Kohsuke Kawaguchi
I think it'd be great if you can update Wiki with some of these
information in this thread. A fresh perspective always help in getting
good docs, as so many things becomes "too obvious" when you do it
several times, and that reflects in the doc that we write.
So far we haven't had this issue before --- we've been politely asking
people to bring their source code to our community, and everyone was OK
with it. We never had a closed source plugin available in our update
center thus far. The JIRA plugin and the sonar plugin lives with us, so
is the Artifactory plugin.
The co-location of the plugin really served us well, in that it ensures
continuity. A lot of time, the original people who wrote the plugin
moves on, and it's taken over by other people. It's a lot harder to
happen if the plugins are scattered around. It also helps us reduce the
risk of having similar but different plugins.
So given that history, I'd say our current requirement is that you do
host the source code with us. But if there's a good case to be made
against that, we'd love to hear.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Henrik Lynggaard
> I think it'd be great if you can update Wiki with some of these
> information in this thread. A fresh perspective always help in getting
> good docs, as so many things becomes "too obvious" when you do it
> several times, and that reflects in the doc that we write.
until people here have read it
> So far we haven't had this issue before --- we've been politely asking
> people to bring their source code to our community, and everyone was OK
> with it. We never had a closed source plugin available in our update
> center thus far. The JIRA plugin and the sonar plugin lives with us, so
> is the Artifactory plugin.
(http://www.rallydev.com/agile_products/integrations/
continuous_build/). (As far as I can tell it is closed source as I
don't have a rally login)
As a Hudson administrator, it would be nice if such plug ins was in a
update centre. Preferably in the default update center, but if I could
easily add extra update centres that would be fine.
> The co-location of the plugin really served us well, in that it ensures
> continuity. A lot of time, the original people who wrote the plugin
> moves on, and it's taken over by other people. It's a lot harder to
> happen if the plugins are scattered around. It also helps us reduce the
> risk of having similar but different plugins.
>
> So given that history, I'd say our current requirement is that you do
> host the source code with us. But if there's a good case to be made
> against that, we'd love to hear.
gather information for the new pages.
However a Jira style project would actually be a good example. They
might have plug-ins for multiple CI-servers such as Hudson,
CruiseControl etc. It would seen from the project point of view make
good sense to have these plugins reside next to the API they are using
for communications with the rest of the "jira" code. It would also
ensure the developers comming and goifn from "jira" would be aware of
the plugin and maintain it.
I think it is really about context and where one's focus is for hudson
it is better it is here, but for jira it makes sense to group the ci-
server plugins. Anyways I am not trying to change the rules as I don't
have an issue, I was just replying with an example.
Best regards
henrik
Henrik Lynggaard
> to the dev list that you would like to have a Jira component and a CI job.
ci.org) does not seem to be in sync for my account, Are we sure they
share user database ?
Best regards
Henrik
Kohsuke Kawaguchi
> On 25 Jan., 20:05, Kohsuke Kawaguchi<kkawagu...@cloudbees.com> wrote:
>> I think it'd be great if you can update Wiki with some of these
>> information in this thread. A fresh perspective always help in getting
>> good docs, as so many things becomes "too obvious" when you do it
>> several times, and that reflects in the doc that we write.
>
> Thank you, I will give it a try. and mark it with a big DRAFT on top
> until people here have read it
>
>> So far we haven't had this issue before --- we've been politely asking
>> people to bring their source code to our community, and everyone was OK
>> with it. We never had a closed source plugin available in our update
>> center thus far. The JIRA plugin and the sonar plugin lives with us, so
>> is the Artifactory plugin.
>
> With regards to closed sourced plugins I know of at least Rallydev.
> (http://www.rallydev.com/agile_products/integrations/
> continuous_build/). (As far as I can tell it is closed source as I
> don't have a rally login)
Good catch. It is actually open-source (the last time I checked it was
in SourceForge), but you are right that it's not co-located with us.
I should write to them to see what they say.
Kohsuke Kawaguchi
For unfortunate historical reasons, Wiki uses its own user database and
JIRA is linked to java.net
> Best regards
> Henrik
Henrik Lynggaard
> Good catch. It is actually open-source (the last time I checked it was
> in SourceForge), but you are right that it's not co-located with us.
>
> I should write to them to see what they say.
>
plugin is now at http://agilecommons.org/posts/347cf00b5d"
I have tried to access that page, but it looks like only rally
customers are allowed, and if you look at the participate menu I see
no reference to source code?
Henrik Lynggaard
Given the new situation with two branches of development I would urge
you to reconsider the requirement of co-location of the source code in
order to be accepted in the update center.
I am all about not picking sides and trying to contribute in a way
that serves both branches, and in that scenario it makes sense to
place the code some place neutral, at least until we see where things
are heading.
On Jan 25, 8:05 pm, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:
Richard Bywater
Jenkins & Hudson on a common plugin format if possible so that plugins
can be shared. Otherwise we'll end up people having to write two
versions of a plugin...
Richard.
Nigel Magnay
Kohsuke Kawaguchi
Yeah, I think that's fair.
Kohsuke Kawaguchi
> To that end, I wonder if it would be possible to also agree between
> can be shared. Otherwise we'll end up people having to write two
> versions of a plugin...
The format of the plugin is fairly well-established, so fracturing
caused by it is of little concern. The bigger problem is the eventual
divergence of the API, and it's hard to predict if/how that happens.
One approach that works is to restrict yourself to Hudson <= 1.395,
which would work with both versions so long as the backward
compatibility is maintained.