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