I would vote for #4 or #3, but I don't feel strongly enough to oppose other options if someone's willing to do the work.
On Wed, Sep 25, 2013 at 7:37 AM, Mark Grover <[email protected]> wrote: > 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 > > >
