You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by John D'Orazio <jo...@cappellaniauniroma3.org> on 2020/11/06 14:13:05 UTC
Re: [DISCUSS] Groovy UNO Extensions
A Gradle implementation sounds good to me! I'm currently packaging some
libraries into the repo of my java plugin, but other developers interested
in participating in my project asked if I could implement Gradle to
simplify handling the dependencies.
And those helper methods look good! That would simplify things quite a bit.
Might I take the opportunity to ask, I'm currently in the process of
packaging JCEF (Java Chrome Embedded Framework) into my plugin. This
requires adding the path to the native libraries to the system path. I've
been successful in the build on Windows using JDK 1.8 since I'm able to use
reflection and reset the "java.library.path" at runtime. I haven't been as
successful with a Linux build, where I believe I need to set the
LD_LIBRARY_PATH environment variable to accommodate the path to the JCEF
native libraries. While in the testing phase just trying to get it working
on Linux, I've tried manually setting the LD_LIBRARY_PATH environment
variable on the command line before launching the "Debug install" from
Netbeans, however I'm seeing at runtime that the LD_LIBRARY_PATH variable
is being overwritten, I'm guessing by the Ant script? I see three
references to LD_LIBRARY_PATH in build-uno-impl.xml but I don't think I can
change anything there? I believe that file is automatically generated by
the Netbeans plugin, in fact it says at the very top of the file:
<!--
*** AUTOMATICALLY GENERATED - DO NOT EDIT ***
*** EDIT ../build.xml INSTEAD ***
-->
I confess I have hardly any experience with Ant, until now I've depended on
the AOO Netbeans plugin taking care of that and it's been enough for my
purposes. Now I'm finding that I need to link to other native libraries and
so I probably need to edit the Ant scripts to set environment variables and
"java.library.path". Any pointers on how I should go about doing so?
On Fri, Dec 18, 2015 at 12:49 PM Carl Marcum <cm...@apache.org> wrote:
>
>
> On 12/17/2015 11:53 PM, Pedro Giffuni wrote:
> > Hi Carl;
> >
> > You are definitely having quite awesome ideas lately :).
> > Actually, I tried to get the Groovy extension relicensed but I got
> > no reply from the developer of the old project.
> >
> > It sounds great to start a new effort from scratch.
> >
> > I am taking a forced break due to hardware issues but you
> > have my moral support! ;).
> >
> > Pedro.
> >
> Thanks Pedro !
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
don John R. D'Orazio
Cappellano Ingegneria e Scienze Roma Tre
________________________________________
Servizio di Cappellania - Università degli Studi Roma Tre
Piazzale San Paolo 1/d - 00120 Città del Vaticano
tel. +39 06-69880809 - cell. +39 333/2545447
E-Mail: *cappellania.uniroma3@gmail.com* <ca...@gmail.com> |
*cappellania@uniroma3.it* <ca...@uniroma3.it>
----
Sito Web: https://www.cappellaniauniroma3.org
Twitter: https://twitter.com/CappellaniaR3
Flickr: http://www.flickr.com/people/cappellaniauniroma3/
Pagina Facebook: https://www.facebook.com/cappellania.uniroma3
Gruppo Facebook: https://www.facebook.com/groups/cappellania.uniroma3
Pagina Google+: https://plus.google.com/+CappellaniaUniRoma3org
Community Google+: http://gplus.to/CappellaniaUniRoma3
LinkedIn:
http://www.linkedin.com/company/cappellania-universit-degli-studi-roma-tre
----
Per iscriversi al Calendario Pubblico della Cappellania (con account
gmail): [image: Iscriviti con Google Calendar]
<https://www.google.com/calendar/render?cid=8jugejikjtlks094p62hled6vs%40group.calendar.google.com>
Re: [DISCUSS] Groovy UNO Extensions
Posted by Carl Marcum <cm...@apache.org>.
Hi John,
I forgot there is also the example project[1] from the talk so you don't
have to generate one just to look at it.
And to use the Groovy UNO Extension you need to add it as a Gradle
dependency. It's not in the template yet.
Only works with Groovy though. For java you would need to extend the UNO
classes in your own library.
[1] https://github.com/cbmarcum/file-utils-addin
Best regards,
Carl
On 11/6/20 10:16 AM, Carl Marcum wrote:
> Hi John,
>
> (Sorry top posting)
>
> Since this thread, I've done a fair amount of work around this and
> some related related personal projects.
> I included them in my ApacheCon@Home OpenOffice UNO Programming with
> Groovy talk you can find on YouTube [1].
>
> The Groovy UNO Extension [2] and Documentation [3].
>
> The project you might want to look at is my openoffice-lazybones[4]
> template project that will generate gradle based exetension projects
> for Groovy or Java Add-Ins, or a Groovy based client. I haven't done
> an Add-On yet but I plan on it soon. Documentation is here[5].
>
> The add-in's show how I reused ant tasks from the Netbeans based
> extensions in a Gradle build. I moved ant to a sub-directory and
> called them from Gradle instead of re-writing them in Gradle. These
> projects have the Groovy UNO Extension as a dependency.
>
> If you have questions about my projects feel free to contact me off-list.
>
> [1] https://youtu.be/CzxLKG9CUvo
> [2] https://github.com/cbmarcum/guno-extension
> [3] https://cbmarcum.github.io/guno-extension/
> [4] https://github.com/cbmarcum/openoffice-lazybones
> [5] https://cbmarcum.github.io/openoffice-lazybones/
>
> Best regards,
> Carl
>
>
> On 11/6/20 9:13 AM, John D'Orazio wrote:
>> A Gradle implementation sounds good to me! I'm currently packaging some
>> libraries into the repo of my java plugin, but other developers
>> interested
>> in participating in my project asked if I could implement Gradle to
>> simplify handling the dependencies.
>> And those helper methods look good! That would simplify things quite
>> a bit.
>>
>> Might I take the opportunity to ask, I'm currently in the process of
>> packaging JCEF (Java Chrome Embedded Framework) into my plugin. This
>> requires adding the path to the native libraries to the system path.
>> I've
>> been successful in the build on Windows using JDK 1.8 since I'm able
>> to use
>> reflection and reset the "java.library.path" at runtime. I haven't
>> been as
>> successful with a Linux build, where I believe I need to set the
>> LD_LIBRARY_PATH environment variable to accommodate the path to the JCEF
>> native libraries. While in the testing phase just trying to get it
>> working
>> on Linux, I've tried manually setting the LD_LIBRARY_PATH environment
>> variable on the command line before launching the "Debug install" from
>> Netbeans, however I'm seeing at runtime that the LD_LIBRARY_PATH
>> variable
>> is being overwritten, I'm guessing by the Ant script? I see three
>> references to LD_LIBRARY_PATH in build-uno-impl.xml but I don't think
>> I can
>> change anything there? I believe that file is automatically generated by
>> the Netbeans plugin, in fact it says at the very top of the file:
>>
>> <!--
>> *** AUTOMATICALLY GENERATED - DO NOT EDIT ***
>> *** EDIT ../build.xml INSTEAD ***
>> -->
>>
>> I confess I have hardly any experience with Ant, until now I've
>> depended on
>> the AOO Netbeans plugin taking care of that and it's been enough for my
>> purposes. Now I'm finding that I need to link to other native
>> libraries and
>> so I probably need to edit the Ant scripts to set environment
>> variables and
>> "java.library.path". Any pointers on how I should go about doing so?
>>
>> On Fri, Dec 18, 2015 at 12:49 PM Carl Marcum <cm...@apache.org> wrote:
>>
>>>
>>> On 12/17/2015 11:53 PM, Pedro Giffuni wrote:
>>>> Hi Carl;
>>>>
>>>> You are definitely having quite awesome ideas lately :).
>>>> Actually, I tried to get the Groovy extension relicensed but I got
>>>> no reply from the developer of the old project.
>>>>
>>>> It sounds great to start a new effort from scratch.
>>>>
>>>> I am taking a forced break due to hardware issues but you
>>>> have my moral support! ;).
>>>>
>>>> Pedro.
>>>>
>>> Thanks Pedro !
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Groovy UNO Extensions
Posted by Carl Marcum <cm...@apache.org>.
Hi John,
(Sorry top posting)
Since this thread, I've done a fair amount of work around this and some
related related personal projects.
I included them in my ApacheCon@Home OpenOffice UNO Programming with
Groovy talk you can find on YouTube [1].
The Groovy UNO Extension [2] and Documentation [3].
The project you might want to look at is my openoffice-lazybones[4]
template project that will generate gradle based exetension projects for
Groovy or Java Add-Ins, or a Groovy based client. I haven't done an
Add-On yet but I plan on it soon. Documentation is here[5].
The add-in's show how I reused ant tasks from the Netbeans based
extensions in a Gradle build. I moved ant to a sub-directory and called
them from Gradle instead of re-writing them in Gradle. These projects
have the Groovy UNO Extension as a dependency.
If you have questions about my projects feel free to contact me off-list.
[1] https://youtu.be/CzxLKG9CUvo
[2] https://github.com/cbmarcum/guno-extension
[3] https://cbmarcum.github.io/guno-extension/
[4] https://github.com/cbmarcum/openoffice-lazybones
[5] https://cbmarcum.github.io/openoffice-lazybones/
Best regards,
Carl
On 11/6/20 9:13 AM, John D'Orazio wrote:
> A Gradle implementation sounds good to me! I'm currently packaging some
> libraries into the repo of my java plugin, but other developers interested
> in participating in my project asked if I could implement Gradle to
> simplify handling the dependencies.
> And those helper methods look good! That would simplify things quite a bit.
>
> Might I take the opportunity to ask, I'm currently in the process of
> packaging JCEF (Java Chrome Embedded Framework) into my plugin. This
> requires adding the path to the native libraries to the system path. I've
> been successful in the build on Windows using JDK 1.8 since I'm able to use
> reflection and reset the "java.library.path" at runtime. I haven't been as
> successful with a Linux build, where I believe I need to set the
> LD_LIBRARY_PATH environment variable to accommodate the path to the JCEF
> native libraries. While in the testing phase just trying to get it working
> on Linux, I've tried manually setting the LD_LIBRARY_PATH environment
> variable on the command line before launching the "Debug install" from
> Netbeans, however I'm seeing at runtime that the LD_LIBRARY_PATH variable
> is being overwritten, I'm guessing by the Ant script? I see three
> references to LD_LIBRARY_PATH in build-uno-impl.xml but I don't think I can
> change anything there? I believe that file is automatically generated by
> the Netbeans plugin, in fact it says at the very top of the file:
>
> <!--
> *** AUTOMATICALLY GENERATED - DO NOT EDIT ***
> *** EDIT ../build.xml INSTEAD ***
> -->
>
> I confess I have hardly any experience with Ant, until now I've depended on
> the AOO Netbeans plugin taking care of that and it's been enough for my
> purposes. Now I'm finding that I need to link to other native libraries and
> so I probably need to edit the Ant scripts to set environment variables and
> "java.library.path". Any pointers on how I should go about doing so?
>
> On Fri, Dec 18, 2015 at 12:49 PM Carl Marcum <cm...@apache.org> wrote:
>
>>
>> On 12/17/2015 11:53 PM, Pedro Giffuni wrote:
>>> Hi Carl;
>>>
>>> You are definitely having quite awesome ideas lately :).
>>> Actually, I tried to get the Groovy extension relicensed but I got
>>> no reply from the developer of the old project.
>>>
>>> It sounds great to start a new effort from scratch.
>>>
>>> I am taking a forced break due to hardware issues but you
>>> have my moral support! ;).
>>>
>>> Pedro.
>>>
>> Thanks Pedro !
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org