Fwd: May I use "OpenOffice.org" and "Apache Incubator" logos on OpenOffice.org CD
Hi Shane. This request to use the OpenOffice.org logo came to the ooo-dev list. We reviewed and there were no objections after 72-hours to forwarding this request on to you with our positive recommendation. Note: the request was also for use of the "Apache Incubator" logo. We gave no opinion on that. Regards, -Rob -- Forwarded message -- From: Kazunari Hirano Date: Wed, Jan 11, 2012 at 9:58 AM Subject: May I use "OpenOffice.org" and "Apache Incubator" logos on OpenOffice.org CD To: ooo-dev@incubator.apache.org Happy New Year! Please take a look at the following page. http://wiki.services.openoffice.org/wiki/JA/Marketing/OpenOffice.org_CD/ May I use "OpenOffice.org" and "Apache Incubator" logos on OpenOffice.org CD? Thanks, khirano -- khir...@apache.org Apache OpenOffice (incubating) http://incubator.apache.org/openofficeorg/
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni wrote: > Hello fellow indians; ;) > > I think there is consensus that this is (at least) > a gray area so I have the following proposal, which > shouldn't get in the way of having this properly > solved by legal but which I think should solve at > least temporarily the issues that we have. It's > actually very simple but who knows, maybe it's even > acceptable as a general incubator policy at the ASF. > > The ext_source in shall be divided, according to > the categories of the licenses, into two > directories in SVN, namely: > > ext_source_A > ext_source_B > This is assuming all 3rd party modules are pure, under a single license. I don't believe this is always the case. Why not treat it the way we treat 3rd party modules in releases, e.g., with a LICENSE and NOTICE file? We could put a LICENSE file in /ext-src. That would make it clear to anyone who browses that directory. > - Ext_source_B shall have a prominent text note that warns > users that the code there is made available only for > builder convenience but that the code is in general > not acceptable for inclusion in Apache source code > releases. > OK, though this is solving a problem we don't really have, right? Although we have not yet built a script to produce a source package per Apache rules, when we do it will not include any of the /ext-src modules, correct? It won't include the category-a and it will not include the category-b either? What would be the point, since the build script brings down what it needs via the bootstrap, per the configuration flags used? So if we really want to give proper notice to the person downloading our source release, this needs to be done: 1) In the LICENSE and NOTICE files. and 2) In the build instructions. Putting extra verbiage in the SVN tree that is not included in the releases -- I don't see the point. Is this to protect casual browsers of our SVN tree? I have no objections if you want to shuffle things around in the directory structure, and update bootstrap logic accordingly. It is your time. But given that these files are not included in our releases, I don't think this solves the problem you originally set out to solve. > - It is understood that ext_source_B is a quarantine > area. The idea is that the code we have there will > only shrink with time. The code there can be updated > for security reasons but in general no new code should > be brought in without specific consensus (voting, checking > with the PPMC, etc, but not lazy consensus). > > NOTE: Consensus for replacing standard OOo 3.4 > functionality like the CoinMP solver code is a given > (particularly as the licensing is being worked on) but > we don't want this to be a loophole to bring in MPL'd > code into AOO. > > Of course we still have to comply with the standard > Apache policies concerning Category-B : "Code that is > more substantial, more volatile, or not directly consumed > at runtime in source form may only be distributed in > binary form." but at least now it should be pretty clear > and easy for everyone downloading the code from SVN where > they can expect licensing issues. > > Pedro. >
Re: Seeking Bugzilla Admin Volunteers
On Sat, Jan 14, 2012 at 7:28 PM, Ariel Constenla-Haile wrote: > Hi *, > > On Sat, Jan 14, 2012 at 11:52:03PM +0100, Andrea Pescetti wrote: >> On 12/01/2012 Rob Weir wrote: >> >I'll enter a JIRA issue asking that myself, and whichever other >> >committers want to be included, be added to a group that will have the >> >following additional Bugzilla permissions: >> >- editbugs >> >- editcomponents >> >- canconfirm >> >- editkeywords >> >> I still have extended permissions (on bugs, not on users) that were >> preserved with the Bugzilla migration. They come handy from time to >> time, so please do not drop them (or just re-add me to the list). >> User pescetti AT apache.org > > are current privileges going to dropped? > I didn't understand it this way (though I confess I do not read *all* > mail coming from this list - otherwise I wouldn't have time to spend on > doing what I like ;) ). > Did you read anyone say that current privileges are going to be dropped? I certainly did not say that. -Rob > Just in case they're going to be dropped, please keep my current status > (canconfirm et. al.): arielch AT apache.org > > > Regards > -- > Ariel Constenla-Haile > La Plata, Argentina
Re: Category-B tarballs in SVN (was Re: External libraries)
On Sat, Jan 14, 2012 at 9:01 PM, Ross Gardler wrote: > On 13 January 2012 18:36, Rob Weir wrote: >> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler >> wrote: >>> On 13 January 2012 17:38, Rob Weir wrote: >>> You are trying to argue the necessity point. >>> >>> I'm not arguing any point. I'm asking questions so that I might >>> understand what the sticking point is. >>> >> >> OK. You'll understand this better if you think of it as a >> configuration management question rather than a question of necessity. > > Thank you Rob. Of course this is well understood in a general context. > However, earlier in this thread I was informed that we were not > talking about situations where the code had been modified. I'm not > clear whether we are talking about hypothetical or real situations > here. There seems to be many contradictions in this thread. > The point Pedro brought up, and the point you are trying to argue against, is storage of MPL modules in SVN. That is what I am arguing for. > To be absolutely clear about my own position in the general context: > > If the third party code is available elsewhere then there is no need > to hold it here in AOO (if there is reason to believe the third party > host is at risk that is an edge case). > You say, "no need". I say "engineering prudence". This is not a policy question. > If third party code needs modification and those modifications have > been contributed to the upstream project but not yet included there > then those patches need to be stored here. > So you are arguing that there may be reasons for storing MPL code in SVN? > I realise that some want to store the full code here, I don't see the > need myself. In the past I've always maintained change sets and > checked out source and applied patches in the build scripts. I've > found that this encourages people to work upstream to get the patches > included. There is some short term pain for this, but in my experience > it is for long term gain. However, I do accept that this doesn't > always work out. > You say, "no need". I say "engineering prudence". This is not a policy question. > Where the AOO project feels this approach is unworkable I believe that > a case for hosting source tarballs should be made to the legal team as > I have tried to communicate earlier in this thread. > You say, "unworkable". I say "engineering prudence". This is not a policy question. > What I, and I guess many other ASF Members, will want to avoid is to > make it easier to modify code and archive it here as a fork than it is > to work at getting the patches committed upstream. > We avoid changing this code in other ways. Maybe this was not clear,or you did not read what was said previously. We do not store individual source files in SVN, as we would the core AOO code. We store tarballs, i.e., archived bundles of the complete module, with a name that includes an MD5 hash of the source code. This prevents anyone on this project from changing that modules without breaking the hash. We're doing only as little as is necessary to ensure the the 3rd party module is properly archived, as a service to the continuity of this project and to downstream consumers. Perhaps you underestimate the importance of this? This might be from lack of experience with software products of comparable size and complexity. AOO is unlike anything else you have at Apache, in terms of size and number of modules we integrate with. This is because unlike almost every other project, we are an end-user GUI application and need to integrate broadly with the platform at many levels, from install/uninstall, to address books, to crypto, to clipboard, to platform specific UI libraries, etc. The typical Apache product does only a small percentage of this. > In the meantime Pedro has made a suggestion that he feels will allow > the project to move forwards. > > Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 18:36, Rob Weir wrote: > On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler > wrote: >> On 13 January 2012 17:38, Rob Weir wrote: >> >>> You are trying to argue the necessity point. >> >> I'm not arguing any point. I'm asking questions so that I might >> understand what the sticking point is. >> > > OK. You'll understand this better if you think of it as a > configuration management question rather than a question of necessity. Thank you Rob. Of course this is well understood in a general context. However, earlier in this thread I was informed that we were not talking about situations where the code had been modified. I'm not clear whether we are talking about hypothetical or real situations here. There seems to be many contradictions in this thread. To be absolutely clear about my own position in the general context: If the third party code is available elsewhere then there is no need to hold it here in AOO (if there is reason to believe the third party host is at risk that is an edge case). If third party code needs modification and those modifications have been contributed to the upstream project but not yet included there then those patches need to be stored here. I realise that some want to store the full code here, I don't see the need myself. In the past I've always maintained change sets and checked out source and applied patches in the build scripts. I've found that this encourages people to work upstream to get the patches included. There is some short term pain for this, but in my experience it is for long term gain. However, I do accept that this doesn't always work out. Where the AOO project feels this approach is unworkable I believe that a case for hosting source tarballs should be made to the legal team as I have tried to communicate earlier in this thread. What I, and I guess many other ASF Members, will want to avoid is to make it easier to modify code and archive it here as a fork than it is to work at getting the patches committed upstream. In the meantime Pedro has made a suggestion that he feels will allow the project to move forwards. Ross
Re: Seeking Bugzilla Admin Volunteers
On Jan 14, 2012, at 4:28 PM, Ariel Constenla-Haile wrote: > Hi *, > > On Sat, Jan 14, 2012 at 11:52:03PM +0100, Andrea Pescetti wrote: >> On 12/01/2012 Rob Weir wrote: >>> I'll enter a JIRA issue asking that myself, and whichever other >>> committers want to be included, be added to a group that will have the >>> following additional Bugzilla permissions: >>> - editbugs >>> - editcomponents >>> - canconfirm >>> - editkeywords >> >> I still have extended permissions (on bugs, not on users) that were >> preserved with the Bugzilla migration. They come handy from time to >> time, so please do not drop them (or just re-add me to the list). >> User pescetti AT apache.org > > are current privileges going to dropped? > I didn't understand it this way (though I confess I do not read *all* > mail coming from this list - otherwise I wouldn't have time to spend on > doing what I like ;) ). > > Just in case they're going to be dropped, please keep my current status > (canconfirm et. al.): arielch AT apache.org IMO the default permissions in the OOO Bugzilla to be VERY constrained. I fixed an issue a few weeks ago with the website and could not do anything! Does anyone have a reference about the workflow in this bugzilla? It is definitely not what I'm used to in the normal Apache bugzilla. Let's consider making our special BZ much more open! Regards, Dave
Re: [BUILD]solaris build failed again.
Hi, On Fri, Jan 13, 2012 at 12:15:56PM +0100, Jürgen Schmidt wrote: > Hi, > > you have to update the sources, there was a fix already from Ariel > that should solve your problem hopefull > > Juergen > > On 1/13/12 12:09 PM, L'oiseau de mer wrote: > >Today i try to build failure, it appear this error message. Maybe > >recently have modified some code about gtk? > >== > > > >[ build LNK ] Library/libvclplug_gtk.so > >Undefined first referenced > > symbol in file > >g_thread_init > >/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/CxxObject/vcl/unx/gtk/app/gtkinst.o > >ld: fatal: symbol referencing errors. No output written to > >/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so > >make: *** > >[/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so] > >Error 2 can you post the full generated command? Also, the contents of GTK_CFLAGS, GTK_LIBS, GTHREAD_CFLAGS et. al. may be helpful. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpbLxmldwgFE.pgp Description: PGP signature
Re: Java 7 and Apache OpenOffice
Hi there, On Sat, Jan 14, 2012 at 09:36:34AM +0100, O.Felka wrote: > >>I'm using this Office > >>http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_de.exe > >>on WinXP - SP3. > >> > >>Regards,Ok, without an official AOO build QA work is nonsense. It makes no > >>sense to jumpp from developer playground A to developer build b to c to see > >>if something is fixed. > >>Olaf > >> > >I'm using > >http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_en-US.exe > > > > > >Regards, > >Zoltan > > > > Ok, I see. > Without an official AOO build QA work is nonsense. I tend to disagree here. It seems you're not subscribed to the issues mailing list (ooo-issues-subscr...@incubator.apache.org). Many issues have been discovered (and even solved) since we started providing builds for testing purposes. Calling this a nonsense is underestimating the efforts of people doing the build, people doing the QA (Regina, Reizinger, Oliver, et. al.), and people solving the issues. Just to quote an example, Regina's work testing the new SVG implementation is remarkable, and I'm sure Armin appreciates it. Facts have shown that builds are useful, we have volunteers willing to help QAing, so we should keep providing them until we have official weekly Developer Snapshots. That said, I agree that the situation is suboptimal, but we do not have buildboots for all platforms yet. > It makes no sense > to jump from developer playground A to developer build b to c to see > if something is fixed or not. Back to the present issue, as I wrote in the bug, we have to split: a) this issue, detect JRE 7.0 version b) issues with things that don't work with JRE 7 For (b), please open new bug reports of the kind "[java 7] XXX does not work" or the like. And set them as blockers for i118352 when/if they are confirmed. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpRHGTJXFw3m.pgp Description: PGP signature
Re: [BUILD]solaris build failed again.
i test build the latest revision, but the problem is still exists, Still is the same error message. 2012/1/13 Jürgen Schmidt : > Hi, > > you have to update the sources, there was a fix already from Ariel that > should solve your problem hopefully > > Juergen > > > On 1/13/12 12:09 PM, L'oiseau de mer wrote: >> >> Today i try to build failure, it appear this error message. Maybe >> recently have modified some code about gtk? >> == >> >> [ build LNK ] Library/libvclplug_gtk.so >> Undefined first referenced >> symbol in file >> g_thread_init >> >> /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/CxxObject/vcl/unx/gtk/app/gtkinst.o >> ld: fatal: symbol referencing errors. No output written to >> >> /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so >> make: *** >> [/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so] >> Error 2 >> dmake: Error code 2, while making 'all' >> ---* RULES.MK *--- >> >> 1 module(s): >> vcl >> need(s) to be rebuilt >> >> Reason(s): >> >> ERROR: error 65280 occurred while making /UNIX-LAB/ooo/main/vcl/prj >> >> When you have fixed the errors in that module you can resume the build >> by running: >> >> build --all:vcl > >
Re: Seeking Bugzilla Admin Volunteers
Hi *, On Sat, Jan 14, 2012 at 11:52:03PM +0100, Andrea Pescetti wrote: > On 12/01/2012 Rob Weir wrote: > >I'll enter a JIRA issue asking that myself, and whichever other > >committers want to be included, be added to a group that will have the > >following additional Bugzilla permissions: > >- editbugs > >- editcomponents > >- canconfirm > >- editkeywords > > I still have extended permissions (on bugs, not on users) that were > preserved with the Bugzilla migration. They come handy from time to > time, so please do not drop them (or just re-add me to the list). > User pescetti AT apache.org are current privileges going to dropped? I didn't understand it this way (though I confess I do not read *all* mail coming from this list - otherwise I wouldn't have time to spend on doing what I like ;) ). Just in case they're going to be dropped, please keep my current status (canconfirm et. al.): arielch AT apache.org Regards -- Ariel Constenla-Haile La Plata, Argentina pgpYTargf9a6x.pgp Description: PGP signature
RE: Java 7 and Apache OpenOffice
+1 There is a similar situation with some JIRA systems that I work on. VERIFIED is a nice condition. My understanding is that RESOLVED means that there is a resolution, with FIXED meaning it has been applied, with VERIFIED needed to be satisfied that the issue can be closed. There is still the case of whether it is verified in the build of a release candidate, and that takes a little more to differentiate. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, January 14, 2012 14:38 To: ooo-dev@incubator.apache.org Subject: Re: Java 7 and Apache OpenOffice On 13/01/2012 Rob Weir wrote: > On Thu, Jan 12, 2012 at 6:24 PM, Andrea Pescetti wrote: >> Wasn't the cycle something like the following? >> - Developer thinks the bug is fixed and marks issue as RESOLVED FIXED. >> - QA engineer sets to VERIFIED, then to CLOSED. ... > The value of having a QA engineer test a bug fix is they also "test > around" the fix, to make sure related areas are not broken. If we > want CRT, then maybe it is a good thing if the person doing the review > is not the same person who did the commit? Sure, but the review (by someone else than the developer) would be the step from RESOLVED FIXED to VERIFIED. When Ariel fixes something, the issue status should change to something different than STARTED (i.e., to RESOLVED FIXED), otherwise there will be no way for QA volunteers to find the "RESOLVED FIXED" issues and verify that they have actually been fixed properly. At least this was my understanding of the VERIFIED status in Bugzilla. Regards, Andrea.
Re: Seeking Bugzilla Admin Volunteers
On 12/01/2012 Rob Weir wrote: I'll enter a JIRA issue asking that myself, and whichever other committers want to be included, be added to a group that will have the following additional Bugzilla permissions: - editbugs - editcomponents - canconfirm - editkeywords I still have extended permissions (on bugs, not on users) that were preserved with the Bugzilla migration. They come handy from time to time, so please do not drop them (or just re-add me to the list). User pescetti AT apache.org Thanks, Andrea.
Re: Java 7 and Apache OpenOffice
On 13/01/2012 Rob Weir wrote: On Thu, Jan 12, 2012 at 6:24 PM, Andrea Pescetti wrote: Wasn't the cycle something like the following? - Developer thinks the bug is fixed and marks issue as RESOLVED FIXED. - QA engineer sets to VERIFIED, then to CLOSED. ... The value of having a QA engineer test a bug fix is they also "test around" the fix, to make sure related areas are not broken. If we want CRT, then maybe it is a good thing if the person doing the review is not the same person who did the commit? Sure, but the review (by someone else than the developer) would be the step from RESOLVED FIXED to VERIFIED. When Ariel fixes something, the issue status should change to something different than STARTED (i.e., to RESOLVED FIXED), otherwise there will be no way for QA volunteers to find the "RESOLVED FIXED" issues and verify that they have actually been fixed properly. At least this was my understanding of the VERIFIED status in Bugzilla. Regards, Andrea.
Re: New feature: Drawing thick lines with line caps
On 13/01/2012 Armin Le Grand wrote: again updated to trunk (after some Svg fixes) and built. Find the linecap install sets under: Win: http://people.apache.org/~alg/linecap/wntmsci12/ Linux64bit: http://people.apache.org/~alg/linecap/unxlngx6/ Have fun checking out the LineCap feature! Thanks Regina, Armin, but would it be possible to have just a couple screenshots with "Before and After" the Linecap feature, for those who are not familiar with terminology and can't install the builds you provided? It's all stuff that we will need to reuse in the release notes anyway, and useful information for potential testers. Regards, Andrea.
another use of the mark request - another logo props update - more branding IOW..
Howdy, Well, haven't looked to update the wiki just yet, will try to finish that tonight.. in the meantime I was reading the comments on the logo - branding - name questions (w/incubating w/p) and spent some time rethinking the images from the other day. I tried to be more expressive of a change, while attempting to think of appropriate incremental type edits. So, these I would propose for use for the current developer snapshot builds - you will see, I hope, that again I tried to emphasize the nature of the release (or non-release if you will) w/ strong dev. snapshot text. So - before I go eat and come back to the wiki, here is a link to the new files as an archive: http://lo-portal.us/aoo/temp/gttysbrg.tar.bz2 The file has 3 folders: SVG for the inkscape source files. - logo.svg is now included -- note this file uses layers to allow different -- permutations of the basic logo design -- this file no longer can be edited as text -- rather is suited for scaling install - has the a new look for application embedded graphics. banner - used the basic logo to generate a couple of web style - images and speaking of which I've used one of those on a web page, though I don't think this use requires pre-emptive permission I don't mind asking for such. http://lo-portal.us/aoo
Re: [build] planning to create new developer snapshots
2012/1/10 Jürgen Schmidt > On 1/10/12 11:23 AM, Oliver-Rainer Wittmann wrote: > >> Hi, >> >> I am planning to create new developer snapshots from the today's revision. >> >> Ariel is already using his space on people.apache.org to provide such >> developer snapshots. I would like to do the same in order to share the >> effort on such a 'service'. >> >> I am able to create builds under Ubuntu 11.10, 32bit (running in a >> VirtualBox) and Windows 7. >> >> @Ariel: May be you can share your 'website' sources/structure. I would >> use it it for my people.apache.org 'website' >> >> Any comments/objections/**improvements? >> > > I would suggest that we use only one page where we can link all provided > builds. That means if you can provide builds, maybe Ariel can contain them > in his overview page. I would add a MacOS build and Linux 64bit on a > regular basis. > Hi-- OK, just an observation. Currently on the wiki from the main page-- http://wiki.services.openoffice.org/wiki/Main_Page is a link (toward the bottom) of Developer Snapshot Builds which goes to http://download.openoffice.org/next Can you still use THAT service for your builds or , if you chose not to, to replace that link with your "new central page". I'm working on some clean up to the Developer FAQs at: http://incubator.apache.org/openofficeorg/developer-faqs.html and will add in the wiki main page to this. But just thought I'd point out this old link/reference. > This way we can support Ariel and the information is centralized in one > place. > > Juergen > > > -- MzK "Follow your bliss." -- attributed to Joseph Campbell
Re: Seeking Bugzilla Admin Volunteers
On 13/01/12 23:07, Dennis E. Hamilton wrote: Great!! One thing to do: Go into your bugzilla account and change your e-mail address! The openoffice.org one will stop working eventually. Also, when you make the change, your history and any issues that have your name on them in any way will be preserved under the new ID. - Dennis -Original Message- From: David McKay [mailto:dmc...@btconnect.com] Sent: Friday, January 13, 2012 14:11 To: dennis.hamil...@acm.org Cc: ooo-dev@incubator.apache.org; thegur...@apache.org Subject: Re: Seeking Bugzilla Admin Volunteers On 13/01/12 20:02, Dennis E. Hamilton wrote: For David McKay, see if thegur...@apache.org is registered. On the other hand, I would not elevate his privileges or ask that he be set up as administrator without having his confirmation that he's still interested and available. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Friday, January 13, 2012 04:35 To: ooo-dev@incubator.apache.org Subject: Re: Seeking Bugzilla Admin Volunteers On Fri, Jan 13, 2012 at 4:48 AM, tj wrote: On 1/12/2012 14:16, Rob Weir wrote: [snip] So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob Count me in (t...@apache.org) for both permissions and admin. I already have some elevated permissions for Documentation project bugs. I will try to make contact with David McKay, to see if he's still interested. It would be nice to have an admin who actually knows what to do. I'd consider him as already volunteered per his previous statements. Do you know his Bugzilla ID? -Rob -- /tj/ I'm still interested and available, real-world job permitting. I'm in the UK time-zone if that has any bearing on anything. Dave. Done.
Re: Java 7 and Apache OpenOffice
Am 13.01.2012 17:33, schrieb Reizinger Zoltán: 2012.01.13. 17:21 keltezéssel, O.Felka írta: Am 13.01.2012 17:18, schrieb Reizinger Zoltán: 2012.01.13. 17:06 keltezéssel, O.Felka írta: Am 13.01.2012 16:55, schrieb Reizinger Zoltán: 2012.01.13. 16:43 keltezéssel, O.Felka írta: Am 13.01.2012 16:21, schrieb Reizinger Zoltán: 2012.01.13. 14:30 keltezéssel, O.Felka írta: Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf Try orw's build it works with java 1.7. : http://people.apache.org/~orw/ Regards, Zoltan It's the same with the builds of Olive: Java 7 has been detected but the Wizard doesn't work. Regards, Olaf It shows a debug messeage: Debug Output --- Error: SfxHTMLParser::SfxHTMLParser: Wo kommt der ZS her? From File c:/AOO/sources/firsttasks/main/sfx2/source/bastyp/sfxhtml.cxx at Line 79 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click no, then second debug error: --- Debug Output --- Error: Don't close the medium when loading documents! From File c:/AOO/sources/firsttasks/main/sfx2/source/doc/objmisc.cxx at Line 1444 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click No, the wizard starts. May be the debug allowed switch was set and they created a debug version of AOO. Regards, Zoltan I don't get a debug output. Just a message box that says that the selected JRE is defective and I should choose another one. Regards, Olaf May be we use different OS, I run under Windows 7. Regards, Zoltan I'm using this Office http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_de.exe on WinXP - SP3. Regards,Ok, without an official AOO build QA work is nonsense. It makes no sense to jumpp from developer playground A to developer build b to c to see if something is fixed. Olaf I'm using http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_en-US.exe Regards, Zoltan Ok, I see. Without an official AOO build QA work is nonsense. It makes no sense to jump from developer playground A to developer build b to c to see if something is fixed or not. Regars, Olaf
Re: Status of OOo NetBeans Plugin
Am Samstag, 14. Januar 2012 schrieb Andrew Rist : > Sounds good - I'll wait for a day or so to see if there are any alternate opinions, then go for it... > A. > > On 1/13/2012 4:16 PM, Carl Marcum wrote: >> >> Hi Andrew, >> >> On 01/13/2012 12:08 PM, Andrew Rist wrote: >>> >>> Where should we check it in? If there is a consensus on the location, >>> I'll check it in and change the headers... >>> after the discussion the last days I am not sure if we should put it under trunk or better besides trunk. People who want it check the sources necessary to build the office only would checkout trunk. If we put it also under trunk people would check these things too and would probably never build it. I am fine with devtools and the plugin already have the name ooonetbeansintegration or so. I have to check it ... Juergen >>> A. >>> >> >> The original discussion is here [1]. >> >> I think the proposal is to start something beside 'trunk' like 'devtools' since it won't be included with OOo source. >> >> I think we should put it's own directory under 'devtools' like 'netbeans' since there will probably be similar plugins in the future like 'eclipse', etc. >> >> [1] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/20.mbox/%3C4ED5FF8D.4050708%40googlemail.com%3E >> >> Thanks, >> Carl >> >>> On 1/13/2012 12:24 AM, Jürgen Schmidt wrote: Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: > > Hi all, > I've seen mentioned in another thread, the OOo NetBeans plugin was to be > part of the SGA, but not yet available. Does anyone know the status of > the code, or when we should see it? > > Best regards, > Carl >>> >> > > -- > > Andrew Rist | Interoperability Architect > OracleCorporate Architecture Group > Redwood Shores, CA | 650.506.9847 > >
