While I don't have a strong opposition to the 2 options, aren't there 2
more options here:
3. We detect GROOVY_HOME and let our users download and install groovy
themselves? We do this for Java (albeit, for licensing reasons), however,
pulling in our own groovy just for init-hdfs.sh seems like an overkill.
4. Wrap the groovy script into a jar and run that jar on java instead.
Since init-hdfs.sh is the first groovy script in Bigtop packages, I am
inclined towards #4. If we do end up writing more and more groovy scripts,
then we start bundling in our own groovy.
On Wed, Sep 25, 2013 at 12:54 AM, Bruno Mahé <[EMAIL PROTECTED]> wrote:
> On 09/24/2013 03:54 PM, Roman Shaposhnik wrote:
>> for the work on BIGTOP-952 I've got
>> a Groovy script that does the job.
>> Question is -- what to do about Groovy
>> itself. I see two choices:
>> 1. make Groovy jars available as part
>> of bigtop-utils
>> 2. introduce a full fledged bigtop-groovy
> I vote for 2.
> So if any other package needs groovy, we will have that handy.
> Also it would make it easier to just upgrade groovy without updating any
> other part of bigtop-utils.