I'm confused. Isn't Azul a commercial JRE? What's that have to do with Groovy in Docker? Did you reply to wrong thread?

As a side note, @jbaruch gave a talk at Codemash a shirt while ago that reminded me I should pin the versions of dependencies I'm installing with apk on the alpine versions. I'll do that after the conference.

-Keegan

On Jan 11, 2017 10:12 PM, "Gerald Wiltse" <jerrywiltse@gmail.com> wrote:
If you have questions about Azul that you can't seem to figure out online, the Azul Product Director is the organizer of my local JUG and I have a dialog with him.  I'd be happy to get him involved if you think it will help.  Just let me know.

Regards,
Jerry

Gerald R. Wiltse
jerrywiltse@gmail.com


On Tue, Dec 13, 2016 at 8:16 AM, Thibault Kruse <tibokruse@googlemail.com> wrote:
By comments I mean what is in the readme. Dockerfiles get copy pasted without attached readme, so they should be self commenting.

A minimalist server example may be nice. Can be in the same repo as a means of documentation, I think. 

For grapes I was worried about download location not writable.



On Dec 11, 2016 19:12, "Keegan Witt" <keeganwitt@gmail.com> wrote:
Thanks for the feedback, Thibault.  I've responded in-line.
  • Might be better not to start groovysh, might be mentioned in Dockerfile comments instead
    • It's just a default to be run when the user does "docker run", they can specify an alternative command to run if they choose (see my grape example further down).  Ruby, JRuby, and Python all do this, and it's mentioned in Docker's best practices.
  • Add Dockerfile comments, at least a link to the repo containing the dockerfiles
    • Did you mean a link to the Docker Hub page?  If not, what comments do you think would be helpful in the Dockerfiles?
  • Add a LICENSE file to the github repo
    • Good catch.  Done.
  • Add a travis job to the github repo that verifies the Dockerfiles
    • Yea, I intend to change the readme to link to the Docker Hub page (once published) and a Travis job, as you've suggested.  Build automation is something I have to work out yet, goes with the templating work I mentioned.
  • Provide one sample image on top of those images with some hello world application
    • Usage is pretty straightforward, but I could do that.  It probably should be in a separate repo though, don't you think?  Also any suggestions on a good sample?  I was thinking something not compiled Groovy, because for that you'd just run with Java Docker image, no need for Groovy on path.  Maybe a script of some kind.
  • Check if grapes can be run from containers
    • Grape seemed to work, was there a particular problem you were concerned about?
$ docker run -it --rm --name groovy groovy:jre8-latest
Dec 11, 2016 9:37:40 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Groovy Shell (2.4.7, JVM: 1.8.0_111)
Type ':help' or ':h' for help.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
groovy:000> groovy.grape.Grape.grab(group:'org.springframework', module:'spring', version:'2.5.6')
===> null

$ docker run -it --rm --name groovy groovy:jre8-latest grape install 'org.springframework' 'spring' '2.5.6'
:: loading settings :: url = jar:file:/opt/groovy/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: caller#all-caller;working72
        confs: [default]
        found org.springframework#spring;2.5.6 in jcenter
        found commons-logging#commons-logging;1.1.1 in jcenter
        [SUCCESSFUL ] org.springframework#spring;2.5.6!spring.jar (2741ms)
        [SUCCESSFUL ] commons-logging#commons-logging;1.1.1!commons-logging.jar (719ms)

On Sun, Dec 11, 2016 at 3:32 AM, Thibault Kruse <tibokruse@googlemail.com> wrote:
Some minor comments:
- might be better not to start groovysh, might be mentioned in
Dockerfile comments instead
- Add Dockerfile comments, at least a link to the repo containing the
dockerfiles
- Add a LICENSE file to the github repo
- Add a travis job to the github repo that verifies the Dockerfiles
- check if grapes can be run from containers
- Provide one sample image on top of those images with some hello
world application


On Sun, Dec 11, 2016 at 3:24 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
> Sorry for the long turnaround on this.  I've got some basic Dockerfiles put
> together: https://github.com/keeganwitt/groovy-docker.  Please let me know
> what I can improve.  One thing I might do is template out the Dockerfiles
> similar to what Ruby did to make it easier to publish images when there's a
> new Groovy version.
>
> I planned on creating both Alpine and non-Alpine images since that seems to
> be the current practice.  But we need to get GROOVY-7906 resolved for the
> Alpine images to work.
>
> I'm concerned about whether it'd be legal for us to distribute the Oracle
> JDK with Groovy.  I saw this article on the topic:
> http://blog.takipi.com/running-java-on-docker-youre-breaking-the-law/.  I
> don't speak legalize though.  I haven't seen anyone else (Jruby, etc)
> publishing Oracle JDK, and Oracle has never published Docker images that
> were not OpenJDK.  The only images floating out there have been
> community-created.  So for the time being, I don't plan to publish Oracle
> based images.
>
> Once we think these look good, I'll move the repo over to groovy org in
> Github and we'll get them published to Docker Hub.  Maybe we could also ask
> Apache Infra to get them added to https://hub.docker.com/u/apache/, I
> haven't decided.  What do you think?
>
> On Fri, Sep 9, 2016 at 11:19 PM, Corum, Michael <mcorum@rgare.com> wrote:
>>
>> Not related to Groovy as much.  We’ve never been able to get OpenJDK (7 or
>> 8) to work properly with Oracle JDBC drivers on Alpine.  Always have to use
>> Oracle JDK and in the research we did, we found others with the same issues.
>>
>> Michael Corum
>>
>> VP, Technical Architecture Solutions
>>
>>
>>
>> RGA Reinsurance Company
>>
>> 16600 Swingley Ridge Road
>>
>> Chesterfield, Missouri 6301701706
>>
>> T 636.736.7066
>>
>> www.rgare.com
>>
>>
>>
>>
>> From: Guillaume Laforge <glaforge@gmail.com>
>> Reply-To: "users@groovy.apache.org" <users@groovy.apache.org>
>> Date: Friday, September 9, 2016 at 10:16 PM
>> To: "users@groovy.apache.org" <users@groovy.apache.org>
>> Subject: Re: Groovy Docker images
>>
>> Out of curiosity, what's the problem with OpenJDK?
>> Is it related to Groovy or not at all?
>>
>> On Sat, Sep 10, 2016 at 5:09 AM, Corum, Michael <mcorum@rgare.com> wrote:
>>>
>>>
>>> Either one
>>> Alpine – I suspect others will want other options though
>>> Would most definitely prefer Oracle but I assume other would want OpenJDK
>>> as well.  For my purposes OpenJDK just doesn’t work at all.
>>>
>>> Michael Corum
>>>
>>> VP, Technical Architecture Solutions
>>>
>>>
>>>
>>> RGA Reinsurance Company
>>>
>>> 16600 Swingley Ridge Road
>>>
>>> Chesterfield, Missouri 6301701706
>>>
>>> T 636.736.7066
>>>
>>> www.rgare.com
>>>
>>>
>>>
>>>
>>> From: Keegan Witt <keeganwitt@gmail.com>
>>> Reply-To: "users@groovy.apache.org" <users@groovy.apache.org>
>>> Date: Friday, September 9, 2016 at 9:48 PM
>>> To: "users@groovy.apache.org" <users@groovy.apache.org>
>>> Subject: Groovy Docker images
>>>
>>> I was thinking of putting together some Docker images for Groovy, with
>>> the idea they might be useful to base Grails, Gradle, etc images on and
>>> wondered people's opinions on a few things.
>>>
>>> Should I install Groovy manually in somewhere like /opt?  Or use SDKMAN?
>>> Should I have images based on Alpine and Debian? Alpine only?
>>> I presume OpenJDK images are fine as bases?  Any reason we'd need an
>>> Oracle based image too?
>>>
>>> Thoughts?
>>>
>>> -Keegan
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
>
>