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: > >> Hi! >> >> 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 >> >> Thoughts? >> >> Thanks, >> Roman. >> >> > 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. > > Thanks, > Bruno >
