Automatic process to detect SNAPSHOT dependencies to avoid problem before Maven Release

[pVML]

Hi,

We migrated all of our projects from ant to maven and now we've some
multi module maven projects and one in particular is our main
application and it's a big multi module project.

In last months, we're having some problem due to the internal
dependencies of our projects and the SNAPSHOTS versions in pom.xml.

It's usually forget one SNAPSHOT dependency in one pom.xml and this is
only detected when we try to release our product (maven error tell us
that we've SNAPSHOT dependencies). This bring to us some problems
because we want to release our product quickly, simple and without
developer interaction (this process must be made by versioning team).

Can we have an automatic process to make this check? It's the best way
to do it? Do you have any suggestion?

Thanks in advance for your help!

[Nord, James]

Maven can do this for you.

Enforcer plugin and the require release dependencies http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html

You will probably want to excluded all your project modules (as they will be snapshots when you are working on the project).

Or are you just looking for a way to mark the build as unstable if it contains any snapshot dependencies?
If so you may be able to do something like add the goal "dependency:list" after other maven goals and use the text scanner to find any occurrences of "-SNAPSHOT"
https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin

/James

Hi,

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Swindells, Thomas]

Of course another method is just to have strict code review guidelines which reject changes if they change poms to reference SNAPSHOT versions of external dependencies.

Thomas

[pVML]

Thanks for your suggestions!

@James: Maven-enforcer-plugin is a good solution for our problem, I
think so! You think that we can configure a job to run this plugin and
report if there is a SNAPSHOT dependency in our poms? Or this
verification should allways run in a "clean install" or "clean deploy"
command?

@ Thomas: The problem of this solution is that it depends on human
verification and our team is really big (50+). There is an automatic
way to do this? Some of the SNAPSHOT dependencies are internal but
they are independent projects (internal libs or frameworks
dependencies) and they are versioned only some days before the product
due to internal needs.

Thanks!

On May 4, 1:26 pm, "Swindells, Thomas" <TSwinde...@nds.com> wrote:
> Of course another method is just to have strict code review guidelines which reject changes if they change poms to reference SNAPSHOT versions of external dependencies.
>
> Thomas
>
> -----Original Message-----
> From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Nord, James
> Sent: Wednesday, May 04, 2011 1:05 PM
> To: jenkins...@googlegroups.com
> Subject: RE: Automatic process to detect SNAPSHOT dependencies to avoid problem before Maven Release
>
> Maven can do this for you.
>

> Enforcer plugin and the require release dependencieshttp://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html

>
> You will probably want to excluded all your project modules (as they will be snapshots when you are working on the project).
>
> Or are you just looking for a way to mark the build as unstable if it contains any snapshot dependencies?
> If so you may be able to do something like add the goal "dependency:list" after other maven goals and use the text scanner to find any occurrences of "-SNAPSHOT"https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin
>
> /James
>
> -----Original Message-----
> From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of pVML
> Sent: 04 May 2011 12:08
> To: Jenkins Users
> Subject: Automatic process to detect SNAPSHOT dependencies to avoid problem before Maven Release
>
> Hi,
>
> We migrated all of our projects from ant to maven and now we've some multi module maven projects and one in particular is our main application and it's a big multi module project.
>
> In last months, we're having some problem due to the internal dependencies of our projects and the SNAPSHOTS  versions in pom.xml.
>
> It's usually forget one SNAPSHOT dependency in one pom.xml and this is only detected when we try to release our product (maven error tell us that we've SNAPSHOT dependencies). This bring to us some problems because we want to  release our product quickly, simple and without developer interaction (this process must be made by versioning team).
>
> Can we have an automatic process to make this check? It's the best way to do it? Do you have any suggestion?
>
> Thanks in advance for your help!
>
> **************************************************************************************

> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

[Swindells, Thomas]

What do you actually want to achieve?
From what you've just said you want to allow SNAPSHOT versions of some projects from outside of your multi-module build - if this is the case then you seem to be saying that the only time you are sure you don't want SNAPSHOT versions is when the project is release - which is the state you are in at the moment?

If you want an easy way to review what dependencies are being used you can use the dependency:list goal to print them out - with a bit of regex'ing you could write a pattern to grep out all the SNAPSHOT versions that don't match permitted groupIds/artifact ids and then do something with this output..

Thomas

Thanks for your suggestions!

Thanks!

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

[pVML]

At this moment we are at a bug fixing period and most of the
dependencies outside the multi module project are closed. I want to
control the changes that are made in the poms to guarantee that
versioning team can release the product without problems in the
release date. Maybe, this is a problem of our development methodology
instead of a maven or jenkins question.

What is the recomended way to build a big project and have a QC
environment? Are you able to suggest anything?

Thanks for your help!

> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

[Messmer, Jason]

http://www.infoq.com/news/2011/05/eclipse-hudson

[pVML]

Just to update to the original subject...

> > > Registered no.3080780. VAT no. GB603 8808 40-00
> > > **********************************************************************
> > > ****************
>

> > *************************************************************************** ***********
> > This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>

> > NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no.3080780. VAT no. GB603 8808 40-00
> > *************************************************************************** ***********

[David Weintraub]

Will this help heal the rift between Hudson and Jenkins?

I've subscribe to both the Hudson and Jenkins list and notice most of
the user traffic is with Jenkins. What is Kohsuke's view on the whole
thing? Is he being involved in this?

--
David Weintraub
qaz...@gmail.com

[Andrew Bayer]

Kohsuke has a blogpost up: http://kohsuke.org/2011/05/04/oracle-proposes-to-move-hudson-to-eclipse/

A.

[Richard Bywater]

So guess the question that I have, is that if the proposal was changeable to include KK as a Project Lead, would this be a possible thing for the Jenkins community? (Note I don't know how Eclipse governance structures work so don't know if that's even possible)

Richard.

[R. Tyler Croy]

On Wed, 04 May 2011, David Weintraub wrote:

> Will this help heal the rift between Hudson and Jenkins?
>
> I've subscribe to both the Hudson and Jenkins list and notice most of
> the user traffic is with Jenkins. What is Kohsuke's view on the whole
> thing? Is he being involved in this?

Setting aside previous politics between the Jenkins developer community and
Oracle.

We are currently working on a couple of independent options as umbrella
organizations following what the interim governance board has agreed upon in
our *very* public meetings: <http://meetings.jenkins-ci.org/jenkins/2011/>

My question to you and perhaps all the other folks out there asking the
question "will they merge?": what does the Jenkins community have to gain from
Hudson *at all*?

IMHO, the Jenkins brand is now getting stronger than Hudson ever was, the
community is stronger than before (yay github!), we have a fancy new logo
decided upon by the community, and we're on track to get more support from a
variety of organizations including formalizing our governance and trademark
under a neutral 3rd party organization.

When we parted ways with Oracle, they were offered a seat on the interim board
which they declined.

This move to me /feels/ like an attempt for Oracle/Sonatype to save face after
learning the same lesson that OpenOffice.org learned from LibreOffice.

I personally see *zero* benefit from Hudson and Jenkins merging in the future.

Long live Jenkins :)

Cheers

- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Chatter: http://identi.ca/agentdero
http://twitter.com/agentdero

[Nigel Magnay]

On Wed, May 4, 2011 at 10:11 PM, David Weintraub <qaz...@gmail.com> wrote:

Will this help heal the rift between Hudson and Jenkins?

Aka - will the two branches merge under the Eclipse-hosted Hudson project ?

Going out on a limb, and notwithstanding the bad blood which Oracle is still poisoning with inaccurate briefings, but I'd say it's now actually less likely; Eclipse is such a developer-unfriendly place to work (some might say it's a large legal firm with a small software development capability that's largely devoted to pontification about OSGi...).

The Jenkins contributors have been looking at various options for trademark/legal protection and/or governance, such as ASF, SFLC and others, and these are at the 'which are possible' stage. As far as I am aware, there has been nobody actively wanting to move to eclipse, and others who are undoubtedly strongly against such a move.

Even Hudson's move to eclipse isn't a foregone conclusion from what I can see. From the Oracle proposal, they intend to license the Hudson project under the Eclipse Public License. Similarly, they are seemingly wishing to 'auto-enroll' plugins into a similar scheme, re-licensing under the EPL.

IANAL, but I don't think that's possible without the consent of all the copyright holders. I think it's possible to *dual-license* to EPL, but I don't think the MIT license allows unilateral relicensing. (The reason I believe dual licensing is possible is that the MIT license allows you to sublicense, but does so subject to conditions, one of which is that the MIT copyright and permission notice is included - I.E: those rights are also transferred).

So they could be going dual-license, but it seems to me unlikely given the entire bureaucracy seems intended to cleanse IP. It's entirely possible that eclipse intends to contact each core and plugin contributor to ask them to relicense their code to EPL - they're a big organisation. I for one will be declining any such approach.

This, of course, doesn't preclude the rift being healed by a different mechanism. All developers are welcome at Jenkins, even ones who work for Oracle!

[Swindells, Thomas]

> -----Original Message-----
> From: jenkins...@googlegroups.com [mailto:jenkinsci-
> us...@googlegroups.com] On Behalf Of R. Tyler Croy
> Sent: 05 May 2011 00:36
> To: jenkins...@googlegroups.com
> Subject: Re: Looks like Oracle hudson is moving to Eclipse Foundation

> My question to you and perhaps all the other folks out there asking the
> question "will they merge?": what does the Jenkins community have to gain
> from Hudson *at all*?
>
>

> I personally see *zero* benefit from Hudson and Jenkins merging in the
> future.

I think you are overlooking the fact that Oracle and Sonatype are prepared to pay developers and QC staff to develop and improve the codebase. Ignoring the management these developers are working under I'm sure that they are very capable and talented developers who will be able to contribute useful fixes and improvements. In particular, being paid to do so, they are more likely to work on the 'dull' areas of software development like improving test coverage, stability and performance which can sometimes get neglected when people are contributing either for fun, or to fix particular issues affecting their real job.
Whether this benefit is outweighed by the managers these developers work under is another question.
Also to note is that the eclipse public license is basically an MIT clone (I believe) which I think means that Jenkins can just pull and include any fixes contributed to it anyway?

Thomas

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

[danny staple]

On the stability/test coverage, bear in mind that those who are interested in hudson/jenkins as a project are usually those who are test infected (or test obsessed) and actually find test coverage and stability not to be a boring area (just a much neglected/undervalued one).
Performance is perhaps another matter.

--
Danny Staple

Director, ODM Solutions Ltd
w: http://www.odmsolutions.co.uk
Blog: http://orionrobots.co.uk/blog1-Danny-Staple

[Nord, James]

If that where the case I would say there should be a lot fewer regressions and new bugs in each Jenkins release.

 

Currently if you take a build it can (certainly it has) been a bit hit and miss as to if it was a good release or not (and hence why there is now a stable branch, and the community feedback option in the change log).

Nothing against the committers – they’re doing great job and fix important defects/regressions pretty swiftly but I certainly perceive there is more a focus on new features rather than stability (which is fine as a lot of people are doing this on their own time).  (I may have missed lots of new Its being checked in so my perceptions may be completely wrong.  For for a long time a significant portion of the tests would not pass on anything other than Linux and Solaris).

 

/James

[Les Mikesell]

On 5/4/2011 6:36 PM, R. Tyler Croy wrote:
>
> My question to you and perhaps all the other folks out there asking the
> question "will they merge?": what does the Jenkins community have to gain from
> Hudson *at all*?

As someone still using the pre-fork version (and saw nothing really
wrong with that status), I'd appreciate not having a 50/50 chance of
picking the wrong path to upgrade (i.e. the one that won't have the
plugin I need in the future).

> I personally see *zero* benefit from Hudson and Jenkins merging in the future.

If I were a developer capable of matching anything one or the other of
the communities does all by myself, I might be less concerned about the
way they will diverge...

--
Les Mikesell
lesmi...@gmail.com

[Andrew Bayer]

For what it's worth, Tyler's not capable of matching *anything* either community does in terms of Java code. =)

A.

[David Weintraub]

I am not a developer and don't know how the politics of open source
software works. I do know a couple of things:

* As an end user, I now have to make a choice: Go with the Hudson name
or move to Jenkins. If I pick the wrong one, I now have to redo my
infrastructure later on. I implemented a Mambo CMS system right after
the split between Joomla and Mambo. My client was not very happy.

* Features and improvements will be split between the two. It means
that a plug in I need is a Hudson plugin while I have a particular
feature on Jenkins I need. It can also mean running two different
servers because one project may need something from Hudson while
another needs something from Jenkins.

* Energy in a project is now being put towards choosing sides and
fighting instead of coding. Rumors will be spread why each isn't a
very good project. And, these rumors will spread to my customers and
management who will want to know why I am suggesting a particular
system that has "all sorts of issues" rather than a nice standard,
well supported package like TeamCity or Bamboo.

In the end, this split really isn't doing anyone any good. It would be
nice before too much code is changed and the two projects cannot be
meshed together if serious efforts are made to heal this rift.

--
David Weintraub
qaz...@gmail.com

[Jesse Farinacci]

Greetings,

On Wed, May 11, 2011 at 4:59 PM, David Weintraub <qaz...@gmail.com> wrote:
>
> * As an end user, I now have to make a choice: Go with the Hudson name
> or move to Jenkins. If I pick the wrong one, I now have to redo my
> infrastructure later on. I implemented a Mambo CMS system right after
> the split between Joomla and Mambo. My client was not very happy.

How is this any different than having to choose between Jenkins,
Hudson, Continuum, Bamboo, CruiseControl, TeamCity, etc? This is not a
real issue.. at least, it's not an issue that has been created by the
split. I dare say it isn't one that has been all that greatly
exasperated by the split, either.

> * Features and improvements will be split between the two. It means
> that a plug in I need is a Hudson plugin while I have a particular
> feature on Jenkins I need. It can also mean running two different
> servers because one project may need something from Hudson while
> another needs something from Jenkins.

Each of the CI servers I mentioned above have different features. So
far, the only things that Hudson has provided that wasn't already part
of Jenkins is javax.inject abilities for plugins. I haven't seen one
developer request this feature on the -dev list.. I think the benefits
of this are suspect.

> * Energy in a project is now being put towards choosing sides and
> fighting instead of coding. Rumors will be spread why each isn't a

I don't see this at all, please direct me to all the fighting and
choosing sides. If you look at what is *actually* happening as far as
commits and releases here at Jenkins you'd see that the development
has been ramped up to epic levels.

> very good project. And, these rumors will spread to my customers and
> management who will want to know why I am suggesting a particular
> system that has "all sorts of issues" rather than a nice standard,
> well supported package like TeamCity or Bamboo.

Again, show me what you're talking about because I really don't see
this happening at all.

> In the end, this split really isn't doing anyone any good. It would be
> nice before too much code is changed and the two projects cannot be
> meshed together if serious efforts are made to heal this rift.

Life is about choice, you have to make decisions all the time. Man up
and choose and then move on. These conversations about reconciliation
seem to be more of a time waster than anything else, especially since
it's technically unlikely and politically extremely unlikely.

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

[Les Mikesell]

On 5/11/2011 4:31 PM, Jesse Farinacci wrote:
>
>> * As an end user, I now have to make a choice: Go with the Hudson name
>> or move to Jenkins. If I pick the wrong one, I now have to redo my
>> infrastructure later on. I implemented a Mambo CMS system right after
>> the split between Joomla and Mambo. My client was not very happy.
>
> How is this any different than having to choose between Jenkins,
> Hudson, Continuum, Bamboo, CruiseControl, TeamCity, etc?

Were any of those things besides Jenkins and Hudson a single community
that subsequently split? If not, that's the difference.

> This is not a
> real issue.. at least, it's not an issue that has been created by the
> split. I dare say it isn't one that has been all that greatly
> exasperated by the split, either.

How is it not an issue to have the developer and user base fragmented?

> Each of the CI servers I mentioned above have different features. So
> far, the only things that Hudson has provided that wasn't already part
> of Jenkins is javax.inject abilities for plugins. I haven't seen one
> developer request this feature on the -dev list.. I think the benefits
> of this are suspect.

And you think that's going to be the only change they'll ever make? I
don't, and consider it unfair to jump to such a conclusion in such a
short time span after losing the original developers.

> I don't see this at all, please direct me to all the fighting and
> choosing sides. If you look at what is *actually* happening as far as
> commits and releases here at Jenkins you'd see that the development
> has been ramped up to epic levels.

What kind of testing do you have before a release to ensure that all the
plugins continue to work on all platforms? Documentation development?

>> In the end, this split really isn't doing anyone any good. It would be
>> nice before too much code is changed and the two projects cannot be
>> meshed together if serious efforts are made to heal this rift.
>
> Life is about choice, you have to make decisions all the time. Man up
> and choose and then move on. These conversations about reconciliation
> seem to be more of a time waster than anything else, especially since
> it's technically unlikely and politically extremely unlikely.

We may have to do that, but don't ask me to like it or pretend that it
is for the best.

--
Les Mikesell
lesmi...@gmail.com

[Andrew Bayer]

On Wed, May 11, 2011 at 2:57 PM, Les Mikesell <lesmi...@gmail.com> wrote:

What kind of testing do you have before a release to ensure that all the plugins continue to work on all platforms?  Documentation development?

On that note, take a look at fcamblor's plugin-compat test stuff - it's still fairly new and not that mature yet, but it's a great step towards having some level of validation that plugins released for earlier versions will work on newer versions.

A. 

[Andrew Bayer]

It's also worth asking what the Hudson people are willing to do in order to reunite - this, obviously, can't be all one side or the other alone making moves.

A.

[Jesse Farinacci]

Greetings,

On Wed, May 11, 2011 at 5:57 PM, Les Mikesell <lesmi...@gmail.com> wrote:
>> How is this any different than having to choose between Jenkins,
>> Hudson, Continuum, Bamboo, CruiseControl, TeamCity, etc?
>
> Were any of those things besides Jenkins and Hudson a single community that
> subsequently split?  If not, that's the difference.

You can't have it both ways, sorry. Either they are similar enough
that a split should influence the decision in the manner you suggest
here, then you can't assert (as you do down below) that they will
diverge drastically in features and capabilities.

> How is it not an issue to have the developer and user base fragmented?

It isn't. I'll bet all the money in my pockets against all the money
in your pockets that 90%+ of the developer and user base is with
Jenkins. See the whole of the CI universe for further reference.

> And you think that's going to be the only change they'll ever make?  I
> don't, and consider it unfair to jump to such a conclusion in such a short
> time span after losing the original developers.

See above w/r/t having it both ways. I am not jumping to conclusions.
It's 3+ months out and so far I only see one real feature added to
Hudson. 3+ months, I'm not jumping to conclusions.

>> Life is about choice, you have to make decisions all the time. Man up
>> and choose and then move on. These conversations about reconciliation
>> seem to be more of a time waster than anything else, especially since
>> it's technically unlikely and politically extremely unlikely.
>
> We may have to do that, but don't ask me to like it or pretend that it is
> for the best.

I don't recall making that request. It is for the best to move
forward, IMO. I know I am breaking camp here, but I sincerely believe
that focusing on compatibility or reconciliation is wasted effort. Not
wasting time and energy is for the best, of everyone.

[Les Mikesell]

On 5/11/2011 5:19 PM, Jesse Farinacci wrote:
> Greetings,
>
> On Wed, May 11, 2011 at 5:57 PM, Les Mikesell<lesmi...@gmail.com> wrote:
>>> How is this any different than having to choose between Jenkins,
>>> Hudson, Continuum, Bamboo, CruiseControl, TeamCity, etc?
>>
>> Were any of those things besides Jenkins and Hudson a single community that
>> subsequently split? If not, that's the difference.
>
> You can't have it both ways, sorry. Either they are similar enough
> that a split should influence the decision in the manner you suggest
> here, then you can't assert (as you do down below) that they will
> diverge drastically in features and capabilities.

Right now I do have it both ways. I am running a pre-fork version.

>> How is it not an issue to have the developer and user base fragmented?
>
> It isn't. I'll bet all the money in my pockets against all the money
> in your pockets that 90%+ of the developer and user base is with
> Jenkins. See the whole of the CI universe for further reference.

Were you counting me in that user base? I'd bet that I'm not the only
one running an older release. And are developers enough? What about QA
resources? Release testers? Even if your 90% is right, what about
fixing the bugs that other 10% would catch and report? If the project
doesn't care about these things, it's probably the wrong direction for me.

> See above w/r/t having it both ways. I am not jumping to conclusions.
> It's 3+ months out and so far I only see one real feature added to
> Hudson. 3+ months, I'm not jumping to conclusions.

What percent of the lifespan of the project is that?

> I don't recall making that request. It is for the best to move
> forward, IMO. I know I am breaking camp here, but I sincerely believe
> that focusing on compatibility or reconciliation is wasted effort. Not
> wasting time and energy is for the best, of everyone.

Unless the combined resources more than make up for it over the life of
the project...

--
Les Mikesell
lesmi...@gmal.com

[Kohsuke Kawaguchi]

I think I understand how you feel, and I acknowledge the downside of
separation. OTOH, to steal a point someone made today in the project
meeting, I think it's also important for us to keep the developers of
the project happy and productive, because that's the main engine of an
OSS project.

Given where two projects are today, there's natural and legitimate
concerns about whether merging can produce a functional community. A lot
of things get done in open-source projects through human relationships,
and we have little of that between the two groups currently. I'd love to
be able to rebuild that, but as Andrew wrote in his blog, we need more
help for that to happen than just hearing "you should work together!" I
know I'm not doing a good job of getting the point across, but it really
is harder than it looks from outside.

In a way, maybe we are in the prisoners' dilemma like situation; it's
possible that both sides are reasonable and still end up in a
sub-optimal state.

On a positive side, I think the competition isn't necessarily a bad thing.

--
Kohsuke Kawaguchi http://kohsuke.org/

[jyo...@oreillyauto.com]

I for one have been viewing Oracle with a suspicious eye in everything they
do since the acquisition of Sun. I don't expect products like MySQL and
Java to remain open and free to thrive in the Open Source world if Oracle
can turn a profit for a quarter. The way I imagine it being is that as
long as Oracle feels confident that the projection of income will rise a
certain percentage above the cost of acquisition, they will go for it. No
matter what it does to the Open Source community, or the long term
potential that they will most assuredly lose.

The split between Hudson and Jenkins may have been fueled by similar
sentiments on many people's part. In fact, I had very little hesitance in
upgrading to Jenkins builds after the split was announced.
This doesn't mean that I'm not interested in stable release versions that
only suggest downloading bug fixes or security fixes over a period of time,
and virtually guarantee that the plugins will continue to work through
those fixes. I know that this means that bug fixes will potentially have
to be applied and ported and tested on multiple releases, but I'm also
willing to provide some assistance in that, by testing the bug fixes,
following up on jira reports etc.

*IF* the move of Hudson to the Eclipse Foundation (or some other open
source body), can reduce the likelihood that Oracle will run the project
like it does everything else, then I would say it's worth discussing a
merger of communities. Oracle, Sonatype, and other companies should not
have privileged seats at the governance table, and the current Jenkins
community should remain willing and able to return to the current status if
there are issues in that regard.

It's really about retaining the ability to commit new features as they are
contributed, and not having a profit minded overlord denying the creativity
and resourcefulness of the community at large.

We have to remember to be civil and open to the thoughts of people that are
still riding the fence. I'm sure there are plenty of users of Jenkins or
Hudson that don't join the mailing lists, and don't have a very good
understanding of what the split is even about at the core. Furthermore,
I'm sure that there are now a great number of people who see the
announcement of trying to move Hudson to the Eclipse Foundation as "the
Jenkins people getting what they wanted", and may think that we were
impatient by splitting. I don't see it this way, but I feel as though I
understand the dynamics somewhat well, whereas I doubt many corporate users
do.

Politics is sometimes a difficult game to play, and I know that we tech
heads have a hard time participating at times, but, as a community, I think
it is 100% beneficial to discuss all the requirements, write them down in
public, and say exactly what it would take for the Jenkins community to
trust Oracle, and to gain benefit from merging the two products. Hashing
out these details is not a waste of time, because it will help those that
don't participate directly in the community to have a clearer understanding
of why the split exists, and if it is unresolved, then the benefits of
Jenkins remaining alive, strong, and separate from Hudson.

Jeremy D. Young
Web Architect
O'Reilly Auto Parts

jenkins...@googlegroups.com wrote on 05/11/2011 07:16:55 PM:

> From: Kohsuke Kawaguchi <k...@kohsuke.org>
> To: jenkins...@googlegroups.com
> Cc: David Weintraub <qaz...@gmail.com>
> Date: 05/11/2011 07:17 PM
> Subject: Re: Looks like Oracle hudson is moving to Eclipse Foundation

> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

[Les Mikesell]

On 5/12/2011 1:08 PM, jyo...@oreillyauto.com wrote:
>
> It's really about retaining the ability to commit new features as they are
> contributed, and not having a profit minded overlord denying the creativity
> and resourcefulness of the community at large.

But I'd temper that with the realization that pushing changes that break
things into releases will drive users away, and that the creative
developers may have better things to do than a lot of cross platform QA
testing.

> Furthermore,
> I'm sure that there are now a great number of people who see the
> announcement of trying to move Hudson to the Eclipse Foundation as "the
> Jenkins people getting what they wanted", and may think that we were
> impatient by splitting. I don't see it this way, but I feel as though I
> understand the dynamics somewhat well, whereas I doubt many corporate users
> do.

It's not going to work unless everyone gets what they want. I'm not
close enough to the project to know any of the politics - or care about
them anyway and the name, ownership of the name, or cutesy icon is even
less important. But, it would be great if the fast-track
development/testing version(s) could co-exist with a more formal
'no-surprises' release process so you could use either or both in
appropriate situations.

--
Les Mikesell
lesmi...@gmail.com

[R. Tyler Croy]

A stable, long-term support release is being branched from 1.400 and worked on
right now, for what it's worth.

Not everybody in the dev community runs their own CI servers on the most
bleeding edge :)

[Les Mikesell]

On 5/12/2011 5:48 PM, R. Tyler Croy wrote:
>
>
> Not everybody in the dev community runs their own CI servers on the most
> bleeding edge :)

Right, but making the choice of which one doesn't have the showstopper
bugs has been left up to users that may not be well equipped to make
that choice.

--
Les Mikesell
lesmi...@gmail.com

[Tim Pizey]

On 12 May 2011 23:56, Les Mikesell <lesmi...@gmail.com> wrote:
> On 5/12/2011 5:48 PM, R. Tyler Croy wrote:
>>
>>
>> Not everybody in the dev community runs their own CI servers on the most
>> bleeding edge :)
>
> Right, but making the choice of which one doesn't have the showstopper bugs
> has been left up to users that may not be well equipped to make that choice.

I am pretty underwhelmed by the stability argument.

Those who value stability need to build redundant systems to give them
that stability ie run
staging and live, nothing else will give you stability.

--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.org

[Les Mikesell]

On 5/13/11 3:32 AM, Tim Pizey wrote:
>
>>> Not everybody in the dev community runs their own CI servers on the most
>>> bleeding edge :)
>>
>> Right, but making the choice of which one doesn't have the showstopper bugs
>> has been left up to users that may not be well equipped to make that choice.
>
> I am pretty underwhelmed by the stability argument.
>
> Those who value stability need to build redundant systems to give them
> that stability ie run
> staging and live, nothing else will give you stability.

Ummm, no. Software packages get stability by testing, and if a bug is found
before a release, it doesn't affect the users. Why force every end user to find
the same bugs? Yes, sometimes free software projects don't have the resources
to do a good job of testing, but they can't pretend it doesn't matter.

--
Les Mikesell
lesmi...@gmail.com

[Dan Haynes]

My thoughts:

In reading the discussion about "fragmented user community", I wonder how
many others are in the same boat as me and didn't even know about the split
between Hudson and Jenkins until months after it happened? I'd wager that
there are quite a few users out there just like me who installed Hudson,
have automatic updates in place and just had no idea there was a split.

As an Oracle user/customer and with some experience in how they do business,
I switched to Jenkins as soon as I found out (Oracle have *great* engineers
but if given the choice between Oracle management/corporate
policies/bloodsucking licensing practices and death, death is definitely the
better choice) However I only learned about the split about a month and a
half ago and then only by chance when I happened across a google groups post
while looking for configuration examples.

I'm an Eclipse user/fan but I'd rather not see the project hosted on
Eclipse. The problem is that projects hosted on Eclipse/associated with
Eclipse invariably become bound to it. I've still never found the time to
sort out how to replace Jetty 6 with Jetty 7 because when it moved to
Eclipse it seems to have become dependent on Maven and Eclipse and a pain in
the butt to figure out how to use it outside of Eclipse. In the real world
the projects I work on required headless/unattended builds on machines we
don't control. As a development group we use Jenkins to notify us of broken
builds/unit tests/integration tests. The actual QA builds are done in an
entirely different environment which (for good reasons) we have no control
over, so our builds must be simple ant scripts with hard coded dependencies.
A long winded way of saying I don't want Jenkins to become dependent on
Eclipse, mostly out of my own ignorance but also it's not a subject I'm
really interested in learning when there are deadlines to meet.

I think merging Hudson/Jenkins would be a good thing just from an efficiency
standpoint. It would combine the development efforts and increase the number
of eyes on the direction and quality of the code.

That said, I think the point must also be made that Kohsuke and the other
folks who lead the effort *must* be satisfied with the final decision. There
is not a single really good open source project out there that does not have
at least one or two dedicated/focused prime movers with strong ideas driving
it. If developing on the project isn't fun for them, the project loses out.
When I was in the submarine service our nuclear weapon security training
emphasized "consider hostages, but shoot through them". I think user
preferences should be considered, but shoot through them if that's what it
takes to keep Kohsuke and crew happy.

My $0.02 worth.

-----Original Message-----
From: jenkins...@googlegroups.com
[mailto:jenkins...@googlegroups.com] On Behalf Of Kohsuke Kawaguchi
Sent: Wednesday, May 11, 2011 6:17 PM
To: jenkins...@googlegroups.com
Cc: David Weintraub
Subject: Re: Looks like Oracle hudson is moving to Eclipse Foundation