Re: devtools
Am 14.08.21 um 13:33 schrieb Peter Kovacs: Last discussion on this topic is at [1] [1] https://lists.apache.org/thread.html/r64090cf9de98c0147098b5d7d58b5f248c71b42e06d3dcb1c536bc88%40%3Cdev.openoffice.apache.org%3E +1 to move to git. I would separate each tool in an own repository. But as long as it is done I would agree to a devtools repository. To migrate it back into OpenOffice.git I am at -1 because OpenOffice Code + Build environment is already hard to learn. Especially for new commers. It is better to cluster by topics. I also think that code and tools should be separated. We have the following tools (or maybe also some more): aoo-stats bootstrap-connector build-scripts bz-tools genUpdateFeed guno-extension hg2svn lazybones-templates list-stats release-scripts scripts sdk-examples svn-stats updateVersion I don't think that we should create an own repo for each of them. This would be too much overhead. Please let us keep all tools in 1 repo together. It's just 25 MB of space or a few MBs more. Marcus On 12.08.21 18:00, Jim Jagielski wrote: Any other opinions or comments? On Aug 6, 2021, at 12:52 PM, Jim Jagielski wrote: To me, it being within OpenOffice.git makes the most sense... but I'm fine either way On Aug 6, 2021, at 12:49 PM, Dave Fisher wrote: Within /Apache/OpenOffice.git repository? Or a new /Apache/OpenOffice-devtools.git? +1, especially if history is preserved. Of course there would be wiki and webpages to update. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
re: devtools
Last discussion on this topic is at [1] [1] https://lists.apache.org/thread.html/r64090cf9de98c0147098b5d7d58b5f248c71b42e06d3dcb1c536bc88%40%3Cdev.openoffice.apache.org%3E +1 to move to git. I would separate each tool in an own repository. But as long as it is done I would agree to a devtools repository. To migrate it back into OpenOffice.git I am at -1 because OpenOffice Code + Build environment is already hard to learn. Especially for new commers. It is better to cluster by topics. All the best Peter On 12.08.21 18:00, Jim Jagielski wrote: Any other opinions or comments? On Aug 6, 2021, at 12:52 PM, Jim Jagielski wrote: To me, it being within OpenOffice.git makes the most sense... but I'm fine either way On Aug 6, 2021, at 12:49 PM, Dave Fisher wrote: Within /Apache/OpenOffice.git repository? Or a new /Apache/OpenOffice-devtools.git? +1, especially if history is preserved. Of course there would be wiki and webpages to update. Sent from my iPhone On Aug 6, 2021, at 9:31 AM, Jim Jagielski wrote: Our devtools repo is till under svn; should we switch it to git. It would be nice, I think, to use on version control implementation for all our code related repos. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- This is the Way! http://www.apache.org/theapacheway/index.html
Re: devtools
Hi Arrigo, Am 13.08.21 um 16:14 schrieb Arrigo Marchiori: > Hello Jim, All, > > On Fri, Aug 06, 2021 at 12:30:43PM -0400, Jim Jagielski wrote: > >> Our devtools repo is till under svn; should we switch it to git. It >> would be nice, I think, to use on version control implementation for >> all our code related repos. > TL;DR: +1 > > Longer reply: I agree it would, and I suggest we use a separate > repository. > > I can only talk about build-scripts because I have been tinkering with > them. They have a ``historical'' structure that IMHO does not merge > well with the current layout of the main source repository (which is > already very complex). > > But I also don't know how much an effort it would require, to make a > new Git repository under the Apache ``flag''. I think that whatever > repository we choose, it should belong to the Apache Software > Foundation. That's Self Service: https://gitbox.apache.org/setup/newrepo.html Regards, Matthias > > These are just my two cents. > > Best regards, smime.p7s Description: S/MIME Cryptographic Signature
Re: devtools
Hello Jim, All, On Fri, Aug 06, 2021 at 12:30:43PM -0400, Jim Jagielski wrote: > Our devtools repo is till under svn; should we switch it to git. It > would be nice, I think, to use on version control implementation for > all our code related repos. TL;DR: +1 Longer reply: I agree it would, and I suggest we use a separate repository. I can only talk about build-scripts because I have been tinkering with them. They have a ``historical'' structure that IMHO does not merge well with the current layout of the main source repository (which is already very complex). But I also don't know how much an effort it would require, to make a new Git repository under the Apache ``flag''. I think that whatever repository we choose, it should belong to the Apache Software Foundation. These are just my two cents. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools
Hi Jim, For the directories: bootstrap-connector guno-extension lazybones-templates I have copied to my github account projects and have been working on them there. I haven't done anything with netbeansintegration yet but I could. These all work best as standalone projects in Git due to the way they each build an artifact and it helped with issue tracking and releasing (personal releases that is). I'm okay if you want to copy the whole tree over so they have a home in git. I can go back and get them updated either way. Best regards, Carl On 8/12/21 12:00 PM, Jim Jagielski wrote: Any other opinions or comments? On Aug 6, 2021, at 12:52 PM, Jim Jagielski wrote: To me, it being within OpenOffice.git makes the most sense... but I'm fine either way ;) On Aug 6, 2021, at 12:49 PM, Dave Fisher wrote: Within /Apache/OpenOffice.git repository? Or a new /Apache/OpenOffice-devtools.git? +1, especially if history is preserved. Of course there would be wiki and webpages to update. Sent from my iPhone On Aug 6, 2021, at 9:31 AM, Jim Jagielski wrote: Our devtools repo is till under svn; should we switch it to git. It would be nice, I think, to use on version control implementation for all our code related repos. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools
Any other opinions or comments? > On Aug 6, 2021, at 12:52 PM, Jim Jagielski wrote: > > To me, it being within OpenOffice.git makes the most sense... but I'm fine > either way ;) > >> On Aug 6, 2021, at 12:49 PM, Dave Fisher wrote: >> >> Within /Apache/OpenOffice.git repository? Or a new >> /Apache/OpenOffice-devtools.git? >> >> +1, especially if history is preserved. >> >> Of course there would be wiki and webpages to update. >> >> Sent from my iPhone >> >>> On Aug 6, 2021, at 9:31 AM, Jim Jagielski wrote: >>> >>> Our devtools repo is till under svn; should we switch it to git. It would >>> be nice, I think, to use on version control implementation for all our code >>> related repos. >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools
To me, it being within OpenOffice.git makes the most sense... but I'm fine either way ;) > On Aug 6, 2021, at 12:49 PM, Dave Fisher wrote: > > Within /Apache/OpenOffice.git repository? Or a new > /Apache/OpenOffice-devtools.git? > > +1, especially if history is preserved. > > Of course there would be wiki and webpages to update. > > Sent from my iPhone > >> On Aug 6, 2021, at 9:31 AM, Jim Jagielski wrote: >> >> Our devtools repo is till under svn; should we switch it to git. It would >> be nice, I think, to use on version control implementation for all our code >> related repos. >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools
Within /Apache/OpenOffice.git repository? Or a new /Apache/OpenOffice-devtools.git? +1, especially if history is preserved. Of course there would be wiki and webpages to update. Sent from my iPhone > On Aug 6, 2021, at 9:31 AM, Jim Jagielski wrote: > > Our devtools repo is till under svn; should we switch it to git. It would be > nice, I think, to use on version control implementation for all our code > related repos. > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
devtools
Our devtools repo is till under svn; should we switch it to git. It would be nice, I think, to use on version control implementation for all our code related repos. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1890844 - /openoffice/devtools/build-scripts/4.1.10/wntmsci/build_aoo32bit_on_mingw. sh
Hello all, On Thu, Jun 17, 2021 at 02:54:26AM +0200, Damjan Jovanovic wrote: > On Thu, Jun 17, 2021 at 1:34 AM Don Lewis wrote: > > > On 16 Jun, ard...@apache.org wrote: > > > Author: ardovm > > > Date: Wed Jun 16 19:07:44 2021 > > > New Revision: 1890844 > > > > > > URL: http://svn.apache.org/viewvc?rev=1890844&view=rev > > > Log: > > > Build script for AOO 4.1.10 under Mingw > > > > > > Better late than never... could be used as a template for the future > > > > I thought our Mingw support had rotted. [...] ...and so had my brain, for a short while. I wrote "Mingw" instead of "Cygwin". I apologize for the noise! I renamed the file shortly therafter (thanks to Matthias who pointed to me the error immediately). But, quoting Damjan: > While never tested, every change I made for the modules I ported to gbuild, > and gbuild itself, had mingw support preserved as much as I could. This is very interesting! Damjan, (one of) the next things on my to-do list is to peek into your Scons branch and try to see if I can help there. Does that branch also try to preserve compatibility with Mingw? Thank you in advance and best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1890844 - /openoffice/devtools/build-scripts/4.1.10/wntmsci/build_aoo32bit_on_mingw. sh
On Thu, Jun 17, 2021 at 1:34 AM Don Lewis wrote: > On 16 Jun, ard...@apache.org wrote: > > Author: ardovm > > Date: Wed Jun 16 19:07:44 2021 > > New Revision: 1890844 > > > > URL: http://svn.apache.org/viewvc?rev=1890844&view=rev > > Log: > > Build script for AOO 4.1.10 under Mingw > > > > Better late than never... could be used as a template for the future > > I thought our Mingw support had rotted. It hasn't been used in ages. > > While never tested, every change I made for the modules I ported to gbuild, and gbuild itself, had mingw support preserved as much as I could.
Re: svn commit: r1890844 - /openoffice/devtools/build-scripts/4.1.10/wntmsci/build_aoo32bit_on_mingw. sh
On 16 Jun, ard...@apache.org wrote: > Author: ardovm > Date: Wed Jun 16 19:07:44 2021 > New Revision: 1890844 > > URL: http://svn.apache.org/viewvc?rev=1890844&view=rev > Log: > Build script for AOO 4.1.10 under Mingw > > Better late than never... could be used as a template for the future I thought our Mingw support had rotted. It hasn't been used in ages. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposed changes to devtools/build-scripts on SVN
rigo, thanks for the great email.. I will be posting my comments/answers inline. > On Dec 8, 2020, at 4:13 PM, Arrigo Marchiori wrote: > > Dear List, > > while working on pull requests, I was wondering how to test the most > common build options for OpenOffice -- possibly the same used for > release builds. > > I must confess I got lost a couple of times while searching the wiki > for this information, but I eventually found out this SVN repository: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/ > > I would like to propose some changes to those scripts. They do not > seem to be on GitHub, so a pull request is not possible. I am writing > to this list in the hope to reach the responsible people. I will be > happy to write to more direct email addresses, if anyone could point > them out to me. > For the most part, I do the Linux and macOS community builds. > 1- there seems to be a hidden bug. The configure script is called in > a subshell and its output is piped to tee(1). However, this discards > the return value of the configure script, and this does not seem to > be the intended behavior (the subshell invocation is followed by > "|| exit 1"). Solution: add "set -o pipefail" before invoking the > configure script. Great suggestion. > > 2- I would like to propose not to rely on dmake and epm to be > installed in /usr/local/bin, but to rather make them optional. If > they are found, they are used; otherwise, their URL's are passed to > the configure script so that the build system will take care of > building them. As I understand it, that would require the use of both configure options for EPM/dmake. One which sez "look for it locally" (basically, the one now where we specify a path) and the other that provides a download URL. Does that match your understanding? > > 3- I would like to propose build scripts for Ubuntu 18.04 and for > opeSUSE Leap 15 systems (they are what I have at hand at the moment) > Great! > 4- possibly other personalizations, such as the number of concurrent > jobs (8 is a bit too much for my computers :-) > Yes. In fact, I have been doing such things w/ the macOS build script where I allow for various command line options to change what is passed to configure. Of course, the question/issue arises that, after all, the main function of the build script is to pass options to configure, and it is easy to make the build script more complex that simply driving configure manually :) Please take a look at the macOS build scripts, esp for the 4.2.0-Dev code, and see if that match what you are thinking. > If the responsible people are interested in the above changes, then I > will be happy to send the changes in patch(1) format. Or, to open a > bug report. Alternatively, I am 100% open to discuss the above by > email. Cheers! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposed changes to devtools/build-scripts on SVN
This is the correct list. Sent from my iPhone > On Dec 8, 2020, at 1:13 PM, Arrigo Marchiori wrote: > > Dear List, > > while working on pull requests, I was wondering how to test the most > common build options for OpenOffice -- possibly the same used for > release builds. > > I must confess I got lost a couple of times while searching the wiki > for this information, but I eventually found out this SVN repository: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/ > > I would like to propose some changes to those scripts. They do not > seem to be on GitHub, so a pull request is not possible. I am writing > to this list in the hope to reach the responsible people. I will be > happy to write to more direct email addresses, if anyone could point > them out to me. > > 1- there seems to be a hidden bug. The configure script is called in > a subshell and its output is piped to tee(1). However, this discards > the return value of the configure script, and this does not seem to > be the intended behavior (the subshell invocation is followed by > "|| exit 1"). Solution: add "set -o pipefail" before invoking the > configure script. > > 2- I would like to propose not to rely on dmake and epm to be > installed in /usr/local/bin, but to rather make them optional. If > they are found, they are used; otherwise, their URL's are passed to > the configure script so that the build system will take care of > building them. > > 3- I would like to propose build scripts for Ubuntu 18.04 and for > opeSUSE Leap 15 systems (they are what I have at hand at the moment) > > 4- possibly other personalizations, such as the number of concurrent > jobs (8 is a bit too much for my computers :-) > > If the responsible people are interested in the above changes, then I > will be happy to send the changes in patch(1) format. Or, to open a > bug report. Alternatively, I am 100% open to discuss the above by > email. > > Regards, > -- > rigo > > http://rigo.altervista.org > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Proposed changes to devtools/build-scripts on SVN
Dear List, while working on pull requests, I was wondering how to test the most common build options for OpenOffice -- possibly the same used for release builds. I must confess I got lost a couple of times while searching the wiki for this information, but I eventually found out this SVN repository: http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/ I would like to propose some changes to those scripts. They do not seem to be on GitHub, so a pull request is not possible. I am writing to this list in the hope to reach the responsible people. I will be happy to write to more direct email addresses, if anyone could point them out to me. 1- there seems to be a hidden bug. The configure script is called in a subshell and its output is piped to tee(1). However, this discards the return value of the configure script, and this does not seem to be the intended behavior (the subshell invocation is followed by "|| exit 1"). Solution: add "set -o pipefail" before invoking the configure script. 2- I would like to propose not to rely on dmake and epm to be installed in /usr/local/bin, but to rather make them optional. If they are found, they are used; otherwise, their URL's are passed to the configure script so that the build system will take care of building them. 3- I would like to propose build scripts for Ubuntu 18.04 and for opeSUSE Leap 15 systems (they are what I have at hand at the moment) 4- possibly other personalizations, such as the number of concurrent jobs (8 is a bit too much for my computers :-) If the responsible people are interested in the above changes, then I will be happy to send the changes in patch(1) format. Or, to open a bug report. Alternatively, I am 100% open to discuss the above by email. Regards, -- rigo http://rigo.altervista.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools repo - move to git
There is. On Fri, Aug 7, 2020, 12:04 AM Peter Kovacs wrote: > I am suggesting to break the svn in several repos, yes. But we can do it > theoretically at any time. I just thought if we switch it is a good > opportunity to take a look. As I said below we have ideas to split multiple > things into smaller parts. > There is no rush. > > Am 6. August 2020 13:56:27 MESZ schrieb Jim Jagielski : > >So are you thinking about breaking devtools into a bunch of sep repos? > >Or keeping it as a single repo that contains a collection of devtools? > > > >Why am I proposing this: Currently, to build our community AOO builds > >you need BOTH svn and git. It would be nice to need just one. > > > >> On Aug 5, 2020, at 8:50 AM, Peter Kovacs wrote: > >> > >> Due to the fact that Git repos unlike svn can only checked out in > >total, I would rather prefer to split all applications into own repos. > >> Just don't forget we have the idea to split a lot of other things. > >GSI Check will move into its own Repo. UNO libraries WE have talked > >about to separate into own repo, too. > >> And I would a t some point also think of extract MediaWiki, and Star > >Basic into own Repos without changing our binary install file. > >> > >> Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg > >: > >>> Good.send on. > >>> > >>> On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: > >>> > >>>> Hi Jim, > >>>> > >>>> On 8/4/20 4:12 PM, Jim Jagielski wrote: > >>>>> Considering that AOO is now, itself, under gitbox, should we also > >>> move > >>>> devtools as well over there as well? > >>>>> > >>> > >- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>>> > >>>> > >>>> Where were you thinking of putting it? > >>>> > >>>> In a separate project? > >>>> > >>>> For the directories: > >>>> bootstrap-connector > >>>> guno-extension > >>>> lazybones-templates > >>>> > >>>> I have copied to my github account projects and have been working > >on > >>>> them there. > >>>> > >>>> I haven't done anything with netbeansintegration yet but I could. > >>>> > >>>> These all work best as standalone projects in Git due to the way > >they > >>>> each build an artifact > >>>> and it helped with issue tracking. > >>>> > >>>> If we could do that under Apache that would be great. > >>>> > >>>> Best regards, > >>>> Carl > >>>> > >>>> > >- > >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>> > >>>> > > > > > >- > >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >For additional commands, e-mail: dev-h...@openoffice.apache.org >
Re: devtools repo - move to git
I am suggesting to break the svn in several repos, yes. But we can do it theoretically at any time. I just thought if we switch it is a good opportunity to take a look. As I said below we have ideas to split multiple things into smaller parts. There is no rush. Am 6. August 2020 13:56:27 MESZ schrieb Jim Jagielski : >So are you thinking about breaking devtools into a bunch of sep repos? >Or keeping it as a single repo that contains a collection of devtools? > >Why am I proposing this: Currently, to build our community AOO builds >you need BOTH svn and git. It would be nice to need just one. > >> On Aug 5, 2020, at 8:50 AM, Peter Kovacs wrote: >> >> Due to the fact that Git repos unlike svn can only checked out in >total, I would rather prefer to split all applications into own repos. >> Just don't forget we have the idea to split a lot of other things. >GSI Check will move into its own Repo. UNO libraries WE have talked >about to separate into own repo, too. >> And I would a t some point also think of extract MediaWiki, and Star >Basic into own Repos without changing our binary install file. >> >> Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg >: >>> Good.send on. >>> >>> On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: >>> >>>> Hi Jim, >>>> >>>> On 8/4/20 4:12 PM, Jim Jagielski wrote: >>>>> Considering that AOO is now, itself, under gitbox, should we also >>> move >>>> devtools as well over there as well? >>>>> >>> >- >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>> >>>> >>>> Where were you thinking of putting it? >>>> >>>> In a separate project? >>>> >>>> For the directories: >>>> bootstrap-connector >>>> guno-extension >>>> lazybones-templates >>>> >>>> I have copied to my github account projects and have been working >on >>>> them there. >>>> >>>> I haven't done anything with netbeansintegration yet but I could. >>>> >>>> These all work best as standalone projects in Git due to the way >they >>>> each build an artifact >>>> and it helped with issue tracking. >>>> >>>> If we could do that under Apache that would be great. >>>> >>>> Best regards, >>>> Carl >>>> >>>> >- >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>>> > > >- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools repo - move to git
So are you thinking about breaking devtools into a bunch of sep repos? Or keeping it as a single repo that contains a collection of devtools? Why am I proposing this: Currently, to build our community AOO builds you need BOTH svn and git. It would be nice to need just one. > On Aug 5, 2020, at 8:50 AM, Peter Kovacs wrote: > > Due to the fact that Git repos unlike svn can only checked out in total, I > would rather prefer to split all applications into own repos. > Just don't forget we have the idea to split a lot of other things. GSI Check > will move into its own Repo. UNO libraries WE have talked about to separate > into own repo, too. > And I would a t some point also think of extract MediaWiki, and Star Basic > into own Repos without changing our binary install file. > > Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg > : >> Good.send on. >> >> On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: >> >>> Hi Jim, >>> >>> On 8/4/20 4:12 PM, Jim Jagielski wrote: >>>> Considering that AOO is now, itself, under gitbox, should we also >> move >>> devtools as well over there as well? >>>> >> - >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>> >>> Where were you thinking of putting it? >>> >>> In a separate project? >>> >>> For the directories: >>> bootstrap-connector >>> guno-extension >>> lazybones-templates >>> >>> I have copied to my github account projects and have been working on >>> them there. >>> >>> I haven't done anything with netbeansintegration yet but I could. >>> >>> These all work best as standalone projects in Git due to the way they >>> each build an artifact >>> and it helped with issue tracking. >>> >>> If we could do that under Apache that would be great. >>> >>> Best regards, >>> Carl >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools repo - move to git
Imho Svn or Git is also not important. ;) Am 5. August 2020 15:56:34 MESZ schrieb Nathan Rosenburg : >Not important. > >On Wed, Aug 5, 2020, 7:50 AM Peter Kovacs wrote: > >> Due to the fact that Git repos unlike svn can only checked out in >total, I >> would rather prefer to split all applications into own repos. >> Just don't forget we have the idea to split a lot of other things. >GSI >> Check will move into its own Repo. UNO libraries WE have talked about >to >> separate into own repo, too. >> And I would a t some point also think of extract MediaWiki, and Star >Basic >> into own Repos without changing our binary install file. >> >> Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg < >> nathanrosenburg198...@gmail.com>: >> >Good.send on. >> > >> >On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: >> > >> >> Hi Jim, >> >> >> >> On 8/4/20 4:12 PM, Jim Jagielski wrote: >> >> > Considering that AOO is now, itself, under gitbox, should we >also >> >move >> >> devtools as well over there as well? >> >> > >> >>- >> >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> >> > For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > >> >> >> >> Where were you thinking of putting it? >> >> >> >> In a separate project? >> >> >> >> For the directories: >> >> bootstrap-connector >> >> guno-extension >> >> lazybones-templates >> >> >> >> I have copied to my github account projects and have been working >on >> >> them there. >> >> >> >> I haven't done anything with netbeansintegration yet but I could. >> >> >> >> These all work best as standalone projects in Git due to the way >they >> >> each build an artifact >> >> and it helped with issue tracking. >> >> >> >> If we could do that under Apache that would be great. >> >> >> >> Best regards, >> >> Carl >> >> >> >> >- >> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> >> >> >>
Re: devtools repo - move to git
Not important. On Wed, Aug 5, 2020, 7:50 AM Peter Kovacs wrote: > Due to the fact that Git repos unlike svn can only checked out in total, I > would rather prefer to split all applications into own repos. > Just don't forget we have the idea to split a lot of other things. GSI > Check will move into its own Repo. UNO libraries WE have talked about to > separate into own repo, too. > And I would a t some point also think of extract MediaWiki, and Star Basic > into own Repos without changing our binary install file. > > Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg < > nathanrosenburg198...@gmail.com>: > >Good.send on. > > > >On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: > > > >> Hi Jim, > >> > >> On 8/4/20 4:12 PM, Jim Jagielski wrote: > >> > Considering that AOO is now, itself, under gitbox, should we also > >move > >> devtools as well over there as well? > >> > > >- > >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > >> > >> Where were you thinking of putting it? > >> > >> In a separate project? > >> > >> For the directories: > >> bootstrap-connector > >> guno-extension > >> lazybones-templates > >> > >> I have copied to my github account projects and have been working on > >> them there. > >> > >> I haven't done anything with netbeansintegration yet but I could. > >> > >> These all work best as standalone projects in Git due to the way they > >> each build an artifact > >> and it helped with issue tracking. > >> > >> If we could do that under Apache that would be great. > >> > >> Best regards, > >> Carl > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> >
Re: devtools repo - move to git
Due to the fact that Git repos unlike svn can only checked out in total, I would rather prefer to split all applications into own repos. Just don't forget we have the idea to split a lot of other things. GSI Check will move into its own Repo. UNO libraries WE have talked about to separate into own repo, too. And I would a t some point also think of extract MediaWiki, and Star Basic into own Repos without changing our binary install file. Am 5. August 2020 15:05:22 MESZ schrieb Nathan Rosenburg : >Good.send on. > >On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: > >> Hi Jim, >> >> On 8/4/20 4:12 PM, Jim Jagielski wrote: >> > Considering that AOO is now, itself, under gitbox, should we also >move >> devtools as well over there as well? >> > >- >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> > For additional commands, e-mail: dev-h...@openoffice.apache.org >> > >> >> Where were you thinking of putting it? >> >> In a separate project? >> >> For the directories: >> bootstrap-connector >> guno-extension >> lazybones-templates >> >> I have copied to my github account projects and have been working on >> them there. >> >> I haven't done anything with netbeansintegration yet but I could. >> >> These all work best as standalone projects in Git due to the way they >> each build an artifact >> and it helped with issue tracking. >> >> If we could do that under Apache that would be great. >> >> Best regards, >> Carl >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >>
Re: devtools repo - move to git
Good.send on. On Tue, Aug 4, 2020, 5:09 PM Carl Marcum wrote: > Hi Jim, > > On 8/4/20 4:12 PM, Jim Jagielski wrote: > > Considering that AOO is now, itself, under gitbox, should we also move > devtools as well over there as well? > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > Where were you thinking of putting it? > > In a separate project? > > For the directories: > bootstrap-connector > guno-extension > lazybones-templates > > I have copied to my github account projects and have been working on > them there. > > I haven't done anything with netbeansintegration yet but I could. > > These all work best as standalone projects in Git due to the way they > each build an artifact > and it helped with issue tracking. > > If we could do that under Apache that would be great. > > Best regards, > Carl > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: devtools repo - move to git
On 8/4/20 7:23 PM, Jim Jagielski wrote: On Aug 4, 2020, at 6:09 PM, Carl Marcum wrote: Hi Jim, On 8/4/20 4:12 PM, Jim Jagielski wrote: Considering that AOO is now, itself, under gitbox, should we also move devtools as well over there as well? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Where were you thinking of putting it? In a separate project? Just copying the entire repo into a github repo... nothing fancy :) Sounds good. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools repo - move to git
> On Aug 4, 2020, at 6:09 PM, Carl Marcum wrote: > > Hi Jim, > > On 8/4/20 4:12 PM, Jim Jagielski wrote: >> Considering that AOO is now, itself, under gitbox, should we also move >> devtools as well over there as well? >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > Where were you thinking of putting it? > > In a separate project? Just copying the entire repo into a github repo... nothing fancy :) > > For the directories: > bootstrap-connector > guno-extension > lazybones-templates > > I have copied to my github account projects and have been working on them > there. > > I haven't done anything with netbeansintegration yet but I could. > > These all work best as standalone projects in Git due to the way they each > build an artifact > and it helped with issue tracking. > > If we could do that under Apache that would be great. > > Best regards, > Carl > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: devtools repo - move to git
Hi Jim, On 8/4/20 4:12 PM, Jim Jagielski wrote: Considering that AOO is now, itself, under gitbox, should we also move devtools as well over there as well? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Where were you thinking of putting it? In a separate project? For the directories: bootstrap-connector guno-extension lazybones-templates I have copied to my github account projects and have been working on them there. I haven't done anything with netbeansintegration yet but I could. These all work best as standalone projects in Git due to the way they each build an artifact and it helped with issue tracking. If we could do that under Apache that would be great. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
devtools repo - move to git
Considering that AOO is now, itself, under gitbox, should we also move devtools as well over there as well? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
Hi Pedro, Am 22.10.18 um 18:47 schrieb Pedro Lino: > Hi all > > >> On October 22, 2018 at 5:38 PM Matthias Seidel > mailto:matthias.sei...@hamburg.de > wrote: >> >> >> Am 22.10.18 um 18:35 schrieb Jim Jagielski: >> >> > > The thing is, IMO, that these ARE community builds, and, as >> such, should be noted as such on the About Page... But I'm fine w/ removing >> that depending on what people think. >>> > The community is not a vendor. If you leave it out everything is >>> OK: >> "This product was created by the OpenOffice community." >> > > Shouldn't it be "This product was created by the OpenOffice community, based > on Apache OpenOffice." for all OSes? That phrase is hard coded in: https://svn.apache.org/repos/asf/openoffice/branches/AOO416/main/cui/source/dialogs/about.src I wouldn't want to change it for 4.1.x (localization would be needed). Maybe for 4.2.x? Regards, Matthias > > I agree with Matthias that "This product was created by Apache OpenOffice > Community Build" does not make sense in English > > > Regards, > > Pedro > > >> > >> >> On Oct 22, 2018, at 12:32 PM, Matthias Seidel >> mailto:matthias.sei...@hamburg.de > wrote: >> >> >> >> Am 22.10.18 um 18:13 schrieb Jim Jagielski: >> >>> It was used for macOS. I was just making it consistent among all my >> builds. >> >> Wouldn't it be better to make the macOS build consistent with the >> other >> >> builds... ;-) >> >> >> >>>> On Oct 22, 2018, at 12:08 PM, Matthias Seidel >> mailto:matthias.sei...@hamburg.de > wrote: >> >>>> >> >>>> Hi Jim, >> >>>> >> >>>> --with-vendor="Apache OpenOffice Community Build" \ >> >>>> >> >>>> results in weird wording: >> >>>> >> >>>> "This product was created by Apache OpenOffice Community Build, >> based on >> >>>> Apache OpenOffice" >> >>>> >> >>>> And we didn't use --with-vendor for a release build before. >> >>>> >> >>>> Regards, >> >>>> >> >>>> Matthias >> >>>> >> >>>> Am 22.10.18 um 14:31 schrieb j...@apache.org mailto:j...@apache.org >> : >> >>>>> Author: jim >> >>>>> Date: Mon Oct 22 12:31:52 2018 >> >>>>> New Revision: 1844550 >> >>>>> >> >>>>> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev >> http://svn.apache.org/viewvc?rev=1844550&view=rev >> >>>>> Log: >> >>>>> Update vendor for builds >> >>>>> >> >>>>> Modified: >> >>>>> >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> >>>>> >> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >> >>>>> >> >>>>> Modified: >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> >>>>> URL: >> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >> >> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >> >>>>> >> == >> >>>>> --- >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> (original) >> >>>>> +++ >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> Mon Oct 22 12:31:52 2018 >> >>>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >> >>>>> fi >> >>>>> ./configure \ >> >>>>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >> >>>>> + --with-vendor="Apache OpenOffice Community Bui
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
Hi all > On October 22, 2018 at 5:38 PM Matthias Seidel mailto:matthias.sei...@hamburg.de > wrote: > > > Am 22.10.18 um 18:35 schrieb Jim Jagielski: > > > > The thing is, IMO, that these ARE community builds, and, as such, > should be noted as such on the About Page... But I'm fine w/ removing that > depending on what people think. > > > > > The community is not a vendor. If you leave it out everything is > > OK: > > "This product was created by the OpenOffice community." > Shouldn't it be "This product was created by the OpenOffice community, based on Apache OpenOffice." for all OSes? I agree with Matthias that "This product was created by Apache OpenOffice Community Build" does not make sense in English Regards, Pedro > > > > >> On Oct 22, 2018, at 12:32 PM, Matthias Seidel > mailto:matthias.sei...@hamburg.de > wrote: > >> > >> Am 22.10.18 um 18:13 schrieb Jim Jagielski: > >>> It was used for macOS. I was just making it consistent among all my > builds. > >> Wouldn't it be better to make the macOS build consistent with the other > >> builds... ;-) > >> > >>>> On Oct 22, 2018, at 12:08 PM, Matthias Seidel > mailto:matthias.sei...@hamburg.de > wrote: > >>>> > >>>> Hi Jim, > >>>> > >>>> --with-vendor="Apache OpenOffice Community Build" \ > >>>> > >>>> results in weird wording: > >>>> > >>>> "This product was created by Apache OpenOffice Community Build, > based on > >>>> Apache OpenOffice" > >>>> > >>>> And we didn't use --with-vendor for a release build before. > >>>> > >>>> Regards, > >>>> > >>>> Matthias > >>>> > >>>> Am 22.10.18 um 14:31 schrieb j...@apache.org mailto:j...@apache.org : > >>>>> Author: jim > >>>>> Date: Mon Oct 22 12:31:52 2018 > >>>>> New Revision: 1844550 > >>>>> > >>>>> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev > http://svn.apache.org/viewvc?rev=1844550&view=rev > >>>>> Log: > >>>>> Update vendor for builds > >>>>> > >>>>> Modified: > >>>>> > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > >>>>> > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > >>>>> > >>>>> Modified: > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > >>>>> URL: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff > > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff > >>>>> > ====== > >>>>> --- > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > (original) > >>>>> +++ > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > Mon Oct 22 12:31:52 2018 > >>>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt > >>>>> fi > >>>>> ./configure \ > >>>>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ > >>>>> + --with-vendor="Apache OpenOffice Community Build" \ > >>>>> --enable-verbose \ > >>>>> --with-system-stdlibs \ > >>>>> --enable-crashdump=yes \ > >>>>> > >>>>> Modified: > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > >>>>> URL: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff > > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
Am 22.10.18 um 18:35 schrieb Jim Jagielski: > The thing is, IMO, that these ARE community builds, and, as such, should be > noted as such on the About Page... But I'm fine w/ removing that depending on > what people think. The community is not a vendor. If you leave it out everything is OK: "This product was created by the OpenOffice community." Regards, Matthias > >> On Oct 22, 2018, at 12:32 PM, Matthias Seidel >> wrote: >> >> Am 22.10.18 um 18:13 schrieb Jim Jagielski: >>> It was used for macOS. I was just making it consistent among all my builds. >> Wouldn't it be better to make the macOS build consistent with the other >> builds... ;-) >> >>>> On Oct 22, 2018, at 12:08 PM, Matthias Seidel >>>> wrote: >>>> >>>> Hi Jim, >>>> >>>> --with-vendor="Apache OpenOffice Community Build" \ >>>> >>>> results in weird wording: >>>> >>>> "This product was created by Apache OpenOffice Community Build, based on >>>> Apache OpenOffice" >>>> >>>> And we didn't use --with-vendor for a release build before. >>>> >>>> Regards, >>>> >>>> Matthias >>>> >>>> Am 22.10.18 um 14:31 schrieb j...@apache.org: >>>>> Author: jim >>>>> Date: Mon Oct 22 12:31:52 2018 >>>>> New Revision: 1844550 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev >>>>> Log: >>>>> Update vendor for builds >>>>> >>>>> Modified: >>>>> >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>>> >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>>> >>>>> Modified: >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>>> URL: >>>>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>>>> == >>>>> --- >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>>> (original) >>>>> +++ >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>>> Mon Oct 22 12:31:52 2018 >>>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>>>> fi >>>>> ./configure \ >>>>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>>>> + --with-vendor="Apache OpenOffice Community Build" \ >>>>> --enable-verbose \ >>>>> --with-system-stdlibs \ >>>>> --enable-crashdump=yes \ >>>>> >>>>> Modified: >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>>> URL: >>>>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>>>> == >>>>> --- >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>>> (original) >>>>> +++ >>>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>>> Mon Oct 22 12:31:52 2018 >>>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>>>> fi >>>>> ./configure \ >>>>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>>>> + --with-vendor="Apache OpenOffice Community Build" \ >>>>> --enable-verbose \ >>>>> --with-system-stdlibs \ >>>>> --enable-crashdump=yes \ >>>>> >>>>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
The thing is, IMO, that these ARE community builds, and, as such, should be noted as such on the About Page... But I'm fine w/ removing that depending on what people think. > On Oct 22, 2018, at 12:32 PM, Matthias Seidel > wrote: > > Am 22.10.18 um 18:13 schrieb Jim Jagielski: >> It was used for macOS. I was just making it consistent among all my builds. > > Wouldn't it be better to make the macOS build consistent with the other > builds... ;-) > >>> On Oct 22, 2018, at 12:08 PM, Matthias Seidel >>> wrote: >>> >>> Hi Jim, >>> >>> --with-vendor="Apache OpenOffice Community Build" \ >>> >>> results in weird wording: >>> >>> "This product was created by Apache OpenOffice Community Build, based on >>> Apache OpenOffice" >>> >>> And we didn't use --with-vendor for a release build before. >>> >>> Regards, >>> >>> Matthias >>> >>> Am 22.10.18 um 14:31 schrieb j...@apache.org: >>>> Author: jim >>>> Date: Mon Oct 22 12:31:52 2018 >>>> New Revision: 1844550 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev >>>> Log: >>>> Update vendor for builds >>>> >>>> Modified: >>>> >>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>> >>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>> >>>> Modified: >>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>> URL: >>>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>>> == >>>> --- >>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>> (original) >>>> +++ >>>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>>> Mon Oct 22 12:31:52 2018 >>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>>> fi >>>> ./configure \ >>>>--with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>>> + --with-vendor="Apache OpenOffice Community Build" \ >>>>--enable-verbose \ >>>>--with-system-stdlibs \ >>>>--enable-crashdump=yes \ >>>> >>>> Modified: >>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>> URL: >>>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>>> == >>>> --- >>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>> (original) >>>> +++ >>>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>>> Mon Oct 22 12:31:52 2018 >>>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>>> fi >>>> ./configure \ >>>>--with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>>> + --with-vendor="Apache OpenOffice Community Build" \ >>>>--enable-verbose \ >>>>--with-system-stdlibs \ >>>>--enable-crashdump=yes \ >>>> >>>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
Am 22.10.18 um 18:13 schrieb Jim Jagielski: > It was used for macOS. I was just making it consistent among all my builds. Wouldn't it be better to make the macOS build consistent with the other builds... ;-) >> On Oct 22, 2018, at 12:08 PM, Matthias Seidel >> wrote: >> >> Hi Jim, >> >> --with-vendor="Apache OpenOffice Community Build" \ >> >> results in weird wording: >> >> "This product was created by Apache OpenOffice Community Build, based on >> Apache OpenOffice" >> >> And we didn't use --with-vendor for a release build before. >> >> Regards, >> >>Matthias >> >> Am 22.10.18 um 14:31 schrieb j...@apache.org: >>> Author: jim >>> Date: Mon Oct 22 12:31:52 2018 >>> New Revision: 1844550 >>> >>> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev >>> Log: >>> Update vendor for builds >>> >>> Modified: >>> >>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>> >>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>> >>> Modified: >>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>> URL: >>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>> == >>> --- >>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>> (original) >>> +++ >>> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >>> Mon Oct 22 12:31:52 2018 >>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>> fi >>> ./configure \ >>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>> + --with-vendor="Apache OpenOffice Community Build" \ >>> --enable-verbose \ >>> --with-system-stdlibs \ >>> --enable-crashdump=yes \ >>> >>> Modified: >>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>> URL: >>> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >>> == >>> --- >>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>> (original) >>> +++ >>> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >>> Mon Oct 22 12:31:52 2018 >>> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >>> fi >>> ./configure \ >>> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >>> + --with-vendor="Apache OpenOffice Community Build" \ >>> --enable-verbose \ >>> --with-system-stdlibs \ >>> --enable-crashdump=yes \ >>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
It was used for macOS. I was just making it consistent among all my builds. > On Oct 22, 2018, at 12:08 PM, Matthias Seidel > wrote: > > Hi Jim, > > --with-vendor="Apache OpenOffice Community Build" \ > > results in weird wording: > > "This product was created by Apache OpenOffice Community Build, based on > Apache OpenOffice" > > And we didn't use --with-vendor for a release build before. > > Regards, > >Matthias > > Am 22.10.18 um 14:31 schrieb j...@apache.org: >> Author: jim >> Date: Mon Oct 22 12:31:52 2018 >> New Revision: 1844550 >> >> URL: http://svn.apache.org/viewvc?rev=1844550&view=rev >> Log: >> Update vendor for builds >> >> Modified: >> >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> >> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >> >> Modified: >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> URL: >> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >> == >> --- >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> (original) >> +++ >> openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh >> Mon Oct 22 12:31:52 2018 >> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >> fi >> ./configure \ >> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >> + --with-vendor="Apache OpenOffice Community Build" \ >> --enable-verbose \ >> --with-system-stdlibs \ >> --enable-crashdump=yes \ >> >> Modified: >> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >> URL: >> http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff >> == >> --- >> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >> (original) >> +++ >> openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh >> Mon Oct 22 12:31:52 2018 >> @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt >> fi >> ./configure \ >> --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ >> +--with-vendor="Apache OpenOffice Community Build" \ >> --enable-verbose \ >> --with-system-stdlibs \ >> --enable-crashdump=yes \ >> >> > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1844550 - in /openoffice/devtools/build-scripts/4.1.6: unxlngi6/build_aoo32bit_on_centos5.sh unxlngix6/build_aoo64bit_on_centos5.sh
Hi Jim, --with-vendor="Apache OpenOffice Community Build" \ results in weird wording: "This product was created by Apache OpenOffice Community Build, based on Apache OpenOffice" And we didn't use --with-vendor for a release build before. Regards, Matthias Am 22.10.18 um 14:31 schrieb j...@apache.org: > Author: jim > Date: Mon Oct 22 12:31:52 2018 > New Revision: 1844550 > > URL: http://svn.apache.org/viewvc?rev=1844550&view=rev > Log: > Update vendor for builds > > Modified: > > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > > Modified: > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > URL: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff > == > --- > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > (original) > +++ > openoffice/devtools/build-scripts/4.1.6/unxlngi6/build_aoo32bit_on_centos5.sh > Mon Oct 22 12:31:52 2018 > @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt > fi > ./configure \ > --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ > + --with-vendor="Apache OpenOffice Community Build" \ > --enable-verbose \ > --with-system-stdlibs \ > --enable-crashdump=yes \ > > Modified: > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > URL: > http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh?rev=1844550&r1=1844549&r2=1844550&view=diff > == > --- > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > (original) > +++ > openoffice/devtools/build-scripts/4.1.6/unxlngix6/build_aoo64bit_on_centos5.sh > Mon Oct 22 12:31:52 2018 > @@ -15,6 +15,7 @@ if [ ! -e configure -o configure.in -nt > fi > ./configure \ > --with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \ > + --with-vendor="Apache OpenOffice Community Build" \ > --enable-verbose \ > --with-system-stdlibs \ > --enable-crashdump=yes \ > > smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r1804009 - /openoffice/devtools/build-scripts/4.1.4/unxlngix6/config.log
.. > +PATH: . > +PATH: . > +PATH: . > +PATH: . > +PATH: . > +PATH: . > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/unxlngx6.pro/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/unxlngx6.pro/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/unxlngx6.pro/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/bin > +PATH: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.41.x86_64/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/unxlngx6.pro/bin > +PATH: /home/jim/src/asf/code/aoo-414/main/solenv/bin > +PATH: /usr/java/jdk1.8.0_101/bin > +PATH: /usr > +PATH: /home/jim/bin > +PATH: /usr/local/bin > +PATH: /usr/bin > +PATH: /bin > +PATH: /usr/X11R6/bin > + Should developer specific path environments be in version control or do we all have to change our name to jim ;) Gav… - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[DEVTOOLS] Groovy Integration Road Map
Hi All, Apologies for the long post... Recently I have be proposing, calling votes and implementing various pieces of things related to Java UNO like adding the AOO Java UNO jars and the bootstrap-connector jar to Maven, etc, without really explaining what I'm working toward. The goal is to be able to use the Apache Groovy language for Add-Ons, Add-Ins, Client applications and Macros. The bootstrap-connector that has a current VOTE open is the piece that allows a single Groovy script to bootstrap the office without being compiled with all the special classloader code like a typical Java Client application. After this is released I will bring forward the Groovy UNO Extension [1] for a vote to release via Maven. This isn't an AOO extension but what Groovy calls an extension because it allows you to extend existing API's. The Java UNO API's in this case. It is what makes it possible to write much less code when using Groovy vs Java. The bootstrap-connector is need by this to allow the functional test scripts to bootstrap the office. The final piece of this is being able to use Groovy as a macro language within AOO. There was a previous OO.o extension to add Groovy as a macro language but I don't think it is updated. I plan on creating a new AOO Extension for this after the Groovy UNO Extension is available through Maven. We can later discuss if this should be included in AOO or available separately. [1] https://wiki.openoffice.org/wiki/Groovy_UNO_Extension Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
On 02/08/2016 03:03 PM, Dennis E. Hamilton wrote: I forgot to be explicit. By releasing, I mean in accordance with <http://apache.org/dev/release.html> and <http://apache.org/dev/release-publishing>. This can't be done single-handed, although all the preparation of release candidates could be (in simple cases). It's really up to Carl to pursue this, which I recommend, or go off-project (which would remain an alternative anyhow). - Dennis -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Monday, February 8, 2016 11:46 To: dev@openoffice.apache.org Subject: RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Friday, February 5, 2016 03:56 To: dev@openoffice.apache.org Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository On 02/04/2016 03:48 PM, Dennis E. Hamilton wrote: [ ... ] 1. You could put together a release, using a tagged/branched piece of the AOO SVN sufficient to what you want to do. So there's a persistent source-tree location and r-number that nails it down. 2. Then you could take that much through the release process, being the release manager yourself. It might be awkward the first time, making it beneficial that this is a pretty simple addition. After that effort, and presumably without more than 2 release candidates, the issue will be having a binding +1 majority of at least three to accomplish the release. 3. Being able to obtain a release vote that includes binding voters successfully building from the released source is a little worrisome. My suggestion is to go through (2) regardless, but I am not doing the work [;<). If all technical objections are satisfied, and it is simply a lack of votes, my personal recommendation would be to do a downstream release relying on the release bundle, but having it be dependent on AOO code, as identified, but not being an AOO release. The problem is then how that is that to be identified so there is no confusion with an AOO release. That's a lot of armchair quarter-backing. What are your further thoughts on this, Carl? Bueller? - Dennis Hi Dennis, I understand how the recently released Java UNO jar to Maven needed to coincide with a AOO release due to the source being in AOO source. For devtools like this bootstrap connector and the netbeans- integration plugin, their source is under the devtools dir which is beside AOO trunk and therefore not branched and tagged with AOO I don't believe. For the netbeans plugin submitted to NetBeans.org, past releases by my were discussed on dev@ and then by lazy-concensus proposal. with it's own trunk, branches, and tags directory structure. Could this not be similar? [orcmid] Made me look! Well, being in the AOO SVN but under devtools/ and separate from the AOO trunk/, branches/ and tags/ source trees is perfect. I do think we need to treat releases as releases though, since we're talking about publishing in public, if I understand it, and that is different than work-in-progress and experimentation. I think the Apache Release process should be applied. I see you've been busy there. Is what you are doing aligned with that prospect? I think releasing will also get more attention to this work. If release fails for non-technical but procedural reasons, that is not on you and there are always alternatives in that case. - Dennis Thanks, Carl [ ... ] I should be able to stage the Maven bundle to Nexus this evening an and call for a vote. Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
I forgot to be explicit. By releasing, I mean in accordance with <http://apache.org/dev/release.html> and <http://apache.org/dev/release-publishing>. This can't be done single-handed, although all the preparation of release candidates could be (in simple cases). It's really up to Carl to pursue this, which I recommend, or go off-project (which would remain an alternative anyhow). - Dennis > -Original Message- > From: Dennis E. Hamilton [mailto:orc...@apache.org] > Sent: Monday, February 8, 2016 11:46 > To: dev@openoffice.apache.org > Subject: RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > > -Original Message- > > From: Carl Marcum [mailto:cmar...@apache.org] > > Sent: Friday, February 5, 2016 03:56 > > To: dev@openoffice.apache.org > > Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to > Maven > > Repository > > > > On 02/04/2016 03:48 PM, Dennis E. Hamilton wrote: > [ ... ] > > > 1. You could put together a release, using a tagged/branched piece > > of the AOO SVN sufficient to what you want to do. So there's a > > persistent source-tree location and r-number that nails it down. > > > > > > 2. Then you could take that much through the release process, > being > > the release manager yourself. It might be awkward the first time, > > making it beneficial that this is a pretty simple addition. After > that > > effort, and presumably without more than 2 release candidates, the > issue > > will be having a binding +1 majority of at least three to accomplish > the > > release. > > > > > > 3. Being able to obtain a release vote that includes binding > voters > > successfully building from the released source is a little worrisome. > > My suggestion is to go through (2) regardless, but I am not doing the > > work [;<). If all technical objections are satisfied, and it is > simply > > a lack of votes, my personal recommendation would be to do a > downstream > > release relying on the release bundle, but having it be dependent on > AOO > > code, as identified, but not being an AOO release. The problem is > then > > how that is that to be identified so there is no confusion with an AOO > > release. > > > > > > That's a lot of armchair quarter-backing. > > > > > > What are your further thoughts on this, Carl? Bueller? > > > > > > - Dennis > > > > Hi Dennis, > > > > I understand how the recently released Java UNO jar to Maven needed to > > coincide with a AOO release due to the source being in AOO source. > > > > For devtools like this bootstrap connector and the netbeans- > integration > > plugin, their source is under the devtools dir which is beside AOO > trunk > > and therefore not branched and tagged with AOO I don't believe. > > > > For the netbeans plugin submitted to NetBeans.org, past releases by my > > were discussed on dev@ and then by lazy-concensus proposal. with it's > > own trunk, branches, and tags directory structure. > > > > Could this not be similar? > > > [orcmid] > > Made me look! > > Well, being in the AOO SVN but under devtools/ and separate from the AOO > trunk/, branches/ and tags/ source trees is perfect. > > I do think we need to treat releases as releases though, since we're > talking about publishing in public, if I understand it, and that is > different than work-in-progress and experimentation. > > I think the Apache Release process should be applied. > > I see you've been busy there. Is what you are doing aligned with that > prospect? > > I think releasing will also get more attention to this work. > > If release fails for non-technical but procedural reasons, that is not > on you and there are always alternatives in that case. > > - Dennis > > > Thanks, > > Carl > > > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
> -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Friday, February 5, 2016 03:56 > To: dev@openoffice.apache.org > Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > On 02/04/2016 03:48 PM, Dennis E. Hamilton wrote: [ ... ] > > 1. You could put together a release, using a tagged/branched piece > of the AOO SVN sufficient to what you want to do. So there's a > persistent source-tree location and r-number that nails it down. > > > > 2. Then you could take that much through the release process, being > the release manager yourself. It might be awkward the first time, > making it beneficial that this is a pretty simple addition. After that > effort, and presumably without more than 2 release candidates, the issue > will be having a binding +1 majority of at least three to accomplish the > release. > > > > 3. Being able to obtain a release vote that includes binding voters > successfully building from the released source is a little worrisome. > My suggestion is to go through (2) regardless, but I am not doing the > work [;<). If all technical objections are satisfied, and it is simply > a lack of votes, my personal recommendation would be to do a downstream > release relying on the release bundle, but having it be dependent on AOO > code, as identified, but not being an AOO release. The problem is then > how that is that to be identified so there is no confusion with an AOO > release. > > > > That's a lot of armchair quarter-backing. > > > > What are your further thoughts on this, Carl? Bueller? > > > > - Dennis > > Hi Dennis, > > I understand how the recently released Java UNO jar to Maven needed to > coincide with a AOO release due to the source being in AOO source. > > For devtools like this bootstrap connector and the netbeans-integration > plugin, their source is under the devtools dir which is beside AOO trunk > and therefore not branched and tagged with AOO I don't believe. > > For the netbeans plugin submitted to NetBeans.org, past releases by my > were discussed on dev@ and then by lazy-concensus proposal. with it's > own trunk, branches, and tags directory structure. > > Could this not be similar? > [orcmid] Made me look! Well, being in the AOO SVN but under devtools/ and separate from the AOO trunk/, branches/ and tags/ source trees is perfect. I do think we need to treat releases as releases though, since we're talking about publishing in public, if I understand it, and that is different than work-in-progress and experimentation. I think the Apache Release process should be applied. I see you've been busy there. Is what you are doing aligned with that prospect? I think releasing will also get more attention to this work. If release fails for non-technical but procedural reasons, that is not on you and there are always alternatives in that case. - Dennis > Thanks, > Carl > [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
On 02/04/2016 03:48 PM, Dennis E. Hamilton wrote: Summary: 1. I think the use of the openoffice "class path" and packaging that is already accepted for use be continued, rather than disturb the Java and maven identifiers that people are already using and expect. 2. Creating a distribution is complicated by the absence of a new Apache OpenOffice release that would include the code and other materials that go with this. This would tend to require a special release for just this. So, for (2), there is more to consider. Notes below. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Saturday, January 30, 2016 13:39 To: dev@openoffice.apache.org Subject: RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Saturday, January 30, 2016 12:09 To: dev@openoffice.apache.org Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository Hi Dennis, comments below.. On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: [ ... ] I am copying the PMC on this and requesting that all discussion be here, and not there, so all committers and interested parties can contribute to the discussion. We would also need to know that at least 3 PMC members are prepared to carry out what is required for casting a binding release vote. While we wrestle with this, I request that you suspend the Groovy UNO Extension discussion for now and we continue this for the simple case of the Java Bootstrap Connector. I am assuming that this is the simpler case to work through a release process if we determine that we need to do so. - Dennis [cmarcum] No problem. I suspended the Groovy UNO extension proposal. My hope was to do this through the project but I understand the procedures and how this could cause more work for others than necessary since it's only a small developer tool and not a primary project artifact. I am more than willing to submit this individually if it makes more sense. In a larger sense this conversation could also apply to the future builds of the AOO-Netbeans plugin that is made available through NetBeans.org. Best regards, Carl [orcmid] Thanks Carl. Let's wait a few days for others to chime in. I would like to see this as a project release rather than a personal one based on AOO code, especially since I think everything needed is in the AOO code base. The bigger issue is the kind of review that is required, and the extra effort in preparing a release candidate, etc. I also think that you are creating a good model and process for spin- outs of useful components from the AOO code base. So this is worth digging into for that reason alone. - Dennis [orcmid] Carl, First, we do make distributions that are based on an AOO source release and that use the source in selective ways. The making of language packs is an example of one special distribution. The one you made for Java uno tools is another. Secondly, there are downstream distributions that are also made. In notable cases, we are aware of them because they contribute patches to our source base and then make their distribution from our source release. I think FreeBSD is such a case, and the Solaris and OS2 distributions are as well. I suspect that there may still be downstream build variants in France. I don't know how or whether those use non-released source and how they tie to AOO release versions, or not. So we are left with the situation of there being no simple mechanism, such as regular maintenance releases that have your additions incorporated so the Maven distributions can be tied to the released AOO version. Here's the conundrum: 1. You could put together a release, using a tagged/branched piece of the AOO SVN sufficient to what you want to do. So there's a persistent source-tree location and r-number that nails it down. 2. Then you could take that much through the release process, being the release manager yourself. It might be awkward the first time, making it beneficial that this is a pretty simple addition. After that effort, and presumably without more than 2 release candidates, the issue will be having a binding +1 majority of at least three to accomplish the release. 3. Being able to obtain a release vote that includes binding voters successfully building from the released source is a little worrisome. My suggestion is to go through (2) regardless, but I am not doing the work [;<). If all technical objections are satisfied, and it is simply a lack of votes, my personal recommendation would be to do a downstream release relying on the release bundle, but having it be dependent on AOO code, as identified, but not being an AOO release. The problem is then how that is that to be identified so there is no confusion with an AOO release. That's a lot of armch
RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
Summary: 1. I think the use of the openoffice "class path" and packaging that is already accepted for use be continued, rather than disturb the Java and maven identifiers that people are already using and expect. 2. Creating a distribution is complicated by the absence of a new Apache OpenOffice release that would include the code and other materials that go with this. This would tend to require a special release for just this. So, for (2), there is more to consider. Notes below. - Dennis > -Original Message- > From: Dennis E. Hamilton [mailto:orc...@apache.org] > Sent: Saturday, January 30, 2016 13:39 > To: dev@openoffice.apache.org > Subject: RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > > -Original Message- > > From: Carl Marcum [mailto:cmar...@apache.org] > > Sent: Saturday, January 30, 2016 12:09 > > To: dev@openoffice.apache.org > > Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to > Maven > > Repository > > > > Hi Dennis, > > > > comments below.. > > > > On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: > [ ... ] > > > I am copying the PMC on this and requesting that all discussion be > > here, and not there, so all committers and interested parties can > > contribute to the discussion. We would also need to know that at > least > > 3 PMC members are prepared to carry out what is required for casting a > > binding release vote. > > > > > > While we wrestle with this, I request that you suspend the Groovy > UNO > > Extension discussion for now and we continue this for the simple case > of > > the Java Bootstrap Connector. I am assuming that this is the simpler > > case to work through a release process if we determine that we need to > > do so. > > > > > > - Dennis > > > > [cmarcum] > > > > No problem. > > I suspended the Groovy UNO extension proposal. > > > > My hope was to do this through the project but I understand the > > procedures and how this could cause more work for others than > necessary > > since it's only a small developer tool and not a primary project > > artifact. > > > > I am more than willing to submit this individually if it makes more > > sense. > > > > In a larger sense this conversation could also apply to the future > > builds of the AOO-Netbeans plugin that is made available through > > NetBeans.org. > > > > Best regards, > > Carl > [orcmid] > > Thanks Carl. Let's wait a few days for others to chime in. > > I would like to see this as a project release rather than a personal one > based on AOO code, especially since I think everything needed is in the > AOO code base. > > The bigger issue is the kind of review that is required, and the extra > effort in preparing a release candidate, etc. > > I also think that you are creating a good model and process for spin- > outs of useful components from the AOO code base. So this is worth > digging into for that reason alone. > > - Dennis [orcmid] Carl, First, we do make distributions that are based on an AOO source release and that use the source in selective ways. The making of language packs is an example of one special distribution. The one you made for Java uno tools is another. Secondly, there are downstream distributions that are also made. In notable cases, we are aware of them because they contribute patches to our source base and then make their distribution from our source release. I think FreeBSD is such a case, and the Solaris and OS2 distributions are as well. I suspect that there may still be downstream build variants in France. I don't know how or whether those use non-released source and how they tie to AOO release versions, or not. So we are left with the situation of there being no simple mechanism, such as regular maintenance releases that have your additions incorporated so the Maven distributions can be tied to the released AOO version. Here's the conundrum: 1. You could put together a release, using a tagged/branched piece of the AOO SVN sufficient to what you want to do. So there's a persistent source-tree location and r-number that nails it down. 2. Then you could take that much through the release process, being the release manager yourself. It might be awkward the first time, making it beneficial that this is a pretty simple addition. After that effort, and presumably without more than 2 release candidates, the issue will be having a binding +1 majority of at least three to accomplish the release. 3. Being able to obtain a release vote that includes binding voters successfull
Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
I think the artifacts should be org.apache.openoffice. Artifacts using org.openoffice are not likely to be within policy, but if issued would also be understood to be from this project. A proper release is required including the source for these jars. Vote is 3 +1 from PMC and a majority. Convention is that -1 is taken seriously if it has true technical merit. Regards, Dave Sent from my iPhone On Jan 30, 2016, at 1:39 PM, Dennis E. Hamilton wrote: >> -Original Message- >> From: Carl Marcum [mailto:cmar...@apache.org] >> Sent: Saturday, January 30, 2016 12:09 >> To: dev@openoffice.apache.org >> Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven >> Repository >> >> Hi Dennis, >> >> comments below.. >> >> On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: > [ ... ] >>> I am copying the PMC on this and requesting that all discussion be >> here, and not there, so all committers and interested parties can >> contribute to the discussion. We would also need to know that at least >> 3 PMC members are prepared to carry out what is required for casting a >> binding release vote. >>> >>> While we wrestle with this, I request that you suspend the Groovy UNO >> Extension discussion for now and we continue this for the simple case of >> the Java Bootstrap Connector. I am assuming that this is the simpler >> case to work through a release process if we determine that we need to >> do so. >>> >>> - Dennis >> >> [cmarcum] >> >> No problem. >> I suspended the Groovy UNO extension proposal. >> >> My hope was to do this through the project but I understand the >> procedures and how this could cause more work for others than necessary >> since it's only a small developer tool and not a primary project >> artifact. >> >> I am more than willing to submit this individually if it makes more >> sense. >> >> In a larger sense this conversation could also apply to the future >> builds of the AOO-Netbeans plugin that is made available through >> NetBeans.org. >> >> Best regards, >> Carl > [orcmid] > > Thanks Carl. Let's wait a few days for others to chime in. > > I would like to see this as a project release rather than a personal one > based on AOO code, especially since I think everything needed is in the AOO > code base. > > The bigger issue is the kind of review that is required, and the extra effort > in preparing a release candidate, etc. > > I also think that you are creating a good model and process for spin-outs of > useful components from the AOO code base. So this is worth digging into for > that reason alone. > > - Dennis > > >> >>>> -Original Message- >>>> From: Carl Marcum [mailto:cmar...@apache.org] >>>> Sent: Saturday, January 30, 2016 06:42 >>>> To: dev@openoffice.apache.org >>>> Subject: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven >>>> Repository >>>> >>>> Hi All, >>>> >>>> I would like to create Maven bundles of the source, classes, and >> javadoc >>>> of the recently added BootstrapConnector [1] and stage them on the >>>> Apache Nexus Maven Repository using groupId "org.openoffice" so this >>>> would be from the project. >>>> >>>> If the project consensus is that a VOTE is necessary I will call for >> one >>>> after staging and prior to publishing, or if not, I will do another >>>> PROPOSAL for release. >>>> >>>> This jar allows bootstrapping the office by passing a string >>>> representing the path to the office executable to the bootstrap >> method. >>>> >>>> This code has been available for download from the Forum since 2008 >> [2]. >>>> >>>> I have obtained permission from the author to use the code by our >>>> project and under the AL 2.0 license and documented it with the AOO >> PMC. >>>> >>>> If there are no objections to the above proposal by midnight GMT >>>> Wednesday February 3rd, then I will invoke Lazy Consensus and >> proceed >>>> to implement the above proposal. >>>> >>>> Another option to this is that I publish them as an individual with a >>>> different groupId if this is preferred. >>>> >>>> [1] >>>> https://svn.a
RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
> -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Saturday, January 30, 2016 12:09 > To: dev@openoffice.apache.org > Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > Hi Dennis, > > comments below.. > > On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: [ ... ] > > I am copying the PMC on this and requesting that all discussion be > here, and not there, so all committers and interested parties can > contribute to the discussion. We would also need to know that at least > 3 PMC members are prepared to carry out what is required for casting a > binding release vote. > > > > While we wrestle with this, I request that you suspend the Groovy UNO > Extension discussion for now and we continue this for the simple case of > the Java Bootstrap Connector. I am assuming that this is the simpler > case to work through a release process if we determine that we need to > do so. > > > > - Dennis > > [cmarcum] > > No problem. > I suspended the Groovy UNO extension proposal. > > My hope was to do this through the project but I understand the > procedures and how this could cause more work for others than necessary > since it's only a small developer tool and not a primary project > artifact. > > I am more than willing to submit this individually if it makes more > sense. > > In a larger sense this conversation could also apply to the future > builds of the AOO-Netbeans plugin that is made available through > NetBeans.org. > > Best regards, > Carl [orcmid] Thanks Carl. Let's wait a few days for others to chime in. I would like to see this as a project release rather than a personal one based on AOO code, especially since I think everything needed is in the AOO code base. The bigger issue is the kind of review that is required, and the extra effort in preparing a release candidate, etc. I also think that you are creating a good model and process for spin-outs of useful components from the AOO code base. So this is worth digging into for that reason alone. - Dennis > > >> -Original Message- > >> From: Carl Marcum [mailto:cmar...@apache.org] > >> Sent: Saturday, January 30, 2016 06:42 > >> To: dev@openoffice.apache.org > >> Subject: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > >> Repository > >> > >> Hi All, > >> > >> I would like to create Maven bundles of the source, classes, and > javadoc > >> of the recently added BootstrapConnector [1] and stage them on the > >> Apache Nexus Maven Repository using groupId "org.openoffice" so this > >> would be from the project. > >> > >> If the project consensus is that a VOTE is necessary I will call for > one > >> after staging and prior to publishing, or if not, I will do another > >> PROPOSAL for release. > >> > >> This jar allows bootstrapping the office by passing a string > >> representing the path to the office executable to the bootstrap > method. > >> > >> This code has been available for download from the Forum since 2008 > [2]. > >> > >> I have obtained permission from the author to use the code by our > >> project and under the AL 2.0 license and documented it with the AOO > PMC. > >> > >> If there are no objections to the above proposal by midnight GMT > >> Wednesday February 3rd, then I will invoke Lazy Consensus and > proceed > >> to implement the above proposal. > >> > >> Another option to this is that I publish them as an individual with a > >> different groupId if this is preferred. > >> > >> [1] > >> https://svn.apache.org/repos/asf/openoffice/devtools/bootstrap- > >> connector/trunk/ > >> > >> [2] https://forum.openoffice.org/en/forum/viewtopic.php?t=2520 > >> > >> Thanks, > >> Carl > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
Hi Dennis, comments below.. On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: [BCC AOO PMC] Carl, I notice that you are running two concurrent proposals. Personally, I am conflicted about this. I think this is admirable and worthy work. However, it is going to Maven as effectively a distribution from the project, and that implies an associated release. At the same time, we really want this to be a low-friction process. The lurking question is, what is the minimum that needs to be done to satisfy the ASF-important ceremonial requirements. See <http://apache.org/dev/release.html>. I'm told there are projects where the PMCs use lazy consensus. AOO has never been one of them and the existing policies and practices do introduce a level of formality for what are AOO releases. If we were to conduct a release vote, it would be necessary to have a majority of binding +1 votes by a margin of 3. That means basically that there is enough information for folks to independently review the source and confirm that the specified build process works. That also means, by the way, that there is a source-only release packaging with no included jars, etc., that there are external digests and digital signatures by the release manager (i.e., you), and there staging somewhere as a release candidate. I am copying the PMC on this and requesting that all discussion be here, and not there, so all committers and interested parties can contribute to the discussion. We would also need to know that at least 3 PMC members are prepared to carry out what is required for casting a binding release vote. While we wrestle with this, I request that you suspend the Groovy UNO Extension discussion for now and we continue this for the simple case of the Java Bootstrap Connector. I am assuming that this is the simpler case to work through a release process if we determine that we need to do so. - Dennis [cmarcum] No problem. I suspended the Groovy UNO extension proposal. My hope was to do this through the project but I understand the procedures and how this could cause more work for others than necessary since it's only a small developer tool and not a primary project artifact. I am more than willing to submit this individually if it makes more sense. In a larger sense this conversation could also apply to the future builds of the AOO-Netbeans plugin that is made available through NetBeans.org. Best regards, Carl -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Saturday, January 30, 2016 06:42 To: dev@openoffice.apache.org Subject: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository Hi All, I would like to create Maven bundles of the source, classes, and javadoc of the recently added BootstrapConnector [1] and stage them on the Apache Nexus Maven Repository using groupId "org.openoffice" so this would be from the project. If the project consensus is that a VOTE is necessary I will call for one after staging and prior to publishing, or if not, I will do another PROPOSAL for release. This jar allows bootstrapping the office by passing a string representing the path to the office executable to the bootstrap method. This code has been available for download from the Forum since 2008 [2]. I have obtained permission from the author to use the code by our project and under the AL 2.0 license and documented it with the AOO PMC. If there are no objections to the above proposal by midnight GMT Wednesday February 3rd, then I will invoke Lazy Consensus and proceed to implement the above proposal. Another option to this is that I publish them as an individual with a different groupId if this is preferred. [1] https://svn.apache.org/repos/asf/openoffice/devtools/bootstrap- connector/trunk/ [2] https://forum.openoffice.org/en/forum/viewtopic.php?t=2520 Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL][DEVTOOLS] Stage the Groovy UNO Extension to Maven Repository
** I am suspending this proposal and will resubmit at a later date if needed ** Thanks, Carl On 01/30/2016 09:43 AM, Carl Marcum wrote: Hi All, I would like to create Maven bundles of the source, classes, and javadoc of the Groovy UNO Extension [1] and stage them on the Apache Nexus Maven Repository using groupId "org.openoffice" so this would be from the project. If the project consensus is that a VOTE is necessary I will call for one after staging and prior to publishing, or if not, I will do another PROPOSAL for release. There is still a lot of work that will be done on this tool but it is useful now as described in the wiki page [2]. There will be a lot of updates in the coming months. If there are no objections to the above proposal by midnight GMT Wednesday February 3rd, then I will invoke Lazy Consensus and proceed to implement the above proposal. Following this I will update the wiki page to describe the steps to reproduce future updates. Another option to this is that I publish them as an individual with a different groupId if this is preferred. [1] https://svn.apache.org/repos/asf/openoffice/devtools/guno-extension [2] https://wiki.openoffice.org/wiki/Groovy_UNO_Extension Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
[BCC AOO PMC] Carl, I notice that you are running two concurrent proposals. Personally, I am conflicted about this. I think this is admirable and worthy work. However, it is going to Maven as effectively a distribution from the project, and that implies an associated release. At the same time, we really want this to be a low-friction process. The lurking question is, what is the minimum that needs to be done to satisfy the ASF-important ceremonial requirements. See <http://apache.org/dev/release.html>. I'm told there are projects where the PMCs use lazy consensus. AOO has never been one of them and the existing policies and practices do introduce a level of formality for what are AOO releases. If we were to conduct a release vote, it would be necessary to have a majority of binding +1 votes by a margin of 3. That means basically that there is enough information for folks to independently review the source and confirm that the specified build process works. That also means, by the way, that there is a source-only release packaging with no included jars, etc., that there are external digests and digital signatures by the release manager (i.e., you), and there staging somewhere as a release candidate. I am copying the PMC on this and requesting that all discussion be here, and not there, so all committers and interested parties can contribute to the discussion. We would also need to know that at least 3 PMC members are prepared to carry out what is required for casting a binding release vote. While we wrestle with this, I request that you suspend the Groovy UNO Extension discussion for now and we continue this for the simple case of the Java Bootstrap Connector. I am assuming that this is the simpler case to work through a release process if we determine that we need to do so. - Dennis > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Saturday, January 30, 2016 06:42 > To: dev@openoffice.apache.org > Subject: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > Hi All, > > I would like to create Maven bundles of the source, classes, and javadoc > of the recently added BootstrapConnector [1] and stage them on the > Apache Nexus Maven Repository using groupId "org.openoffice" so this > would be from the project. > > If the project consensus is that a VOTE is necessary I will call for one > after staging and prior to publishing, or if not, I will do another > PROPOSAL for release. > > This jar allows bootstrapping the office by passing a string > representing the path to the office executable to the bootstrap method. > > This code has been available for download from the Forum since 2008 [2]. > > I have obtained permission from the author to use the code by our > project and under the AL 2.0 license and documented it with the AOO PMC. > > If there are no objections to the above proposal by midnight GMT > Wednesday February 3rd, then I will invoke Lazy Consensus and proceed > to implement the above proposal. > > Another option to this is that I publish them as an individual with a > different groupId if this is preferred. > > [1] > https://svn.apache.org/repos/asf/openoffice/devtools/bootstrap- > connector/trunk/ > > [2] https://forum.openoffice.org/en/forum/viewtopic.php?t=2520 > > Thanks, > Carl > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven Repository
Hi All, I would like to create Maven bundles of the source, classes, and javadoc of the recently added BootstrapConnector [1] and stage them on the Apache Nexus Maven Repository using groupId "org.openoffice" so this would be from the project. If the project consensus is that a VOTE is necessary I will call for one after staging and prior to publishing, or if not, I will do another PROPOSAL for release. This jar allows bootstrapping the office by passing a string representing the path to the office executable to the bootstrap method. This code has been available for download from the Forum since 2008 [2]. I have obtained permission from the author to use the code by our project and under the AL 2.0 license and documented it with the AOO PMC. If there are no objections to the above proposal by midnight GMT Wednesday February 3rd, then I will invoke Lazy Consensus and proceed to implement the above proposal. Another option to this is that I publish them as an individual with a different groupId if this is preferred. [1] https://svn.apache.org/repos/asf/openoffice/devtools/bootstrap-connector/trunk/ [2] https://forum.openoffice.org/en/forum/viewtopic.php?t=2520 Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PROPOSAL][DEVTOOLS] Stage the Groovy UNO Extension to Maven Repository
Hi All, I would like to create Maven bundles of the source, classes, and javadoc of the Groovy UNO Extension [1] and stage them on the Apache Nexus Maven Repository using groupId "org.openoffice" so this would be from the project. If the project consensus is that a VOTE is necessary I will call for one after staging and prior to publishing, or if not, I will do another PROPOSAL for release. There is still a lot of work that will be done on this tool but it is useful now as described in the wiki page [2]. There will be a lot of updates in the coming months. If there are no objections to the above proposal by midnight GMT Wednesday February 3rd, then I will invoke Lazy Consensus and proceed to implement the above proposal. Following this I will update the wiki page to describe the steps to reproduce future updates. Another option to this is that I publish them as an individual with a different groupId if this is preferred. [1] https://svn.apache.org/repos/asf/openoffice/devtools/guno-extension [2] https://wiki.openoffice.org/wiki/Groovy_UNO_Extension Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[DEVTOOLS] Gradle Integration and Groovy UNO Extension
Hi All, I have committed my initial work on a Groovy UNO Extension [1] I added a wiki page to document it [2] Initial work has been on adding convenience methods for spreadsheets. Future work will include the other applications as needed. I also committed a Gradle Integration project [3] And a wiki page for it as well [4] This project is for creating Gradle build based UNO application layouts from templates using Lazybones. The first template completed is for a UNO Client Application that can use Groovy and Java sources and takes advantage of the recently available Java UNO jars from Maven and the previously mentioned Groovy UNO Extension is used locally until it can be released on Maven also. I created a bugzilla issue [5] to track the development work on these. [1] https://svn.apache.org/repos/asf/openoffice/devtools/guno-extension [2] https://wiki.openoffice.org/wiki/Groovy_UNO_Extension [3] https://svn.apache.org/repos/asf/openoffice/devtools/lazybones-templates [4] https://wiki.openoffice.org/wiki/OpenOffice_Gradle_Integration [5] https://bz.apache.org/ooo/show_bug.cgi?id=126770 Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] NetBeans plugin update for NB 8.1
On 12/05/2015 03:22 PM, Rory O'Farrell wrote: On Fri, 04 Dec 2015 18:55:38 -0500 Carl Marcum wrote: Hi All, The NetBeans integration plugin has been updated and verified by the NetBeans team for NB 8.1. It is available for download from NetBeans.org here [1] or through the NetBeans Update Center. For reference this is plugin version 4.1.4 for NB 8.1. The last version for NB 8.0 is plugin version 4.1.3. This update was required for NB api module changes. [1] http://plugins.netbeans.org/plugin/57917/apache-openoffice-api-plugin Thanks, Carl Thank you for the update, Carl. It has fixed several problems with the compilation and installation of some code fir an OO extension I am working on (read: trying vainly to understand!) which didn't migrate well from Netbeans 8.0.2 Thanks for the feedback Rory, I'm never sure how many people besides me use it, but I try to do what little I can. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] NetBeans plugin update for NB 8.1
On Fri, 04 Dec 2015 18:55:38 -0500 Carl Marcum wrote: > Hi All, > > The NetBeans integration plugin has been updated and verified by the > NetBeans team for NB 8.1. > > It is available for download from NetBeans.org here [1] or through the > NetBeans Update Center. > > For reference this is plugin version 4.1.4 for NB 8.1. > The last version for NB 8.0 is plugin version 4.1.3. > > This update was required for NB api module changes. > > [1] http://plugins.netbeans.org/plugin/57917/apache-openoffice-api-plugin > > Thanks, > Carl > Thank you for the update, Carl. It has fixed several problems with the compilation and installation of some code fir an OO extension I am working on (read: trying vainly to understand!) which didn't migrate well from Netbeans 8.0.2 -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[DEVTOOLS] NetBeans plugin update for NB 8.1
Hi All, The NetBeans integration plugin has been updated and verified by the NetBeans team for NB 8.1. It is available for download from NetBeans.org here [1] or through the NetBeans Update Center. For reference this is plugin version 4.1.4 for NB 8.1. The last version for NB 8.0 is plugin version 4.1.3. This update was required for NB api module changes. [1] http://plugins.netbeans.org/plugin/57917/apache-openoffice-api-plugin Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS][EXT] Update to Netbeans plugin
On 03/15/2015 12:33 PM, W. Amenel VOGLOZIN wrote: Hi Carl, I have tried (yesterday) the 4.1.0 version of the plugin (update from 4.0.6) to rebuild an extension I wrote last summer in Java. It has worked fine and I haven't encountered any problems or unexpected behavior. Platform: * Netbeans 8.0.2 Patch 1 * Windows 8.1 64-bit edition * Java 1.8.0_40 (32-bit) * OpenOffice 4.1.1 Note however that I have been building my extension, which relies on Jackson jars, with version 4.0.6 of the Netbeans plugin, without a problem. That version (4.0.6) had been posted to this very mailing list by Jürgen mid-June 2014. The jars were embedded in the oxt file without any actions on my part. I was expecting to do something, for instance add some references to files to include somewhere but I never had to. That was a pleasant surprise, which I believe prompted me back then (June, July or August), to update a page on the OO Wiki to add some information about what to do in order to have dependencies embedded in oxt files. Anyway, what I mean is that the problem (of external jars not being available in the build artifact) that you reported in an e-mail from October 2014, well, it didn't occur in my case. Thanks, -Amenel. De : Carl Marcum À : a...@openoffice.apache.org; "dev@openoffice.apache.org" Envoyé le : Mardi 10 mars 2015 11h07 Objet : Re: [DEVTOOLS][EXT] Update to Netbeans plugin On 12/10/2014 09:10 PM, Carl Marcum wrote: Hi All, I ran into an issue when trying to create an UNO client application with the Netbeans plugin. External library jars were not added to dist/lib or the jar manifest during build. This problem appeared to be related to this issue [1]. I have added the following to UNOClientAppProject template build-uno-impl.xml jar target that overrides jar target in build-impl.xml -do-jar-without-libraries,-do-jar-with-libraries This adds library jars to /dist/lib and also Class Path entries in jar manifest for client applications. Existing projects created prior should be able to change the jar target to include them. Line 27 in nbproject/build-uno-impl.xml I have updated the plugin to version 4.1.0 to better reflect the AOO SDK version compatibility. A compiled version can be found here [2] [1] http://issues.apache.org/ooo/show_bug.cgi?id=78645 [2] http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.1.0.nbm - To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org For additional commands, e-mail: api-h...@openoffice.apache.org Has anyone tried this update with an UNO client app or otherwise? If so, on what platform? Thanks, Carl Amenel, Thank you for the reply, Your feedback is very helpful. I hope someone can also verify the UNO Client now also adds external jars to the dist/lib folder and adds an entry to the MANIFEST.MF file in the jar as expected. Thanks again, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS][EXT] Update to Netbeans plugin
Hi Carl,
I have tried (yesterday) the 4.1.0 version of the plugin (update from 4.0.6) to
rebuild an extension I wrote last summer in Java. It has worked fine and I
haven't encountered any problems or unexpected behavior.
Platform:
* Netbeans 8.0.2 Patch 1
* Windows 8.1 64-bit edition
* Java 1.8.0_40 (32-bit)
* OpenOffice 4.1.1
Note however that I have been building my extension, which relies on Jackson
jars, with version 4.0.6 of the Netbeans plugin, without a problem. That
version (4.0.6) had been posted to this very mailing list by Jürgen mid-June
2014. The jars were embedded in the oxt file without any actions on my part. I
was expecting to do something, for instance add some references to files to
include somewhere but I never had to. That was a pleasant surprise, which I
believe prompted me back then (June, July or August), to update a page on the
OO Wiki to add some information about what to do in order to have dependencies
embedded in oxt files.
Anyway, what I mean is that the problem (of external jars not being available
in the build artifact) that you reported in an e-mail from October 2014, well,
it didn't occur in my case.
Thanks,
-Amenel.
De : Carl Marcum
À : a...@openoffice.apache.org; "dev@openoffice.apache.org"
Envoyé le : Mardi 10 mars 2015 11h07
Objet : Re: [DEVTOOLS][EXT] Update to Netbeans plugin
On 12/10/2014 09:10 PM, Carl Marcum wrote:
> Hi All,
>
> I ran into an issue when trying to create an UNO client application
> with the Netbeans plugin.
>
> External library jars were not added to dist/lib or the jar manifest
> during build.
>
> This problem appeared to be related to this issue [1].
>
> I have added the following to UNOClientAppProject template
> build-uno-impl.xml jar target that overrides jar target in build-impl.xml
> -do-jar-without-libraries,-do-jar-with-libraries
> This adds library jars to /dist/lib and also Class Path entries in jar
> manifest for client applications.
>
> Existing projects created prior should be able to change the jar
> target to include them.
> Line 27 in nbproject/build-uno-impl.xml
> depends="-uno-project-init,compile,-pre-jar,-do-jar-jar,-do-jar-without-libraries,-do-jar-with-libraries,-do-openoffice-manifest,-post-jar">
> manifest="${build.dir}/MANIFEST.MF" filesonly="true" compress="true"
> jarfile="${dist.jar}">
>
>
>
>
> I have updated the plugin to version 4.1.0 to better reflect the AOO
> SDK version compatibility.
>
> A compiled version can be found here [2]
>
> [1] http://issues.apache.org/ooo/show_bug.cgi?id=78645
> [2]
> http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.1.0.nbm
>
>
> -
> To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: api-h...@openoffice.apache.org
>
Has anyone tried this update with an UNO client app or otherwise?
If so, on what platform?
Thanks,
Carl
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
Re: [DEVTOOLS][EXT] Update to Netbeans plugin
On 12/10/2014 09:10 PM, Carl Marcum wrote:
Hi All,
I ran into an issue when trying to create an UNO client application
with the Netbeans plugin.
External library jars were not added to dist/lib or the jar manifest
during build.
This problem appeared to be related to this issue [1].
I have added the following to UNOClientAppProject template
build-uno-impl.xml jar target that overrides jar target in build-impl.xml
-do-jar-without-libraries,-do-jar-with-libraries
This adds library jars to /dist/lib and also Class Path entries in jar
manifest for client applications.
Existing projects created prior should be able to change the jar
target to include them.
Line 27 in nbproject/build-uno-impl.xml
depends="-uno-project-init,compile,-pre-jar,-do-jar-jar,-do-jar-without-libraries,-do-jar-with-libraries,-do-openoffice-manifest,-post-jar">
manifest="${build.dir}/MANIFEST.MF" filesonly="true" compress="true"
jarfile="${dist.jar}">
I have updated the plugin to version 4.1.0 to better reflect the AOO
SDK version compatibility.
A compiled version can be found here [2]
[1] http://issues.apache.org/ooo/show_bug.cgi?id=78645
[2]
http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.1.0.nbm
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
Has anyone tried this update with an UNO client app or otherwise?
If so, on what platform?
Thanks,
Carl
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
[DEVTOOLS][EXT] Update to Netbeans plugin
Hi All,
I ran into an issue when trying to create an UNO client application with
the Netbeans plugin.
External library jars were not added to dist/lib or the jar manifest
during build.
This problem appeared to be related to this issue [1].
I have added the following to UNOClientAppProject template
build-uno-impl.xml jar target that overrides jar target in build-impl.xml
-do-jar-without-libraries,-do-jar-with-libraries
This adds library jars to /dist/lib and also Class Path entries in jar
manifest for client applications.
Existing projects created prior should be able to change the jar target
to include them.
Line 27 in nbproject/build-uno-impl.xml
depends="-uno-project-init,compile,-pre-jar,-do-jar-jar,-do-jar-without-libraries,-do-jar-with-libraries,-do-openoffice-manifest,-post-jar">
manifest="${build.dir}/MANIFEST.MF" filesonly="true" compress="true"
jarfile="${dist.jar}">
I have updated the plugin to version 4.1.0 to better reflect the AOO SDK
version compatibility.
A compiled version can be found here [2]
[1] http://issues.apache.org/ooo/show_bug.cgi?id=78645
[2]
http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.1.0.nbm
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] Updating Netbeans plugin for 3 layer removal
On 09/22/2013 07:41 PM, Carl Marcum wrote: Hi all, Just to update, I have documented my work on the Netbeans plugin related to 3-Layer removal changes here: https://issues.apache.org/ooo/show_bug.cgi?id=123266 I seem to have the plugin working on Netbeans 7.2 and AOO 4.0.0 at least for linux (tested on Fedora 17 x86-64). I have tested a simple AddOn for Writer, AddIn for Calc, and a Client Application. It's possible more work is needed for Mac and Windows. I have upload an updated NBM file to: http://people.apache.org/~cmarcum/devtools/ select org-openoffice-extensions-4.0.5.alpha.nbm Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Has anyone tried to use this update? Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] Updating Netbeans plugin for 3 layer removal
Hi all, Just to update, I have documented my work on the Netbeans plugin related to 3-Layer removal changes here: https://issues.apache.org/ooo/show_bug.cgi?id=123266 I seem to have the plugin working on Netbeans 7.2 and AOO 4.0.0 at least for linux (tested on Fedora 17 x86-64). I have tested a simple AddOn for Writer, AddIn for Calc, and a Client Application. It's possible more work is needed for Mac and Windows. I have upload an updated NBM file to: http://people.apache.org/~cmarcum/devtools/ select org-openoffice-extensions-4.0.5.alpha.nbm Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] Updating Netbeans plugin for 3 layer removal
On 9/16/13 12:35 AM, Carl Marcum wrote:
> Hi,
>
> I'm going on an assumption that the 3-layer removal is a directory
> structure change putting the sdk under the AOO program directory.
>
> I have a question on the directory layout of sdk on platforms other than
> linux.
>
> In netbeans plugin current code is broken for AOO4.
>
> private void skeletonmaker(AddOn addon) {
> String platform = PlatformInfo.getPlatformBinDir(); // returns
> "linux"
> String sdkPath = (String)wiz.getProperty("SdkPath"); // returns
> "/opt/openoffice4/sdk"
> String sdkBinPath =
> sdkPath.concat(File.separator).concat(platform).concat(File.separator).concat("bin");
> // returns "/opt/openoffice4/sdk/linux/bin"
>
> if
> (OpenOfficeLocation.getOpenOfficeLocation().isThreeLayerOffice()) {
> sdkBinPath = sdkPath.concat(File.separator).concat("bin");
> // would return "/opt/openoffice4/sdk/bin"
> }
>
> Since isThreeLayerOffice is false, if I change this to:
>
> if (!OpenOfficeLocation.getOpenOfficeLocation().isThreeLayerOffice()) {
> sdkBinPath = sdkPath.concat(File.separator).concat("bin");
> // returns "/opt/openoffice4/sdk/bin"
> }
> It now works.
>
> My question is would this break other platforms?
not 100% checked but I assume not. The whole code have to be reworked
and I started this work for MacOS already
The SDK is installed in the openoffice4 folder on Linux and Windows. Mac
was always differently.
Some more tweaks are necessary in the project templates. At least addon
and remote client app.
I will try to have a look on this after my vacation.
Juergen
>
> Thanks,
> Carl
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
[DEVTOOLS] Updating Netbeans plugin for 3 layer removal
Hi,
I'm going on an assumption that the 3-layer removal is a directory
structure change putting the sdk under the AOO program directory.
I have a question on the directory layout of sdk on platforms other than
linux.
In netbeans plugin current code is broken for AOO4.
private void skeletonmaker(AddOn addon) {
String platform = PlatformInfo.getPlatformBinDir(); // returns
"linux"
String sdkPath = (String)wiz.getProperty("SdkPath"); // returns
"/opt/openoffice4/sdk"
String sdkBinPath =
sdkPath.concat(File.separator).concat(platform).concat(File.separator).concat("bin");
// returns "/opt/openoffice4/sdk/linux/bin"
if
(OpenOfficeLocation.getOpenOfficeLocation().isThreeLayerOffice()) {
sdkBinPath = sdkPath.concat(File.separator).concat("bin");
// would return "/opt/openoffice4/sdk/bin"
}
Since isThreeLayerOffice is false, if I change this to:
if (!OpenOfficeLocation.getOpenOfficeLocation().isThreeLayerOffice()) {
sdkBinPath = sdkPath.concat(File.separator).concat("bin");
// returns "/opt/openoffice4/sdk/bin"
}
It now works.
My question is would this break other platforms?
Thanks,
Carl
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
[AOO 4.0] [DEVTOOLS] setting toolbar name in Addons.xcu
Hi All, I have committed a change to Netbeans plugin trunk for AOO 4.0 for setting toolbar name in Addons.xcu and setting to AOO 4.0. https://issues.apache.org/ooo/show_bug.cgi?id=122055 I have attached to the issue an example Addons.xcu created with the plugin and a older developer snapshot AOO350m1(Build:9611) - Rev. 1400866 I've been really busy with work and will be away from email a few weeks so I wanted to get this in. If anyone can look at the Addons.xcu file and let me know if there is any issues I'd appreciate it. Also If there is a schema I can validate against, I can work on it when I get back. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
t;> to do in the plugin. It mainly that places of jars, tools, libs >> have >>>>>>>>> changed. >>>>>>>>> >>>>>>>>> Juergen >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this something that will be implemented in AOO 4 release? >>>>>>>> >>>>>>>> >>>>>>> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be >>>>>>> 3.4.1x branch ? >>>>>>> >>>>>>> >>>>>> The Netbeans plugin versions didn't historically coincide with the OOo >>>>>> version numbers (that I know of). >>>>>> >>>>>> When the code came to Apache it was version 2.0.7 and I tagged that >>>>>> version and started work to make it run on Netbeans 6.9 which was >>>> Netbeans >>>>>> 7.0 api changes. That's when I changed it to 3.0. Some additional >>>>>> localization work took it to 3.0.2. >>>>>> >>>>>> I'm not sure what the best solution to version numbering other than to >>>> do >>>>>> a major number change when it's not compatible with AOO or NB and >> keep a >>>>>> compatibility table somewhere. >>>>>> >>>>> >>>>> Thanks for clarifying it for me, I am still learning a lot, however I >> do >>>>> have some opinion on the version numbering. >>>>> >>>>> Netbeans is part of main, and released as an integrated part of AOO. As >>>> far >>>>> as I can see it is not available (for download) independent of AOO. If >> I >>>>> install AOO 4.0, have a problem and see netbeans is 3.0 I would assume >>>> that >>>>> I missed an upgrade. Therefore I will strongly suggest that all modules >>>> in >>>>> main get version 4.0. >>>>> >>>>> If I am wrong and netbeans are available independent, it should not be >> in >>>>> main. Because we will (as we did with 3.4.1) vote about releasing 4.0, >>>> and >>>>> then it would not be correct to silently release a new version of >>>> netbeans, >>>>> just because it is included. >>>>> >>>>> Please do not read my comments as I am against the work. I solely think >>>>> about the version number logistic, which I want to make as simple as >>>>> possible. >>>> >>>> The NetBeans plugin is a developer tool that uses OpenOffice and SDK and >>>> depends on a specific version in the future but it can be seen as >>>> independent and ideally we would bring it back in the plugin center of >>>> Netbeans directly. >>>> >>>> The plugin don't comes with the office and is not part of the source >>>> release. >>>> >>> >>> I thought the source release was the full main ?? >> >> yes, it is but the NetBeans plugin is not in main ;-) >> >> http://svn.apache.org/viewvc/openoffice/devtools/netbeansintegration/ >> > hmmm, what is > > main/scripting/java/org/openoffice/netbeans > > then, I thought that was the plugin, that contains both an editor and > modules. > > or do we have some kind of unwanted mixture ? no everything is as expected. What you have found in main is the beanshell scripting stuff that make use of a NetBeans editor when I remember correctly. Juergen > > rgds > jan I. > > >> >>> >>> Where can I find the script that generates the source release ? >> >> solenv/bin/srcrelease.xml triggered in instset_native/util on demand, no >> default target >> >> Juergen >> >> >>> >>> rgds >>> jan i. >>> >>> >>>> >>>> Juergen >>>> >>>>> >>>>> >>>>>> >>>>>> I do agree with the principle in having a branch. We have however to >>>> make >>>>>>> it clear to developers, that when using that branch their code will >> not >>>>>>> avalible with 4.0. >>>>>>> >>>>>> >>>>>> I agree, that's why I hope everyone continues to do work on trunk and >> we >>>>>> only merge changes if needed for some reason. But we have a well >>>>>> established break point. >>>>>> >>>>> >>>>> To me, branches should be used for work that goes across many modules >>>> (like >>>>> gbuild and l10n), or work that takes a long time (months) to complete. >>>> But >>>>> I have no strong opinion if somebody wants to use a branch, and have >> the >>>>> pain of merging it later. >>>>> >>>>> rgds >>>>> Jan I. >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> rgds >>>>>>> jan I. >>>>>>> >>>>>>> >>>>>> Best regards, >>>>>> Carl >>>>>> >>>>>> >>>>>> >>>> >> --**--**- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< >>>> dev-unsubscr...@openoffice.apache.org> >>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>>> >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 15 April 2013 15:31, Jürgen Schmidt wrote: > On 4/15/13 2:12 PM, janI wrote: > > On 15 April 2013 11:22, Jürgen Schmidt wrote: > > > >> On 4/15/13 9:42 AM, janI wrote: > >>> On 15 April 2013 00:23, Carl Marcum wrote: > >>> > >>>> Hi Jan, > >>>> > >>>> > >>>> On 04/14/2013 02:58 PM, janI wrote: > >>>> > >>>>> On 14 April 2013 20:25, Carl Marcum wrote: > >>>>> > >>>>> Hi Juergen, > >>>>>> > >>>>>> > >>>>>> On 04/14/2013 01:32 PM, Juergen Schmidt wrote: > >>>>>> > >>>>>> Hi Carl, > >>>>>>> > >>>>>>> > >>>>>>> Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: > >>>>>>> > >>>>>>> On 02/10/2013 04:11 PM, Carl Marcum wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On 02/10/2013 02:50 PM, Juergen Schmidt wrote: > >>>>>>>>> > >>>>>>>>> Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > >>>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> I would like to branch NB integration plugin for 3.0 and start > >>>>>>>>>>> modifying > >>>>>>>>>>> trunk for AOO 4.0 compatibility. > >>>>>>>>>>> > >>>>>>>>>>> I would like to also tag current version as 3.0.1 at the same > >> time. > >>>>>>>>>>> > >>>>>>>>>>> Trunk would become version 4.0 to maintain major version number > >> the > >>>>>>>>>>> same > >>>>>>>>>>> as AOO. > >>>>>>>>>>> > >>>>>>>>>>> If there are no objections to the above proposal within > 72-hours > >>>>>>>>>>> then > >>>>>>>>>>> I > >>>>>>>>>>> will invoke Lazy Consensus and proceed to implement the above > >>>>>>>>>>> proposal. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> You can if course create a branch but I don't see the demand > for > >>>>>>>>>> it. > >>>>>>>>>> You can continue the development towards 4.0 on trunk. I don't > see > >>>>>>>>>> many activity here and a branch is not really necessary from my > >> pov. > >>>>>>>>>> > >>>>>>>>>> Juergen > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Carl > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I agree. we can always create a branch based on a revision > number > >>>>>>>>> later if needed. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> I thought about it more and since the next changes will be > >> incompatible > >>>>>>>> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to > >> make > >>>>>>>> it easier if someone needs to make changes for 3.4 compatible > >> plugins. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I agree now and with my upcoming 3layer removal there will be > some > >>>>>>> work > >>>>>>> to do in the plugin. It mainly that places of jars, tools, libs > have > >>>>>>> changed. > >>>>>>> > >>>>>>> Juergen > >>>>>>> > >>>>>>> > >>>>>>>> > >&
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 4/15/13 2:12 PM, janI wrote: > On 15 April 2013 11:22, Jürgen Schmidt wrote: > >> On 4/15/13 9:42 AM, janI wrote: >>> On 15 April 2013 00:23, Carl Marcum wrote: >>> >>>> Hi Jan, >>>> >>>> >>>> On 04/14/2013 02:58 PM, janI wrote: >>>> >>>>> On 14 April 2013 20:25, Carl Marcum wrote: >>>>> >>>>> Hi Juergen, >>>>>> >>>>>> >>>>>> On 04/14/2013 01:32 PM, Juergen Schmidt wrote: >>>>>> >>>>>> Hi Carl, >>>>>>> >>>>>>> >>>>>>> Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: >>>>>>> >>>>>>> On 02/10/2013 04:11 PM, Carl Marcum wrote: >>>>>>> >>>>>>>> >>>>>>>> On 02/10/2013 02:50 PM, Juergen Schmidt wrote: >>>>>>>>> >>>>>>>>> Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I would like to branch NB integration plugin for 3.0 and start >>>>>>>>>>> modifying >>>>>>>>>>> trunk for AOO 4.0 compatibility. >>>>>>>>>>> >>>>>>>>>>> I would like to also tag current version as 3.0.1 at the same >> time. >>>>>>>>>>> >>>>>>>>>>> Trunk would become version 4.0 to maintain major version number >> the >>>>>>>>>>> same >>>>>>>>>>> as AOO. >>>>>>>>>>> >>>>>>>>>>> If there are no objections to the above proposal within 72-hours >>>>>>>>>>> then >>>>>>>>>>> I >>>>>>>>>>> will invoke Lazy Consensus and proceed to implement the above >>>>>>>>>>> proposal. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You can if course create a branch but I don't see the demand for >>>>>>>>>> it. >>>>>>>>>> You can continue the development towards 4.0 on trunk. I don't see >>>>>>>>>> many activity here and a branch is not really necessary from my >> pov. >>>>>>>>>> >>>>>>>>>> Juergen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Carl >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree. we can always create a branch based on a revision number >>>>>>>>> later if needed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I thought about it more and since the next changes will be >> incompatible >>>>>>>> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to >> make >>>>>>>> it easier if someone needs to make changes for 3.4 compatible >> plugins. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree now and with my upcoming 3layer removal there will be some >>>>>>> work >>>>>>> to do in the plugin. It mainly that places of jars, tools, libs have >>>>>>> changed. >>>>>>> >>>>>>> Juergen >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Is this something that will be implemented in AOO 4 release? >>>>>> >>>>>> >>>>> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be >>>>> 3.4.1x branch ? >>>>> >>>>> >>>> The Netbeans plugin versions didn't historically coincide with the OOo >>>> version numbers (that I know of). >>>> >>>> When the code came to Apache it was versi
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 15 April 2013 11:22, Jürgen Schmidt wrote: > On 4/15/13 9:42 AM, janI wrote: > > On 15 April 2013 00:23, Carl Marcum wrote: > > > >> Hi Jan, > >> > >> > >> On 04/14/2013 02:58 PM, janI wrote: > >> > >>> On 14 April 2013 20:25, Carl Marcum wrote: > >>> > >>> Hi Juergen, > > > On 04/14/2013 01:32 PM, Juergen Schmidt wrote: > > Hi Carl, > > > > > > Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: > > > > On 02/10/2013 04:11 PM, Carl Marcum wrote: > > > >> > >> On 02/10/2013 02:50 PM, Juergen Schmidt wrote: > >>> > >>> Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > > Hi all, > > > > I would like to branch NB integration plugin for 3.0 and start > > modifying > > trunk for AOO 4.0 compatibility. > > > > I would like to also tag current version as 3.0.1 at the same > time. > > > > Trunk would become version 4.0 to maintain major version number > the > > same > > as AOO. > > > > If there are no objections to the above proposal within 72-hours > > then > > I > > will invoke Lazy Consensus and proceed to implement the above > > proposal. > > > > > > You can if course create a branch but I don't see the demand for > it. > You can continue the development towards 4.0 on trunk. I don't see > many activity here and a branch is not really necessary from my > pov. > > Juergen > > > > Best regards, > > Carl > > > > > > > > I agree. we can always create a branch based on a revision number > >>> later if needed. > >>> > >>> > >>> > >> I thought about it more and since the next changes will be > incompatible > >> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to > make > >> it easier if someone needs to make changes for 3.4 compatible > plugins. > >> > >> > >> > >> I agree now and with my upcoming 3layer removal there will be some > > work > > to do in the plugin. It mainly that places of jars, tools, libs have > > changed. > > > > Juergen > > > > > >> > >> Is this something that will be implemented in AOO 4 release? > > > >>> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be > >>> 3.4.1x branch ? > >>> > >>> > >> The Netbeans plugin versions didn't historically coincide with the OOo > >> version numbers (that I know of). > >> > >> When the code came to Apache it was version 2.0.7 and I tagged that > >> version and started work to make it run on Netbeans 6.9 which was > Netbeans > >> 7.0 api changes. That's when I changed it to 3.0. Some additional > >> localization work took it to 3.0.2. > >> > >> I'm not sure what the best solution to version numbering other than to > do > >> a major number change when it's not compatible with AOO or NB and keep a > >> compatibility table somewhere. > >> > > > > Thanks for clarifying it for me, I am still learning a lot, however I do > > have some opinion on the version numbering. > > > > Netbeans is part of main, and released as an integrated part of AOO. As > far > > as I can see it is not available (for download) independent of AOO. If I > > install AOO 4.0, have a problem and see netbeans is 3.0 I would assume > that > > I missed an upgrade. Therefore I will strongly suggest that all modules > in > > main get version 4.0. > > > > If I am wrong and netbeans are available independent, it should not be in > > main. Because we will (as we did with 3.4.1) vote about releasing 4.0, > and > > then it would not be correct to silently release a new version of > netbeans, > > just because it is included. > > > > Please do not read my comments as I am against the work. I solely think > > about the version number logistic, which I want to make as simple as > > possible. > > The NetBeans plugin is a developer tool that uses OpenOffice and SDK and > depends on a specific version in the future but it can be seen as > independent and ideally we would bring it back in the plugin center of > Netbeans directly. > > The plugin don't comes with the office and is not part of the source > release. > I thought the source release was the full main ?? Where can I find the script that generates the source release ? rgds jan i. > > Juergen > > > > > > >> > >> I do agree with the principle in having a branch. We have however to > make > >>> it clear to developers, that when using that branch their code will not > >>> avalible with 4.0. > >>> > >> > >> I agree, that's why I hope everyone continues to do work on trunk and we > >> only merge changes if needed for some reason. But we have a well > >> established break point. > >> > > > > To me, branches should be used for work that goes across many m
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 4/15/13 9:42 AM, janI wrote: > On 15 April 2013 00:23, Carl Marcum wrote: > >> Hi Jan, >> >> >> On 04/14/2013 02:58 PM, janI wrote: >> >>> On 14 April 2013 20:25, Carl Marcum wrote: >>> >>> Hi Juergen, On 04/14/2013 01:32 PM, Juergen Schmidt wrote: Hi Carl, > > > Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: > > On 02/10/2013 04:11 PM, Carl Marcum wrote: > >> >> On 02/10/2013 02:50 PM, Juergen Schmidt wrote: >>> >>> Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: Hi all, > > I would like to branch NB integration plugin for 3.0 and start > modifying > trunk for AOO 4.0 compatibility. > > I would like to also tag current version as 3.0.1 at the same time. > > Trunk would become version 4.0 to maintain major version number the > same > as AOO. > > If there are no objections to the above proposal within 72-hours > then > I > will invoke Lazy Consensus and proceed to implement the above > proposal. > > > You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen > Best regards, > Carl > > > I agree. we can always create a branch based on a revision number >>> later if needed. >>> >>> >>> >> I thought about it more and since the next changes will be incompatible >> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make >> it easier if someone needs to make changes for 3.4 compatible plugins. >> >> >> >> I agree now and with my upcoming 3layer removal there will be some > work > to do in the plugin. It mainly that places of jars, tools, libs have > changed. > > Juergen > > >> >> Is this something that will be implemented in AOO 4 release? >>> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be >>> 3.4.1x branch ? >>> >>> >> The Netbeans plugin versions didn't historically coincide with the OOo >> version numbers (that I know of). >> >> When the code came to Apache it was version 2.0.7 and I tagged that >> version and started work to make it run on Netbeans 6.9 which was Netbeans >> 7.0 api changes. That's when I changed it to 3.0. Some additional >> localization work took it to 3.0.2. >> >> I'm not sure what the best solution to version numbering other than to do >> a major number change when it's not compatible with AOO or NB and keep a >> compatibility table somewhere. >> > > Thanks for clarifying it for me, I am still learning a lot, however I do > have some opinion on the version numbering. > > Netbeans is part of main, and released as an integrated part of AOO. As far > as I can see it is not available (for download) independent of AOO. If I > install AOO 4.0, have a problem and see netbeans is 3.0 I would assume that > I missed an upgrade. Therefore I will strongly suggest that all modules in > main get version 4.0. > > If I am wrong and netbeans are available independent, it should not be in > main. Because we will (as we did with 3.4.1) vote about releasing 4.0, and > then it would not be correct to silently release a new version of netbeans, > just because it is included. > > Please do not read my comments as I am against the work. I solely think > about the version number logistic, which I want to make as simple as > possible. The NetBeans plugin is a developer tool that uses OpenOffice and SDK and depends on a specific version in the future but it can be seen as independent and ideally we would bring it back in the plugin center of Netbeans directly. The plugin don't comes with the office and is not part of the source release. Juergen > > >> >> I do agree with the principle in having a branch. We have however to make >>> it clear to developers, that when using that branch their code will not >>> avalible with 4.0. >>> >> >> I agree, that's why I hope everyone continues to do work on trunk and we >> only merge changes if needed for some reason. But we have a well >> established break point. >> > > To me, branches should be used for work that goes across many modules (like > gbuild and l10n), or work that takes a long time (months) to complete. But > I have no strong opinion if somebody wants to use a branch, and have the > pain of merging it later. > > rgds > Jan I. > >> >> >> >>> rgds >>> jan I. >>> >>> >> Best regards, >> Carl >> >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org >> For additional commands, e-mail: dev-h...@openof
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 15 April 2013 00:23, Carl Marcum wrote: > Hi Jan, > > > On 04/14/2013 02:58 PM, janI wrote: > >> On 14 April 2013 20:25, Carl Marcum wrote: >> >> Hi Juergen, >>> >>> >>> On 04/14/2013 01:32 PM, Juergen Schmidt wrote: >>> >>> Hi Carl, Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: On 02/10/2013 04:11 PM, Carl Marcum wrote: > > On 02/10/2013 02:50 PM, Juergen Schmidt wrote: >> >> Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: >>> >>> Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. You can if course create a branch but I don't see the demand for >>> it. >>> You can continue the development towards 4.0 on trunk. I don't see >>> many activity here and a branch is not really necessary from my pov. >>> >>> Juergen >>> >>> Best regards, Carl >>> >>> I agree. we can always create a branch based on a revision number >> later if needed. >> >> >> > I thought about it more and since the next changes will be incompatible > with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make > it easier if someone needs to make changes for 3.4 compatible plugins. > > > > I agree now and with my upcoming 3layer removal there will be some work to do in the plugin. It mainly that places of jars, tools, libs have changed. Juergen > > Is this something that will be implemented in AOO 4 release? >>> >>> >> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be >> 3.4.1x branch ? >> >> > The Netbeans plugin versions didn't historically coincide with the OOo > version numbers (that I know of). > > When the code came to Apache it was version 2.0.7 and I tagged that > version and started work to make it run on Netbeans 6.9 which was Netbeans > 7.0 api changes. That's when I changed it to 3.0. Some additional > localization work took it to 3.0.2. > > I'm not sure what the best solution to version numbering other than to do > a major number change when it's not compatible with AOO or NB and keep a > compatibility table somewhere. > Thanks for clarifying it for me, I am still learning a lot, however I do have some opinion on the version numbering. Netbeans is part of main, and released as an integrated part of AOO. As far as I can see it is not available (for download) independent of AOO. If I install AOO 4.0, have a problem and see netbeans is 3.0 I would assume that I missed an upgrade. Therefore I will strongly suggest that all modules in main get version 4.0. If I am wrong and netbeans are available independent, it should not be in main. Because we will (as we did with 3.4.1) vote about releasing 4.0, and then it would not be correct to silently release a new version of netbeans, just because it is included. Please do not read my comments as I am against the work. I solely think about the version number logistic, which I want to make as simple as possible. > > I do agree with the principle in having a branch. We have however to make >> it clear to developers, that when using that branch their code will not >> avalible with 4.0. >> > > I agree, that's why I hope everyone continues to do work on trunk and we > only merge changes if needed for some reason. But we have a well > established break point. > To me, branches should be used for work that goes across many modules (like gbuild and l10n), or work that takes a long time (months) to complete. But I have no strong opinion if somebody wants to use a branch, and have the pain of merging it later. rgds Jan I. > > > >> rgds >> jan I. >> >> > Best regards, > Carl > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Hi Jan, On 04/14/2013 02:58 PM, janI wrote: On 14 April 2013 20:25, Carl Marcum wrote: Hi Juergen, On 04/14/2013 01:32 PM, Juergen Schmidt wrote: Hi Carl, Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: On 02/10/2013 04:11 PM, Carl Marcum wrote: On 02/10/2013 02:50 PM, Juergen Schmidt wrote: Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen Best regards, Carl I agree. we can always create a branch based on a revision number later if needed. I thought about it more and since the next changes will be incompatible with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make it easier if someone needs to make changes for 3.4 compatible plugins. I agree now and with my upcoming 3layer removal there will be some work to do in the plugin. It mainly that places of jars, tools, libs have changed. Juergen Is this something that will be implemented in AOO 4 release? How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be 3.4.1x branch ? The Netbeans plugin versions didn't historically coincide with the OOo version numbers (that I know of). When the code came to Apache it was version 2.0.7 and I tagged that version and started work to make it run on Netbeans 6.9 which was Netbeans 7.0 api changes. That's when I changed it to 3.0. Some additional localization work took it to 3.0.2. I'm not sure what the best solution to version numbering other than to do a major number change when it's not compatible with AOO or NB and keep a compatibility table somewhere. I do agree with the principle in having a branch. We have however to make it clear to developers, that when using that branch their code will not avalible with 4.0. I agree, that's why I hope everyone continues to do work on trunk and we only merge changes if needed for some reason. But we have a well established break point. rgds jan I. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Am Sonntag, 14. April 2013 um 20:25 schrieb Carl Marcum: > Hi Juergen, > > On 04/14/2013 01:32 PM, Juergen Schmidt wrote: > > Hi Carl, > > > > > > Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: > > > > > On 02/10/2013 04:11 PM, Carl Marcum wrote: > > > > On 02/10/2013 02:50 PM, Juergen Schmidt wrote: > > > > > Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > > > > > > Hi all, > > > > > > > > > > > > I would like to branch NB integration plugin for 3.0 and start > > > > > > modifying > > > > > > trunk for AOO 4.0 compatibility. > > > > > > > > > > > > I would like to also tag current version as 3.0.1 at the same time. > > > > > > > > > > > > Trunk would become version 4.0 to maintain major version number the > > > > > > same > > > > > > as AOO. > > > > > > > > > > > > If there are no objections to the above proposal within 72-hours > > > > > > then I > > > > > > will invoke Lazy Consensus and proceed to implement the above > > > > > > proposal. > > > > > > > > > > > > > > > > > > > > > You can if course create a branch but I don't see the demand for it. > > > > > You can continue the development towards 4.0 on trunk. I don't see > > > > > many activity here and a branch is not really necessary from my pov. > > > > > > > > > > Juergen > > > > > > > > > > > > Best regards, > > > > > > Carl > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree. we can always create a branch based on a revision number > > > > later if needed. > > > > > > > > > > > > > > > > I thought about it more and since the next changes will be incompatible > > > with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make > > > it easier if someone needs to make changes for 3.4 compatible plugins. > > > > > > > > > I agree now and with my upcoming 3layer removal there will be some work to > > do in the plugin. It mainly that places of jars, tools, libs have changed. > > > > Juergen > > > > > > > > > > Is this something that will be implemented in AOO 4 release? yes that is the plan, 4.0 is the best time for it. Juergen > > Thanks, > Carl > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 14 April 2013 20:25, Carl Marcum wrote: > Hi Juergen, > > > On 04/14/2013 01:32 PM, Juergen Schmidt wrote: > >> Hi Carl, >> >> >> Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: >> >> On 02/10/2013 04:11 PM, Carl Marcum wrote: >>> On 02/10/2013 02:50 PM, Juergen Schmidt wrote: > Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > >> Hi all, >> >> I would like to branch NB integration plugin for 3.0 and start >> modifying >> trunk for AOO 4.0 compatibility. >> >> I would like to also tag current version as 3.0.1 at the same time. >> >> Trunk would become version 4.0 to maintain major version number the >> same >> as AOO. >> >> If there are no objections to the above proposal within 72-hours then >> I >> will invoke Lazy Consensus and proceed to implement the above >> proposal. >> >> > You can if course create a branch but I don't see the demand for it. > You can continue the development towards 4.0 on trunk. I don't see > many activity here and a branch is not really necessary from my pov. > > Juergen > >> >> Best regards, >> Carl >> >> > > I agree. we can always create a branch based on a revision number later if needed. >>> >>> I thought about it more and since the next changes will be incompatible >>> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make >>> it easier if someone needs to make changes for 3.4 compatible plugins. >>> >>> >>> >> I agree now and with my upcoming 3layer removal there will be some work >> to do in the plugin. It mainly that places of jars, tools, libs have >> changed. >> >> Juergen >> >>> >>> > Is this something that will be implemented in AOO 4 release? > How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be 3.4.1x branch ? I do agree with the principle in having a branch. We have however to make it clear to developers, that when using that branch their code will not avalible with 4.0. rgds jan I. > > Thanks, > > Carl > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Hi Juergen, On 04/14/2013 01:32 PM, Juergen Schmidt wrote: Hi Carl, Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: On 02/10/2013 04:11 PM, Carl Marcum wrote: On 02/10/2013 02:50 PM, Juergen Schmidt wrote: Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen Best regards, Carl I agree. we can always create a branch based on a revision number later if needed. I thought about it more and since the next changes will be incompatible with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make it easier if someone needs to make changes for 3.4 compatible plugins. I agree now and with my upcoming 3layer removal there will be some work to do in the plugin. It mainly that places of jars, tools, libs have changed. Juergen Is this something that will be implemented in AOO 4 release? Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Hi Carl, Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum: > On 02/10/2013 04:11 PM, Carl Marcum wrote: > > On 02/10/2013 02:50 PM, Juergen Schmidt wrote: > > > Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > > > > Hi all, > > > > > > > > I would like to branch NB integration plugin for 3.0 and start modifying > > > > trunk for AOO 4.0 compatibility. > > > > > > > > I would like to also tag current version as 3.0.1 at the same time. > > > > > > > > Trunk would become version 4.0 to maintain major version number the same > > > > as AOO. > > > > > > > > If there are no objections to the above proposal within 72-hours then I > > > > will invoke Lazy Consensus and proceed to implement the above proposal. > > > > > > > > > > You can if course create a branch but I don't see the demand for it. > > > You can continue the development towards 4.0 on trunk. I don't see > > > many activity here and a branch is not really necessary from my pov. > > > > > > Juergen > > > > > > > > Best regards, > > > > Carl > > > > > > > > > > > > > > I agree. we can always create a branch based on a revision number > > later if needed. > > > > > I thought about it more and since the next changes will be incompatible > with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make > it easier if someone needs to make changes for 3.4 compatible plugins. > > I agree now and with my upcoming 3layer removal there will be some work to do in the plugin. It mainly that places of jars, tools, libs have changed. Juergen > > Best regards, > Carl > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
[DEVTOOLS] update Netbeans plugin for setting toolbar name in Addons.xcu for AOO 4
Hi all, I am working on updating the Netbeans plugin for setting toolbar name in Addons.xcu for AOO 4. This is required for AOO changes documented in bug 121577 and I created bug 122055 to track this change. Since the change will be incompatible with AOO 3.4, I tagged a 3.0.2 version and created a 3.0 branch so trunk will be AOO 4 only. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 02/10/2013 04:11 PM, Carl Marcum wrote: On 02/10/2013 02:50 PM, Juergen Schmidt wrote: Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen Best regards, Carl I agree. we can always create a branch based on a revision number later if needed. I thought about it more and since the next changes will be incompatible with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch to make it easier if someone needs to make changes for 3.4 compatible plugins. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
On 02/10/2013 02:50 PM, Juergen Schmidt wrote: Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen Best regards, Carl I agree. we can always create a branch based on a revision number later if needed. Thanks, Carl
Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum: > Hi all, > > I would like to branch NB integration plugin for 3.0 and start modifying > trunk for AOO 4.0 compatibility. > > I would like to also tag current version as 3.0.1 at the same time. > > Trunk would become version 4.0 to maintain major version number the same > as AOO. > > If there are no objections to the above proposal within 72-hours then I > will invoke Lazy Consensus and proceed to implement the above proposal. > You can if course create a branch but I don't see the demand for it. You can continue the development towards 4.0 on trunk. I don't see many activity here and a branch is not really necessary from my pov. Juergen > > Best regards, > Carl > >
[DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Hi all, I would like to branch NB integration plugin for 3.0 and start modifying trunk for AOO 4.0 compatibility. I would like to also tag current version as 3.0.1 at the same time. Trunk would become version 4.0 to maintain major version number the same as AOO. If there are no objections to the above proposal within 72-hours then I will invoke Lazy Consensus and proceed to implement the above proposal. Best regards, Carl
