Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <21460781.189131275685014252.JavaMail.jira@thor>
Date: Fri, 4 Jun 2010 16:56:54 -0400 (EDT)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-1159) For contrib modules that use
 Java, have a consistent build mechanism
In-Reply-To: <1795880.173731275619912647.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875749#action_12875749 ] 

Jonathan Ellis commented on CASSANDRA-1159:
-------------------------------------------

Yeah, I guess we were/are on different pages there.  I personally don't see the point of having it in-tree, if we're not going to take some responsibility for at least minimal upkeeping, especially since it makes it _more_ difficult for non-committers to patch it.

But I still think it's worth distinguishing between "core" code and contrib, even if the line is somewhat subjective...  If we wanted to make it non-subjective I would be okay with drawing a line that says "example code can go in contrib/, everything else should be in core or spun off elsewhere as its own project."

> For contrib modules that use Java, have a consistent build mechanism
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-1159
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1159
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Contrib
>            Reporter: Jeremy Hanna
>            Assignee: Jeremy Hanna
>            Priority: Minor
>             Fix For: 0.7
>
>
> Contrib modules have a habit of periodically not working for some reason.  To some extent that's expected - they are optional contrib modules.  However, I think it's reasonable to at least have some way to perform a periodic sanity check on them if we can.
> This improvement would make sure there is a consistent build mechanism - build.xml - for each of the contrib modules that use Java.  That way, there could be a hudson build perhaps nightly or weekly, that could inform the devs if the contrib modules are not even compiling.  It's not like it would be a huge priority to fix immediately, but they would at least be aware that changes in the code/config have broken a contrib module.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.