Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (athena.apache.org: domain of brent.atkinson@gmail.com
 designates 209.85.219.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAL4rnW0geTgmOj8pVnrbq9c6G16p2+cfK4XgMMtSRVGLaHexxA@mail.gmail.com>
References: 
 <CAL4rnW0geTgmOj8pVnrbq9c6G16p2+cfK4XgMMtSRVGLaHexxA@mail.gmail.com>
Date: Sat, 2 Mar 2013 16:45:54 -0800
Message-ID: 
 <CALyHw0F40zHdS183LkrvwiPKa5zBtQD-8R6257EkXRhTjKjJOQ@mail.gmail.com>
Subject: Re: Problems with Continuum making it useless (Dev only)
From: Brent Atkinson <brent.atkinson@gmail.com>
To: dev@continuum.apache.org
Content-Type: multipart/alternative; boundary=e89a8f6436fc128f4a04d6fa90b8

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

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

--e89a8f6436fc128f4a04d6fa90b8--