Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (nike.apache.org: domain of muralihere@gmail.com designates
 74.125.83.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALyHw0F40zHdS183LkrvwiPKa5zBtQD-8R6257EkXRhTjKjJOQ@mail.gmail.com>
References: 
 <CAL4rnW0geTgmOj8pVnrbq9c6G16p2+cfK4XgMMtSRVGLaHexxA@mail.gmail.com>
	<CALyHw0F40zHdS183LkrvwiPKa5zBtQD-8R6257EkXRhTjKjJOQ@mail.gmail.com>
Date: Sun, 3 Mar 2013 07:49:17 +0000
Message-ID: 
 <CAL4rnW3AgaByXbCbf=BzhCnWNNWy_boVpGAN81LtkNgOqJV4ww@mail.gmail.com>
Subject: Re: Problems with Continuum making it useless (Dev only)
From: murali mohan <muralihere@gmail.com>
To: dev@continuum.apache.org
Content-Type: multipart/alternative; boundary=047d7b66f619445c5204d7007a96

--047d7b66f619445c5204d7007a96
Content-Type: text/plain; charset=ISO-8859-1

The shell builds are necessary alongside maven builds. One can never image
all possible situations for a continuous integration possible around the
world. In our case, shell builds are necessary just to support maven
builds.

As you rightly said, Continuum is mainly for maven builds and that is what
we are using it for too. But we also need some support and shells are very
basic and can provide all kinds of support needed and actually close off
many use cases, I think. So my vote is for Shell build support - nothing
advanced.

Anyways, I think I have found the root cause for that issue, which is a
"syncrhonize" method, which is not present for other builds like maven. I
do not see a reason for synchronize to be present in that method as
explained in the JIRA issue.

I can provide a patch.

Please have a look and let me know.

Thanks,
Murali


On Sun, Mar 3, 2013 at 12:45 AM, Brent Atkinson <brent.atkinson@gmail.com>wrote:

> Thanks murali, I'll see if I can dig up what root issue might be and update
> the issue.
>
> IMO Continuum's shell and ant support seems a little bizarre because the
> concepts in the application, projects and project groups, were taken
> directly taken from Maven's concept of groupId (group) and
> groupId+artifactId (project). The concepts aren't clear to someone not
> versed in Maven and the implementation seems directed to the Maven concepts
> anyway. I also noticed that the ant support was a bit broken a while back
> depending on how you added projects. It seemed so broken that I couldn't
> imagine anyone using them.
>
> I am wondering, would it be better to prune and cultivate what people are
> using than to drag along vestigial limbs?
>
> As for interest, thanks Louis for speaking up. I believe that there is
> still room for a product that directly addresses CI for Maven projects. I
> use both Continuum and Jenkins, and I still like the simplicity of being
> able to add projects via poms, manage things through the pom, etc. Not all
> projects can operate within the conventions, so the audience may be smaller
> than other CI tools from the start, but I think not trying to solve
> everything might actually sanitize (both clean and sane) things.
> Personally, I think it would be great to do in things like push-button
> branching using release:branch (with version conventions like maintenance
> branches, release branches, etc.) and have the branched build added for
> you.
>
> To your earlier point murali, if the tool seems like it is offering a
> solution and doesn't work properly, it doesn't inspire confidence. I can
> say from direct experience that Continuum actually does work well for
> conventional Maven builds and if the others aren't a focus and are broken,
> why keep fooling ourselves and users?
>
> Brent
>
>
>
>
> On Mar 1, 2013 9:54 AM, "murali mohan" <muralihere@gmail.com> wrote:
>
> > Created a new JIRA issue at
> http://jira.codehaus.org/browse/CONTINUUM-2704
> >
> > I have done a little analysis and posted as comment. Please guide me on
> how
> > to proceed and I will try when I get time.
> >
> > Thanks.
> >
> >
> > On Fri, Mar 1, 2013 at 11:51 AM, Louis Smith <dr.louis.smith@gmail.com
> > >wrote:
> >
> > > I have continuum installed at several clients - one of whom runs over
> 100
> > > java projects and 20 Oracle Forms projects with it.  We have upgraded
> to
> > > the 1.4.x release and have had nothing but success with it - so count
> me
> > > and my clients as "interested".
> > >
> > > Louis
> > >
> > >
> > > On Fri, Mar 1, 2013 at 5:52 AM, murali mohan <muralihere@gmail.com>
> > wrote:
> > >
> > > > As an immediate solution, I will have to look at other options, I
> > guess.
> > > >
> > > > To solve these, I will try to help. But are people interested in this
> > > > project?
> > > >
> > > >
>
>
>
> > -Murali
> > > >
> > > > On Thu, Feb 28, 2013 at 5:53 PM, Brent Atkinson <
> batkinson@apache.org
> > > > >wrote:
> > > >
> > > > > Hi Murali,
> > > > >
> > > > > I'm sorry that you're frustrated.
> > > > >
> > > > > I doubt I can address everything you're raising as I'm still a
> > relative
> > > > > newbie in the code base, but I do know that there are a number of
> > cases
> > > > > Continuum doesn't handle, at least without workarounds, in its
> > current
> > > > > state. One of them is dependencies between builds and I wonder if
> > this
> > > > > limitation is responsible for why the parallel builds work this
> way.
> > > > >
> > > > > To be perfectly honest, if you are looking for an immediate
> solution,
> > > > > Continuum may not be the best choice for you. However, if you're
> > > > interested
> > > > > in helping to address the issues, I will do what I can to help.
> > > > >
> > > > > Brent
> > > > >
> > > > > On Thu, Feb 28, 2013 at 4:21 AM, murali mohan <
> muralihere@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Warning. This is a rant.
> > > > > >
> > > > > > -> Parallel builds in Continuum is an embarrassment. Reasons:
> > > > > >
> > > > > >    1. Different builds from the same project cannot be queued if
> > one
> > > of
> > > > > >    them is already running. Why is this? It is not even the same
> > > build,
> > > > > it
> > > > > > is
> > > > > >    a separate buildsbut belonging to the same project. This is a
> > > block
> > > > > > since
> > > > > >    we are forced to time the scheduling perfectly so that the
> > second
> > > > > build
> > > > > >    starts only after first build is done. Why?! Or we need to
> have
> > > > > separate
> > > > > >    project groups. Then why do we need projects?!
> > > > > >    2. Shell builds are not running in parallel in version 1.3.6
> > > (Don't
> > > > > know
> > > > > >    about other versions). Even after enabling parallel builds and
> > > > queues
> > > > > > and
> > > > > >    when maven builds run in parallel without any problem.
> > > > > >
> > > > > > It has become a very clever and unknown science now to run all
> the
> > > > builds
> > > > > > in parallel in continuum and to ensure that everything completes.
> > > > > >
> > > > > > -> There are thousand of builds and their history in our
> continuum
> > > > > setup. I
> > > > > > have set up purge configurations, but still the UI lists
> thousands
> > > and
> > > > > > takes a long time to load.
> > > > > >
> > > > > > -> For both the above, I have sent emails to support. One is
> > recent,
> > > so
> > > > > > lets leave that, The deletion of builds - no help to complete it.
> > > Some
> > > > > > vague suggestions which never worked when I tried. There is some
> > XML
> > > > RPC
> > > > > > tool to delete these old builds. I did spend a couple of days to
> > run
> > > > it,
> > > > > it
> > > > > > doesn't!
> > > > > >
> > > > > > -> Yes, this is open source and we all should contribute. But I
> am
> > > > > someone
> > > > > > who has submitted patches before and willing to spend some time.
> > But
> > > > > there
> > > > > > seems to be no people who are running this or being responsible.
> > > > > >
> > > > > > -> All in all, I have spent a lot of time on this software from
> the
> > > > time
> > > > > > when it had very minimal features. Sadly, I think it is a waste
> of
> > > time
> > > > > now
> > > > > > adjusting schedules and making it "somehow" run.
> > > > > >
> > > > > > -Murali.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dr. Louis Smith, ThD
> > > Chief Technology Officer, Kyra InfoTech
> > > Engineer-in-Training, Veterans Memorial Railroad
> > >
> >
>

--047d7b66f619445c5204d7007a96--