documentation on The right way to start a new plugin ?

17 visninger
Gå til det første ulæste indlæg

Henrik Lynggaard

ulæst,
24. jan. 2011 16.01.1424.01.2011
til Hudson Developers
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?)
* 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

ulæst,
25. jan. 2011 03.34.4625.01.2011
til hudso...@googlegroups.com
On 01/24/2011 10:01 PM, Henrik Lynggaard wrote:
> 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

ulæst,
25. jan. 2011 03.48.4925.01.2011
til hudso...@googlegroups.com
But don't we always need a java.net account to release to the maven repo?

Ullrich Hafner

ulæst,
25. jan. 2011 03.52.2325.01.2011
til hudso...@googlegroups.com
Yes, as soon as you would like to release your plug-in, you need a java.net account.

So the best thing is to get your java.net and github account in one step.

Ulli

Henrik Lynggaard

ulæst,
25. jan. 2011 13.25.3725.01.2011
til Hudson Developers
On 25 Jan., 09:34, Ullrich Hafner <ullrich.haf...@gmail.com> wrote:
> > * What is the requirements for being included in the update center ?
>
> Just one public release of your plug-in.

By that statement you indicate that also closed source plugins are
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.


I know this is discouraged and I agree with that, however I would
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

ulæst,
25. jan. 2011 14.05.1425.01.2011
til hudso...@googlegroups.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.

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

ulæst,
25. jan. 2011 16.33.2125.01.2011
til Hudson Developers
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)

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.

It is not that I have the issue at the moment, I am just trying to
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

ulæst,
25. jan. 2011 17.04.3625.01.2011
til Hudson Developers
On 25 Jan., 09:34, Ullrich Hafner <ullrich.haf...@gmail.com> wrote:

> 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.

The password for the wiki (wiki.hudson-ci.org) and jira (issues.hudson-
ci.org) does not seem to be in sync for my account, Are we sure they
share user database ?

Best regards
Henrik

Kohsuke Kawaguchi

ulæst,
25. jan. 2011 17.19.3925.01.2011
til hudso...@googlegroups.com, Henrik Lynggaard
On 01/25/2011 01:33 PM, Henrik Lynggaard wrote:
> 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

ulæst,
25. jan. 2011 17.21.3825.01.2011
til hudso...@googlegroups.com, Henrik Lynggaard

For unfortunate historical reasons, Wiki uses its own user database and
JIRA is linked to java.net

> Best regards
> Henrik

Henrik Lynggaard

ulæst,
25. jan. 2011 18.51.1425.01.2011
til Hudson Developers
>
> 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.
>
The hudson plugin has moved away from source forge "NOTE: The Hudson
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

ulæst,
1. feb. 2011 15.55.4001.02.2011
til Jenkins Developers
Hi

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

ulæst,
1. feb. 2011 16.00.1701.02.2011
til jenkin...@googlegroups.com
To that end, I wonder if it would be possible to also agree between
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

ulæst,
1. feb. 2011 16.09.5401.02.2011
til jenkin...@googlegroups.com
I rather suspect that since Oracle clearly has no intention of taking part in Jenkins, and Sonatype announced they are to push changes into Hudson, then whilst plugins may retain compatibility in the short term, I wouldn't bet that this will be true for very much longer.

Bearing in mind the outcome of the vote (which included all of the plugin developers themselves), I'd suggest that maintaining compatibility with whatever the other branch is doing isn't an itch most people on either side of the fence are that interested in scratching.

Kohsuke Kawaguchi

ulæst,
1. feb. 2011 16.09.3101.02.2011
til jenkin...@googlegroups.com, Henrik Lynggaard

Yeah, I think that's fair.

Kohsuke Kawaguchi

ulæst,
1. feb. 2011 16.11.4601.02.2011
til jenkin...@googlegroups.com, Richard Bywater
On 02/01/2011 01:00 PM, Richard Bywater wrote:
> To that end, I wonder if it would be possible to also agree between
> 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...

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.

Henrik Lynggaard

ulæst,
1. feb. 2011 16.45.2001.02.2011
til Jenkins Developers
Thank you :-)



On Feb 1, 10:09 pm, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
Svar alle
Svar forfatteren
Videresend
0 nye indlæg