Re: [EXT][DISCUSS] Including Groovy as a scripting language
On 09/28/2011 01:29 AM, Alexandro Colorado wrote: On Mon, Sep 26, 2011 at 8:45 PM, Carl Marcum wrote: Hi all, I wanted to gauge the interest in including Groovy [1] as a scripting language. For those not familiar, Groovy is a dynamic language for the JVM that includes features like closures, builders, and dynamic typing. There is currently a Groovy For OpenOffice extension [2] for this available under LGPL. I have contacted the author regarding additionally licensing the extension as Apache and he would be willing to do that to include it. Groovy itself is under the Apache 2.0 so I thought it may be a good fit. My biggest reservation toward this is if groovy makes OOo even more heavy. Meaning that if it get bundled in, it will create a similar effect to Python runtime within OpenOffice.org. I haven't look into it yet, but I think the big part is the JVM that is already included anyway. The groovy jar is about 2MB and the complete extension oxt is about 8 Mb I believe. So there are some spring cleaning that needs to happen to python, meaning removing all modules and files that are not needed by OOo and maybe even adding some files that will ease the development of Python in the scripting framework ie. TCL and others. On a similar venue, I will recommend that adding Groovy would also need bootstrap to minimize the overall size impact of the bundle. At the same time many projects to improve the development of extensions have been idle including a Java-GUI development environment and UNO-base IDE for Python and other scripting languages (like Beanshell, and others. Hopefully not idle for much longer :) Of course the smartest and quickest thing to do is to make the Basic IDE/GUI designer compliant with the rest of the languages (Java, Python, Beanshell, ... Groovy). I am willing to work on this if there is interest. Best regards, Carl [1] http://groovy.codehaus.org/ [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice Best regards, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Great. Thanks for the clarification. Carl On 09/28/2011 03:43 AM, Andor E wrote: I'm working on a local copy. So far I haven't changed much code in the extension. The extender is a separate project, because it could be be used without the extension. Given time I'm planning to add a better code editor. But first I have to overcome some idiotic problems in Eclipse. Greetings eymux On Wed, Sep 28, 2011 at 2:45 AM, Carl Marcum wrote: Hi, On 09/27/2011 03:02 AM, Andor E wrote: Hi, I'm currently working on updating the Groovy for OpenOffice.org extension. I already have included the latest Groovy library. Currently I'm writing an extender, that allows to access functions and properties without imports and casts. I still have to overcome a few stumbling blocks, but I hope to have something up for release soon. Greetings eymux Are you working on the original extension or a fork of the project? Best regards, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
I'm working on a local copy. So far I haven't changed much code in the extension. The extender is a separate project, because it could be be used without the extension. Given time I'm planning to add a better code editor. But first I have to overcome some idiotic problems in Eclipse. Greetings eymux On Wed, Sep 28, 2011 at 2:45 AM, Carl Marcum wrote: > Hi, > > On 09/27/2011 03:02 AM, Andor E wrote: >> >> Hi, >> I'm currently working on updating the Groovy for OpenOffice.org >> extension. I already have included the latest Groovy library. >> Currently I'm writing an extender, that allows to access functions and >> properties without imports and casts. I still have to overcome a few >> stumbling blocks, but I hope to have something up for release soon. >> >> Greetings >> >> eymux >> > > Are you working on the original extension or a fork of the project? > > Best regards, > Carl >
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Wed, Sep 28, 2011 at 12:29 AM, Alexandro Colorado wrote: > > > On Mon, Sep 26, 2011 at 8:45 PM, Carl Marcum wrote: > >> Hi all, >> >> I wanted to gauge the interest in including Groovy [1] as a scripting >> language. >> >> For those not familiar, Groovy is a dynamic language for the JVM that >> includes features like closures, builders, and dynamic typing. > > >> There is currently a Groovy For OpenOffice extension [2] for this >> available under LGPL. I have contacted the author regarding additionally >> licensing the extension as Apache and he would be willing to do that to >> include it. > > >> Groovy itself is under the Apache 2.0 so I thought it may be a good fit. >> > > > My biggest reservation toward this is if groovy makes OOo even more heavy. > Meaning that if it get bundled in, it will create a similar effect to Python > runtime within OpenOffice.org. > > So there are some spring cleaning that needs to happen to python, meaning > removing all modules and files that are not needed by OOo and maybe even > adding some files that will ease the development of Python in the scripting > framework ie. TCL and others. > > On a similar venue, I will recommend that adding Groovy would also need > bootstrap to minimize the overall size impact of the bundle. > > At the same time many projects to improve the development of extensions > have been idle including a Java-GUI development environment and UNO-base IDE > for Python and other scripting languages (like Beanshell, and others. > I think this was never achieved, it was targeted for Google Summer of Code of 08: http://wiki.services.openoffice.org/wiki/Summer_of_Code_2008/proposals#GUI_builder_for_OOo > > Of course the smartest and quickest thing to do is to make the Basic > IDE/GUI designer compliant with the rest of the languages (Java, Python, > Beanshell, ... Groovy). > > >> >> I am willing to work on this if there is interest. >> >> Best regards, >> Carl >> >> [1] http://groovy.codehaus.org/ >> [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice >> > > > > -- > *Alexandro Colorado* > *OpenOffice.org* Español > http://es.openoffice.org > fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6 > > -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Mon, Sep 26, 2011 at 8:45 PM, Carl Marcum wrote: > Hi all, > > I wanted to gauge the interest in including Groovy [1] as a scripting > language. > > For those not familiar, Groovy is a dynamic language for the JVM that > includes features like closures, builders, and dynamic typing. > There is currently a Groovy For OpenOffice extension [2] for this > available under LGPL. I have contacted the author regarding additionally > licensing the extension as Apache and he would be willing to do that to > include it. > Groovy itself is under the Apache 2.0 so I thought it may be a good fit. > My biggest reservation toward this is if groovy makes OOo even more heavy. Meaning that if it get bundled in, it will create a similar effect to Python runtime within OpenOffice.org. So there are some spring cleaning that needs to happen to python, meaning removing all modules and files that are not needed by OOo and maybe even adding some files that will ease the development of Python in the scripting framework ie. TCL and others. On a similar venue, I will recommend that adding Groovy would also need bootstrap to minimize the overall size impact of the bundle. At the same time many projects to improve the development of extensions have been idle including a Java-GUI development environment and UNO-base IDE for Python and other scripting languages (like Beanshell, and others. Of course the smartest and quickest thing to do is to make the Basic IDE/GUI designer compliant with the rest of the languages (Java, Python, Beanshell, ... Groovy). > > I am willing to work on this if there is interest. > > Best regards, > Carl > > [1] http://groovy.codehaus.org/ > [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice > -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On 09/27/2011 06:07 AM, Jürgen Schmidt wrote: Hi, i have to confess that i have completely missed this extension until today. It shows again the power that we have to support scripting languages that are based on the JVM. I like it. I think a good selection of scripting options for the power users will be invaluable for gaining users. From a programmability perspective we should think about a better integration of scripting support in general. Besides Basic that is widely used and well known from MS office it would be nice if there would be volunteers interested to work on a better scripting solution than Basic. That would include of course a good and powerful IDE and tooling to make scripting as easy as possible and to benefit from the language features. Additional things like code completion, predefined code snippets for specific task that are easy to use in own scripts come to my mind. I think there is a lot of space for very interesting stuff in this direction and where the office can really benefit from. I agree. Groovy has good integration in Eclipse and Netbeans, but I don't yet know, what is required for AOOo IDE. I am willing to help with this where I can. Best regards, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Hi, On 09/27/2011 03:02 AM, Andor E wrote: Hi, I'm currently working on updating the Groovy for OpenOffice.org extension. I already have included the latest Groovy library. Currently I'm writing an extender, that allows to access functions and properties without imports and casts. I still have to overcome a few stumbling blocks, but I hope to have something up for release soon. Greetings eymux Are you working on the original extension or a fork of the project? Best regards, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
--- On Tue, 9/27/11, Rob Weir wrote: ... > > Bringing it into SVN is easy. Making it into a > release is another > question. To do that requires going through the IP > Clearance process. > Yes, I was obviously referring to the legal requirements. > > I'm willing to debate it for long-established, well-known, > high-profile OSS projects that are being used everywhere, > e..g, ICU. > This is partially about risk management. That is why > we should take > this case by case. But I don't think the Groovy > extension falls into that category. > OK: Ultimately this is a matter of policy and I find it an acceptable policy to ask for an SGA to very specific code like the groovy extension. I don't think carrying the extension involves carrying groovy itself, so we don't have to through all the dependency chain asking for SGA's. OTOH, asking for code assignment for minor stuff that is already completely in the Public Domain or under a BSD license, like ucpp, would be a complete nonsense. As you say .. case by case. Dmake does require IP clearance so good luck contacting WTIcorp :). Pedro.
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Tue, Sep 27, 2011 at 6:30 PM, Pedro F. Giffuni wrote: > > > --- On Tue, 9/27/11, Rob Weir wrote: > ... >> > Another point that Rob brought would be if we need a >> SGA >> > to add the Groovy (or other) extension. >> > >> > I would think an SGA is a rather extreme thing to >> require >> > for extensions: we wouldn't require that if we want >> to >> > include stuff like ucpp, bsh, or icu ... or dmake ;). >> > >> >> Again, this is a binary versus source code question. > > Not really, that was clarified already. The issue now is > how to bring code into the the SVN tree. > Bringing it into SVN is easy. Making it into a release is another question. To do that requires going through the IP Clearance process. >> I thought the discussion was about bringing the groovy >> extension source code over, yes? > > Yes. > >> That would require taking it through the IP >> Clearance process. >> An SGA is the normal way to do this. >> > > The PMC can require signing an SGA, I don't discuss that. > As a Podling, the Incubation PMC needs to sign off on IP Clearance and releases as well. > There are other ways of doing it though: people that > have signed ICLAs can bring in code under an appropriate > license and register it in the NOTICE file, and that's > about to happen as we replace copyleft components with > less restricted software. > The iCLA is of zero value if you are checking in someone else's code. The iCLA is about code that you write. For third party code, you don't personally know the provenance of the code. And if it was not developed on the Apache servers, in our SVN, in our public, archived mailings lists, etc., then neither do we. This isn't to say the code is not good. It just means that we do not have the record of its development. That is why we need the SGA. I'm going through this right now, in another Apache project, the ODF Toolkit. Even though the code was written almost entirely by IBM and Oracle, and the committers all have iCLAs and CCLAs, and the code has been Apache 2.0 licensed from the start, IBM and Oracle are still submitting SGA's for this code. I'm willing to debate it for long-established, well-known, high-profile OSS projects that are being used everywhere, e..g, ICU. This is partially about risk management. That is why we should take this case by case. But I don't think the Groovy extension falls into that category. > You can't really expect opensource coders to go signing > SGAs for all the projects that want to use their code. > The IP cleanliness of the code is very important for Apache projects. That is why we take steps that other projects may not require, including requiring an iCLA for committers, a CCLA for corporate contributors, and an SGA for existing open source projects that are contributed to Apache. I don't expect that all outside open source developers will agree to this paperwork. But I do hope that this project will take these requirements seriously. We should not think of an SGA as being extreme or unreasonable. We should think of it as an opportunity to assure that the IP of the project is reassured. -Rob > cheers, > > Pedro. >
Re: [EXT][DISCUSS] Including Groovy as a scripting language
--- On Tue, 9/27/11, Rob Weir wrote: ... > > Another point that Rob brought would be if we need a > SGA > > to add the Groovy (or other) extension. > > > > I would think an SGA is a rather extreme thing to > require > > for extensions: we wouldn't require that if we want > to > > include stuff like ucpp, bsh, or icu ... or dmake ;). > > > > Again, this is a binary versus source code question. Not really, that was clarified already. The issue now is how to bring code into the the SVN tree. > I thought the discussion was about bringing the groovy > extension source code over, yes? Yes. > That would require taking it through the IP > Clearance process. > An SGA is the normal way to do this. > The PMC can require signing an SGA, I don't discuss that. There are other ways of doing it though: people that have signed ICLAs can bring in code under an appropriate license and register it in the NOTICE file, and that's about to happen as we replace copyleft components with less restricted software. You can't really expect opensource coders to go signing SGAs for all the projects that want to use their code. cheers, Pedro.
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Tue, Sep 27, 2011 at 4:39 PM, Pedro Giffuni wrote: > Thanks, > > I needed that clarified. > > Another point that Rob brought would be if we need a SGA > to add the Groovy (or other) extension. > > I would think an SGA is a rather extreme thing to require > for extensions: we wouldn't require that if we want to > include stuff like ucpp, bsh, or icu ... or dmake ;). > Again, this is a binary versus source code question. I thought the discussion was about bringing the groovy extension source code over, yes? That would require taking it through the IP Clearance process. An SGA is the normal way to do this. > Pedro. > > On Tue, 27 Sep 2011 13:08:43 -0700, "Dennis E. Hamilton" > wrote: >> >> Uh, no, a source tarball is definitely not a binary form. >> >> Think in term of executables and dynamically-bound runtime >> libraries: something derived from source, but not source, >> and not meaningfully modifiable directly. It is not some- >> thing that is the basis for a derivative work and its >> distribution alone does not raise license-compatibility >> issues. >> >> - Dennis >> >> >> -Original Message- >> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com] >> Sent: Tuesday, September 27, 2011 09:25 >> To: ooo-dev@incubator.apache.org >> Subject: Re: [EXT][DISCUSS] Including Groovy as a scripting language >> >> [ ... ] >> >> Concerning the external sources that we still carry: would >> source tarballs of MPL/LGPL stuff be considered binary form? >> This is mostly what we do today so it would solve >> most of our issues (gettext still has to go), but that >> workaround would remove the motivation to further cleanup >> of the source (glibc could stay!) >> >> Pedro. > >
RE: [EXT][DISCUSS] Including Groovy as a scripting language
Thanks, I needed that clarified. Another point that Rob brought would be if we need a SGA to add the Groovy (or other) extension. I would think an SGA is a rather extreme thing to require for extensions: we wouldn't require that if we want to include stuff like ucpp, bsh, or icu ... or dmake ;). Pedro. On Tue, 27 Sep 2011 13:08:43 -0700, "Dennis E. Hamilton" wrote: Uh, no, a source tarball is definitely not a binary form. Think in term of executables and dynamically-bound runtime libraries: something derived from source, but not source, and not meaningfully modifiable directly. It is not some- thing that is the basis for a derivative work and its distribution alone does not raise license-compatibility issues. - Dennis -Original Message- From: Pedro F. Giffuni [mailto:giffu...@tutopia.com] Sent: Tuesday, September 27, 2011 09:25 To: ooo-dev@incubator.apache.org Subject: Re: [EXT][DISCUSS] Including Groovy as a scripting language [ ... ] Concerning the external sources that we still carry: would source tarballs of MPL/LGPL stuff be considered binary form? This is mostly what we do today so it would solve most of our issues (gettext still has to go), but that workaround would remove the motivation to further cleanup of the source (glibc could stay!) Pedro.
RE: [EXT][DISCUSS] Including Groovy as a scripting language
Uh, no, a source tarball is definitely not a binary form. Think in term of executables and dynamically-bound runtime libraries: something derived from source, but not source, and not meaningfully modifiable directly. It is not some- thing that is the basis for a derivative work and its distribution alone does not raise license-compatibility issues. - Dennis -Original Message- From: Pedro F. Giffuni [mailto:giffu...@tutopia.com] Sent: Tuesday, September 27, 2011 09:25 To: ooo-dev@incubator.apache.org Subject: Re: [EXT][DISCUSS] Including Groovy as a scripting language [ ... ] Concerning the external sources that we still carry: would source tarballs of MPL/LGPL stuff be considered binary form? This is mostly what we do today so it would solve most of our issues (gettext still has to go), but that workaround would remove the motivation to further cleanup of the source (glibc could stay!) Pedro.
dmake licensing issues again (was Re: [EXT][DISCUSS] Including Groovy as a scripting language)
--- On Tue, 9/27/11, Rob Weir wrote: > > Hello; > > > > --- On Tue, 9/27/11, Shane Curcuru wrote: > > .. > >> > >> I.e. there are cases where Apache projects may > >> want to include Category-B (EPL, CPL, MPL, etc.) > >> tools within a distribution. This is permitted > >> in binary form, but not source form. > >> > > > > Someone correct me if I am wrong, but dmake as we have > it > > today clearly lies in this category. > > > > Would it be part of the released distribution? That > is the key question. > I understand that you think that since it is a build tool it will not be linked to the binary distribution. If we only distribute binaries, that could be acceptable, but I don't see how you are going to avoid it being in the source distribution. Redistributing the MPL stuff in source code form is explicitly not permitted. The idea behind ASF permission to distribute them in binary form is to avoid any potential risk of developers editing the sources accidentally to find out later that part of their enhancements are under a copyleft license. > > But we should watch out and take this case-by-case. > This matters.. it's not a case by case issue but rather the rules: someone may want to make changes to dmake to build their own modules and then make their modified version of dmake available only on binary form. It may not make sense for us now but it's what users expect to do from code coming from the ASF. With dmake and other tools, and that was the second part of my comment, I think a tarball with the sources would be considered binary form. And then, just like with EPM, I think some people may prefer reusing a pre-built package instead of adding more time to the (already demanding) build. Pedro.
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Tue, Sep 27, 2011 at 12:24 PM, Pedro F. Giffuni wrote: > Hello; > > --- On Tue, 9/27/11, Shane Curcuru wrote: > .. >> >> I.e. there are cases where Apache projects may want to >> include Category-B (EPL, CPL, MPL, etc.) tools within a >> distribution. This is permitted in binary form, but >> not source form. >> > > Someone correct me if I am wrong, but dmake as we have it > today clearly lies in this category. > Would it be part of the released distribution? That is the key question. Some components are statically inked with our binaries. So when we distribute the binaries, we are copying the code, and that has license implications. Some components might be dynamically linked and are part of the user's desktop platform. In that case we don't need to distribute the binaries. Some components might be dynamically linked, but we cannot assume they are pre-installed on the platforms. In that case we do need to distribute the binaries, and that has license implications. And then some tools might not be used by the binaries at all. These are build tools, like make, dmake, perl and shell scripts, etc. They help us build, but they do not become part of the binaries. So look at this from the perspective of someone using our releases, source and binaries. If we used copyleft components linked into the binaries, then we would be restricting the rights of anyone who modified the code. For example, the GPL would require that they make all of their modifications available under GPL as well. But for build tools, like dmake, I think that is in another category. Dmake provides functionality for building. It doesn't provide functionality for the actual product. Using it does not add any obligations to the users of our code distributions. Even if they modified Dmake, they don't need to distribute dmake with their own binary distributions. And if they wanted to release their own source distributions then all they would need to do is distribute their dmake changes. Since the dmake code every bound with the OOo binaries, it doesn't have wider implications. The "weak" part of MPL, etc., is that it is not viral. The copyleft provision applies only to the actual code modified, not all the code that it is linked to. IMHO, a build tool has the effect of "weak copyleft" even if it was GPL. If the license is scoped to only the build tool itself and the tool is not required for the binary distributions, then I think the effect is similar. But we should watch out and take this case-by-case. -Rob > >> With these tools in binary form in the Apache release, a >> user is unlikely to attempt to modify that non-Apache >> licensed source code (which they'd have to go find >> themselves) without clearly realizing that that portion of >> the Apache release is not under our Apache license. >> > > Concerning the external sources that we still carry: would > source tarballs of MPL/LGPL stuff be considered binary form? > This is mostly what we do today so it would solve > most of our issues (gettext still has to go), but that > workaround would remove the motivation to further cleanup > of the source (glibc could stay!) > > Pedro. >
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Hello; --- On Tue, 9/27/11, Shane Curcuru wrote: .. > > I.e. there are cases where Apache projects may want to > include Category-B (EPL, CPL, MPL, etc.) tools within a > distribution. This is permitted in binary form, but > not source form. > Someone correct me if I am wrong, but dmake as we have it today clearly lies in this category. > With these tools in binary form in the Apache release, a > user is unlikely to attempt to modify that non-Apache > licensed source code (which they'd have to go find > themselves) without clearly realizing that that portion of > the Apache release is not under our Apache license. > Concerning the external sources that we still carry: would source tarballs of MPL/LGPL stuff be considered binary form? This is mostly what we do today so it would solve most of our issues (gettext still has to go), but that workaround would remove the motivation to further cleanup of the source (glibc could stay!) Pedro.
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On 9/27/2011 8:27 AM, Rob Weir wrote: ...snip... I think the difference between binary and source use in AOOo is important. When we bring source into the project we are inviting other project members, as well as our downstream consumers, to invest their own time into that code base, to maintain and improve it. So it is worth the extra effort to ensure that the source code is unencumbered. With a binary inclusions this is not an issue. (As an aside - to explain the rationale behind ASF licensing policies, and not necessarily about this tool itself:) Quite right. As the ASF legal FAQ notes [1] about a related kind of issue: "By including only the object/binary form, there is less exposed surface area of the third-party work from which a work might be derived; this addresses the second guiding principle of this policy. By attaching a prominent label to the distribution and requiring an explicit action by the user to get the reciprocally-licensed source, users are less likely to be unaware of restrictions significantly different from those of the Apache License. Please include the URL to the product's homepage in the prominent label." I.e. there are cases where Apache projects may want to include Category-B (EPL, CPL, MPL, etc.) tools within a distribution. This is permitted in binary form, but not source form. With these tools in binary form in the Apache release, a user is unlikely to attempt to modify that non-Apache licensed source code (which they'd have to go find themselves) without clearly realizing that that portion of the Apache release is not under our Apache license. -Shane [1] http://www.apache.org/legal/resolved.html#category-b
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Mon, Sep 26, 2011 at 11:02 PM, Carl Marcum wrote: > > On 09/26/2011 10:31 PM, Rob Weir wrote: >> >> As far as I can tell (and I may be wrong) the way to think of it is like >> this: >> >> 1) When we use a binary in the project (a 3rd party library) then >> having it be ALv2 or compatible is what we want. >> >> 2) When we include 3rd party source in the project, then ALv2 is also >> required, but we might have additional requirements, e.g. >> >> -- small contributions, in the nature of bug fixes and similar >> patches, nothing more required >> >> -- non-trivial code contributions made to the project -- a signed iCLA >> >> -- contribution of existing OSS projects -- signed SGA > > If something like and extension is made available under ALv2 can it be > included it without a SGA? > The relevant procedure is called "IP Clearance", which is described as: "From time to time, an external codebase is brought into the ASF that is not a separate incubating project but still represents a substantial contribution that was not developed within the ASF's source control system and on our public mailing lists. This is a short form of the Incubation checklist, designed to allow code to be imported with alacrity while still providing for oversight." See: http://incubator.apache.org/ip-clearance/index.html and http://incubator.apache.org/ip-clearance/ip-clearance-template.html Each case needs to be examined and documented. From what I can see the SGA is the normal way of doing this. I think the difference between binary and source use in AOOo is important. When we bring source into the project we are inviting other project members, as well as our downstream consumers, to invest their own time into that code base, to maintain and improve it. So it is worth the extra effort to ensure that the source code is unencumbered. With a binary inclusions this is not an issue. -Rob
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Hi, i have to confess that i have completely missed this extension until today. It shows again the power that we have to support scripting languages that are based on the JVM. I like it. >From a programmability perspective we should think about a better integration of scripting support in general. Besides Basic that is widely used and well known from MS office it would be nice if there would be volunteers interested to work on a better scripting solution than Basic. That would include of course a good and powerful IDE and tooling to make scripting as easy as possible and to benefit from the language features. Additional things like code completion, predefined code snippets for specific task that are easy to use in own scripts come to my mind. I think there is a lot of space for very interesting stuff in this direction and where the office can really benefit from. Juergen On Tue, Sep 27, 2011 at 9:02 AM, Andor E wrote: > Hi, > I'm currently working on updating the Groovy for OpenOffice.org > extension. I already have included the latest Groovy library. > Currently I'm writing an extender, that allows to access functions and > properties without imports and casts. I still have to overcome a few > stumbling blocks, but I hope to have something up for release soon. > > Greetings > > eymux > > On Tue, Sep 27, 2011 at 5:11 AM, Carl Marcum wrote: > > > > On 09/26/2011 10:41 PM, Pedro Giffuni wrote: > >> > >> Hi; > >> > >> I like it. I've been thinking that we should campaign moving > >> opensource extensions to apache-extras, as it could make > >> things easier for maintainers if they don't want to sign > >> an ICLA. > >> Of course I won't complain if you think it's better to include > >> this directly. > > > > The extension project is maintained on Sourceforge. > > > > I'm just seeing if there is interest right now. I use Groovy a lot but > > didn't know if others did. > > > >> > >> Pedro. > >> > >> On Mon, 26 Sep 2011 21:45:14 -0400, Carl Marcum > >> wrote: > >>> > >>> Hi all, > >>> > >>> I wanted to gauge the interest in including Groovy [1] as a scripting > >>> language. > >>> > >>> For those not familiar, Groovy is a dynamic language for the JVM that > >>> includes features like closures, builders, and dynamic typing. > >>> > >>> There is currently a Groovy For OpenOffice extension [2] for this > >>> available under LGPL. I have contacted the author regarding > >>> additionally licensing the extension as Apache and he would be willing > >>> to do that to include it. > >>> > >>> Groovy itself is under the Apache 2.0 so I thought it may be a good > fit. > >>> > >>> I am willing to work on this if there is interest. > >>> > >>> Best regards, > >>> Carl > >>> > >>> [1] http://groovy.codehaus.org/ > >>> [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice > >> > > Thanks, > > Carl > > >
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Hi, I'm currently working on updating the Groovy for OpenOffice.org extension. I already have included the latest Groovy library. Currently I'm writing an extender, that allows to access functions and properties without imports and casts. I still have to overcome a few stumbling blocks, but I hope to have something up for release soon. Greetings eymux On Tue, Sep 27, 2011 at 5:11 AM, Carl Marcum wrote: > > On 09/26/2011 10:41 PM, Pedro Giffuni wrote: >> >> Hi; >> >> I like it. I've been thinking that we should campaign moving >> opensource extensions to apache-extras, as it could make >> things easier for maintainers if they don't want to sign >> an ICLA. >> Of course I won't complain if you think it's better to include >> this directly. > > The extension project is maintained on Sourceforge. > > I'm just seeing if there is interest right now. I use Groovy a lot but > didn't know if others did. > >> >> Pedro. >> >> On Mon, 26 Sep 2011 21:45:14 -0400, Carl Marcum >> wrote: >>> >>> Hi all, >>> >>> I wanted to gauge the interest in including Groovy [1] as a scripting >>> language. >>> >>> For those not familiar, Groovy is a dynamic language for the JVM that >>> includes features like closures, builders, and dynamic typing. >>> >>> There is currently a Groovy For OpenOffice extension [2] for this >>> available under LGPL. I have contacted the author regarding >>> additionally licensing the extension as Apache and he would be willing >>> to do that to include it. >>> >>> Groovy itself is under the Apache 2.0 so I thought it may be a good fit. >>> >>> I am willing to work on this if there is interest. >>> >>> Best regards, >>> Carl >>> >>> [1] http://groovy.codehaus.org/ >>> [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice >> > Thanks, > Carl >
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On 09/26/2011 10:41 PM, Pedro Giffuni wrote: Hi; I like it. I've been thinking that we should campaign moving opensource extensions to apache-extras, as it could make things easier for maintainers if they don't want to sign an ICLA. Of course I won't complain if you think it's better to include this directly. The extension project is maintained on Sourceforge. I'm just seeing if there is interest right now. I use Groovy a lot but didn't know if others did. Pedro. On Mon, 26 Sep 2011 21:45:14 -0400, Carl Marcum wrote: Hi all, I wanted to gauge the interest in including Groovy [1] as a scripting language. For those not familiar, Groovy is a dynamic language for the JVM that includes features like closures, builders, and dynamic typing. There is currently a Groovy For OpenOffice extension [2] for this available under LGPL. I have contacted the author regarding additionally licensing the extension as Apache and he would be willing to do that to include it. Groovy itself is under the Apache 2.0 so I thought it may be a good fit. I am willing to work on this if there is interest. Best regards, Carl [1] http://groovy.codehaus.org/ [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice Thanks, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On 09/26/2011 10:31 PM, Rob Weir wrote: On Mon, Sep 26, 2011 at 9:45 PM, Carl Marcum wrote: Hi all, I wanted to gauge the interest in including Groovy [1] as a scripting language. For those not familiar, Groovy is a dynamic language for the JVM that includes features like closures, builders, and dynamic typing. There is currently a Groovy For OpenOffice extension [2] for this available under LGPL. I have contacted the author regarding additionally licensing the extension as Apache and he would be willing to do that to include it. Are you thinking of this as being integrated into the install the released AOOo? Or as an extension that we maintain in the Apache project and allow users to download post-install? I was thinking of it being included in the install via included extension. I'm not sure if that means we have to maintain it, but be willing to as to keep it current. Is the author thinking of joining the project as well? I didn't ask, only about licensing. Does it have any 3rd party dependencies that are not ALv2 (or compatible)? Unknown at this time. I'll look into it. Groovy itself is under the Apache 2.0 so I thought it may be a good fit. As far as I can tell (and I may be wrong) the way to think of it is like this: 1) When we use a binary in the project (a 3rd party library) then having it be ALv2 or compatible is what we want. 2) When we include 3rd party source in the project, then ALv2 is also required, but we might have additional requirements, e.g. -- small contributions, in the nature of bug fixes and similar patches, nothing more required -- non-trivial code contributions made to the project -- a signed iCLA -- contribution of existing OSS projects -- signed SGA If something like and extension is made available under ALv2 can it be included it without a SGA? I am willing to work on this if there is interest. Thanks for looking into this. -Rob Best regards, Carl [1] http://groovy.codehaus.org/ [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice Thanks, Carl
Re: [EXT][DISCUSS] Including Groovy as a scripting language
Hi; I like it. I've been thinking that we should campaign moving opensource extensions to apache-extras, as it could make things easier for maintainers if they don't want to sign an ICLA. Of course I won't complain if you think it's better to include this directly. Pedro. On Mon, 26 Sep 2011 21:45:14 -0400, Carl Marcum wrote: Hi all, I wanted to gauge the interest in including Groovy [1] as a scripting language. For those not familiar, Groovy is a dynamic language for the JVM that includes features like closures, builders, and dynamic typing. There is currently a Groovy For OpenOffice extension [2] for this available under LGPL. I have contacted the author regarding additionally licensing the extension as Apache and he would be willing to do that to include it. Groovy itself is under the Apache 2.0 so I thought it may be a good fit. I am willing to work on this if there is interest. Best regards, Carl [1] http://groovy.codehaus.org/ [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice
Re: [EXT][DISCUSS] Including Groovy as a scripting language
On Mon, Sep 26, 2011 at 9:45 PM, Carl Marcum wrote: > Hi all, > > I wanted to gauge the interest in including Groovy [1] as a scripting > language. > > For those not familiar, Groovy is a dynamic language for the JVM that > includes features like closures, builders, and dynamic typing. > > There is currently a Groovy For OpenOffice extension [2] for this available > under LGPL. I have contacted the author regarding additionally licensing the > extension as Apache and he would be willing to do that to include it. > Are you thinking of this as being integrated into the install the released AOOo? Or as an extension that we maintain in the Apache project and allow users to download post-install? Is the author thinking of joining the project as well? Does it have any 3rd party dependencies that are not ALv2 (or compatible)? > Groovy itself is under the Apache 2.0 so I thought it may be a good fit. > As far as I can tell (and I may be wrong) the way to think of it is like this: 1) When we use a binary in the project (a 3rd party library) then having it be ALv2 or compatible is what we want. 2) When we include 3rd party source in the project, then ALv2 is also required, but we might have additional requirements, e.g. -- small contributions, in the nature of bug fixes and similar patches, nothing more required -- non-trivial code contributions made to the project -- a signed iCLA -- contribution of existing OSS projects -- signed SGA > I am willing to work on this if there is interest. > Thanks for looking into this. -Rob > Best regards, > Carl > > [1] http://groovy.codehaus.org/ > [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice >
[EXT][DISCUSS] Including Groovy as a scripting language
Hi all, I wanted to gauge the interest in including Groovy [1] as a scripting language. For those not familiar, Groovy is a dynamic language for the JVM that includes features like closures, builders, and dynamic typing. There is currently a Groovy For OpenOffice extension [2] for this available under LGPL. I have contacted the author regarding additionally licensing the extension as Apache and he would be willing to do that to include it. Groovy itself is under the Apache 2.0 so I thought it may be a good fit. I am willing to work on this if there is interest. Best regards, Carl [1] http://groovy.codehaus.org/ [2] http://wiki.services.openoffice.org/wiki/GroovyForOpenOffice
