Return-Path: X-Original-To: apmail-continuum-dev-archive@www.apache.org Delivered-To: apmail-continuum-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AFDA0EAA1 for ; Sun, 3 Mar 2013 17:59:29 +0000 (UTC) Received: (qmail 55683 invoked by uid 500); 3 Mar 2013 17:59:29 -0000 Delivered-To: apmail-continuum-dev-archive@continuum.apache.org Received: (qmail 55625 invoked by uid 500); 3 Mar 2013 17:59:29 -0000 Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@continuum.apache.org Delivered-To: mailing list dev@continuum.apache.org Received: (qmail 55617 invoked by uid 99); 3 Mar 2013 17:59:29 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Mar 2013 17:59:29 +0000 Received: from localhost (HELO mail-ob0-f178.google.com) (127.0.0.1) (smtp-auth username batkinson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Mar 2013 17:59:29 +0000 Received: by mail-ob0-f178.google.com with SMTP id wd20so1495144obb.9 for ; Sun, 03 Mar 2013 09:59:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.171.230 with SMTP id ax6mr13500976oec.25.1362333568190; Sun, 03 Mar 2013 09:59:28 -0800 (PST) Received: by 10.60.11.202 with HTTP; Sun, 3 Mar 2013 09:59:28 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Mar 2013 12:59:28 -0500 Message-ID: Subject: Re: Problems with Continuum making it useless (Dev only) From: Brent Atkinson To: dev@continuum.apache.org Content-Type: multipart/alternative; boundary=bcaec550b2e465d18d04d7090054 --bcaec550b2e465d18d04d7090054 Content-Type: text/plain; charset=ISO-8859-1 Murali, I'm not saying that shell builds aren't useful, of course they are. It's more that Continuum's focus hasn't been on these cases and it shows. I'm asking more about refocusing the project. We could continue to chase the general-purpose CI tool goal, but other CI tools already do this and do it better. As you said before, providing a solution for everyone's case is difficult. Alternatively, you can focus on doing less and doing it well. Being realistic about Continuum's state and its place among the greater CI tooling landscape and setting direction based on what it does well provides an opportunity to re-validate its reason for existence. Communicating out more accurately what Continuum is attempting to address also makes it more likely for a functional community to exist around it, and less frustration all-around. Without refocusing, I'm doubtful but could be convinced that Continuum has a place. Brent On Sun, Mar 3, 2013 at 8:03 AM, Louis Smith wrote: > Actually, we never use the shell builds - even for shell builds. all our > shell work is done via ant-run under a pom...IIRC, we did run into issues > with the "native" shell support - and defining everything (yeah, had to > write a standard to implement using it that way..) in a > Groupid/ProjectId/Version based system allowed us to implement the POM for > the project. The Oracle Forms we do are just shell commands; even our > daily run of Apache Forrest runs a large shell script with jar files, > SVNKit analysis - and "wraps" all the site reports under a nice umbrella. > I might upgrade from Forrest to Lenya one of these days... just for fun. > > > On Sun, Mar 3, 2013 at 2:49 AM, murali mohan wrote: > > > 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" 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 > > > > > 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 > > > > > > > > > > > > > > > > > > -- > Dr. Louis Smith, ThD > Chief Technology Officer, Kyra InfoTech > Engineer-in-Training, Veterans Memorial Railroad > --bcaec550b2e465d18d04d7090054--