date:20151108


On 07/11/2015 Marcus wrote:

All nice, but with a short of developers that could do any of the points
you listed below, it's just a theoretical idea what could be done. ;-)


While Damjan brought a somewhat more pragmatic approach here, I'm still 
skeptical: not even coming to whether it is desirable, a Java port is 
unrealistic at the moment. Sure, automation can help, but our usage of 
C++, with proliferation of types, exceptions used for non-exceptional 
control flow and many other issues that could be listed makes it hard to 
rely on a "standard" transformation tool: at least we would need a huge 
investment on tests.


This doesn't mean that developers who love Java don't have anything to 
do in OpenOffice! Completing Andre's unfinished work on the new 
Java-based OOXML import/export framework would be a spectacular asset 
that a large percentage of people would benefit from. Ask for 
pointers/history if interested: there are wiki pages, issues and code, 
but it may be hard to find out what refers to the new project and what 
refers to the existing read-only implementation.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

2015-11-08 Thread Damjan Jovanovic

Let's examine porting AOO to Java in more detail.

Java can easily call C code with JNA and also easily call even C++ with
BridJ (https://github.com/nativelibs4java/BridJ) (with its sister project
JNAerator even generating Java code to compile/link yours against by
examining C/C++ header files), and Java can easily call any UNO component.
C/C++ on the other hand can only call Java with great pain using the Java
invocation API, but UNO wraps that for us, so a Java component can be
called as easily as any UNO component. So ideally the smallest unit of
granularity while converting should be an UNO component, and C++ -> Java
call flow should be avoided.

The easiest way to avoid C++ -> Java calls is to convert top down, starting
with top level modules like main/desktop and working down. But if A uses B,
and A is ported to Java and calls B using JNA/BridJ, then when B is also
ported to Java, A's calls to B need to be ported from JNA/BridJ to pure
Java, so working top down, while easier, means a 2 phase porting process is
necessary. Porting modules that are only accessed via UNO, would avoid the
2 phase problem as UNO would be used before and after; main/xmlsecurity
which is only accessed via UNO and needs the category B nss library, is on
the chopping block :-).

The how of porting is maybe the most interesting. For the migration from
CppUnit to Google Test I did recently, the only reason I finished such a
massive undertaking in the time that I did, is that I quickly developed a
tool to parse source code and convert the API. The tens of thousands of
calls to CPPUNIT_ASSERT* in our source tree didn't require hundreds of
thousands of keystrokes. Most of my time was spent on the stuff that
couldn't be automated, like migrating makefiles, fixing failing tests, and
hooking the tests into the build. My migration attempt from dmake to gbuild
- 100% manually - has been a disaster by comparison: only main/formula was
migrated so far - even the tiny 4 file main/animations module mysteriously
crashes Impress when ported, and 1 test in main/tools doesn't link on
Windows...

I only consider the port to Java feasible because it could be mostly
automated. A while ago I discovered cpp-to-java-source-converter (
https://github.com/danfickle/cpp-to-java-source-converter), a compiler that
converts C++ to Java. It's written in Java, under the ASLv2. It uses the
C++ parser from the Eclipse CDT project. It's still incomplete, very slow,
full of errors, and it produces Java code even more complex than the C++
was. But I played with it, fixed a few bugs, forked it (
https://github.com/DamjanJovanovic/cpp-to-java-source-converter) and am
working on more improvements. And with some further work, I think it has
real potential. Obviously not all C++ code can be converted to Java: goto
statements, iterating a char pointer over a struct, and so on, but those
are rare and can always be converted manually. But for the rest, and with
some improvements to cpp-to-java-source-converter, the Java code produced
could be of very high quality: elimination of destructors that only release
memory, the rest converted to close() and RAII implemented as Java 7's
try-with-resources, pointer iteration converted to indexing or Java
iterators and possibly the enhanced for loop, etc.

Also cpp-to-java-source-converter could be patched to output JNA or BridJ
calls from the converted Java, and maybe to even do some API remapping in
place of calls to C++ APIs, like change ::std::map to java.util.Map.

Of course, it won't all be that easy: comments in the code would have to be
copied to Java manually (and hopefully translated from German),
preprocessor #define constants need research, some C++ idioms will be slow
in Java and need to be rewritten, etc. But I am hopeful that this is still
the most promising path, which will produce the highest quality Java code
in the shortest amount of time.

Even if the goal is 100% Java, there would still be a long transition
period where we use C++ as well. We should also improve the user experience
with Java before porting anything to Java. Then maybe we should start by
porting the dodgy modules like xmlsecurity.

Damjan

On Sat, Nov 7, 2015 at 9:41 PM, Dennis E. Hamilton 
wrote:

> There has been suggestion, and some expressed support, for AOO becoming a
> Java application.
>
> I don't want to discuss the merits of this, but how it might be undertaken.
>
>  1. NO STANDING-STILL ASSUMPTION. My first assumption is that one can't
> cease Apache OpenOffice maintenance and support while something like a
> redevelopment on Java occurs. It is pretty unthinkable that development of
> a
> Java version can be accomplished inside the release cycle (even the past
> lengthy cycle), and that migration from AOO as we know it can't be done
> like
> throwing a switch on the universe.  So, my first assumption, which one can
> challenge, is that any development of a Java version must happen separate
> from the ongoing support

Re: [PROPOSAL] Distribute only one source package

2015-11-08 Thread Damjan Jovanovic

On Sun, Nov 8, 2015 at 12:19 PM, Marcus  wrote:

> Am 11/08/2015 12:08 AM, schrieb Andrea Pescetti:
>
> Thanks for bringing this topic again on the table. I remember there was at
> least 1 request to re-think the distribution policy about the source code
> files. And also to consider to offer a file with 7Zip compression.
>
> We currently distribute 3 source packages at
>> https://archive.apache.org/dist/openoffice/4.1.2/source/
>> 1) A .tar.bz2 file (209 MBytes)
>> 2) A .tar.gz file (276 Mbytes)
>> 3) A ZIP file (323 MBytes)
>>
>> The packages are equivalent, so any one would suffice.
>>
>> As discussed by Regina and Juergen recently, we ship #3 as a convenience
>> for Windows users but this leads to broken file permissions, so the
>> recommendation for Windows users is to use #1 or #2, which makes #3
>> useless.
>>
>> I suggest, subject to lazy consensus, that we only distribute #1, i.e.,
>> the .tar.bz2 file.
>>
>> Reasons:
>> * If we distribute one source package, it will be clear that we are all
>> testing and approving the same one
>>
>
> * It would make the release process a little bit smaller and less complex.
>
> * .tar.bz2 offer better compression than .tar.gz
>>
>
> and all types compared together it's even the best compression.
>
> * bzip2 is ubiquitous today, so I don't believe that there are systems
>> capable of building OpenOffice which don't have bzip2 available
>> * better compression formats exist, but they are not as widely supported
>> as the three we are using now, so I'd stick with bzip2
>>
>
> Maybe it's worth it to test also with 7Zip. What I've seen and read
> (outside of OpenOffice files) is promising.
>
>
Do you mean lzma/xz compression (tar.xz) or the .7z file format too?

There's a Bugzilla issue about tar.xz:
https://bz.apache.org/ooo/show_bug.cgi?id=122819


> Otherwise to offer only a .bz2 file is a point I would support.
>
> This of course doesn't apply to 4.1.2, which is already released and
>> will remain available in all three formats.
>>
>
> Marcus
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

2015-11-08 Thread #PATHANGI JANARDHANAN JATINSHRAVAN#

Hi,
I am pretty much a noob and have only started out contributing, but may 
I ask why moving to Java from C++ is being considered? This migration will take 
effort and time, and I was of the understanding that C++ code runs faster than 
Java.

Thanks
Jatin



On 11/8/15, 8:48 PM, "Fernando Cassia"  wrote:

>On Sat, Nov 7, 2015 at 4:41 PM, Dennis E. Hamilton 
>wrote:
>
>> There has been suggestion, and some expressed support, for AOO becoming a
>> Java application.
>>
>
>+1 I think it would be nice. Previous work on Java based office suites show
>promise and that this is possible.
>
>Cases in point:
>
>1. ThinkFree Office
>https://en.wikipedia.org/wiki/ThinkFree_Office
>http://www.linuxplanet.com/linuxplanet/reviews/1579/1/
>(the biggest annoyance back when I tried it were jagged fonts, but the Java
>platform has gained support for font hinting in later releases and even
>HiDPI fonts in Java9).
>
>2. JoeOffice
>http://www.infoworld.com/article/2614544/office-software/java-developer-says-he-built--launched-basic-open-source-office-suite-in-30-days.html
>Promising work, based on the Netbeans Platform.
>
>3.xfy (now: xMetal)
>http://www.infoworld.com/article/2671944/application-development/reinventing-the-office-suite.html
>
>Never tried it, but the above article makes some good points.
>
>
>>
>>  1. NO STANDING-STILL ASSUMPTION. My first assumption is that one can't
>> cease Apache OpenOffice maintenance and support while something like a
>> redevelopment on Java occurs. It is pretty unthinkable that development of
>> a Java version can be accomplished inside the release cycle (even the past
>> lengthy cycle), and that migration from AOO as we know it can't be done
>> like throwing a switch on the universe.
>>
>
>Of course not, Still, the umbrella AOO project can produce and DOES produce
>AOO for several platforms, right, well, Java is a platform too.
>"AOO for Java" or "AOO Java" sounds about right. Independent of work on the
>C/C++ codebase.
>
>
>>2. FORKING TO MAKE AOO4J?  One could consider making a project fork.
>>
>
>The word "fork" only has negative connotations and very little positives,
>if you ask me. Think about all the negative headlines that could be written
>with that word.
>
>No thanks, I prefer "AOO extended to support Java" (AOO for Java or AOO
>Java).
>
>Remember that "Open Office" (the brand name recognition / mindshare) is
>AOO's main asset. Even if you guys re-released "Joe's Office" with an
>Apache Open Office brand name attached to it, I bet you would get 10x more
>users than whatever "Joe's Office" was able to achieve. ;)
>
>Why not join forces and invite the "Joe's Office" developer to such a
>project? Just thinking aloud.
>
>Just my $0.02
>FC

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

"C++ code runs faster than Java" is, to some extent, a hold-over from 
the early days of Java, when JVMs where pure Bytecode interpreters. 
These days, it gets compiled, and optimized, as it is running. The 
optimizer has more data than a C++ optimizer, because it can see what 
flows are being used in that workload on that day.


If I were writing a straightforward number-crunching program like a 
linear equation solver I would probably write it in Fortran or C++, not 
Java, but that is not the sort of program we are talking about here.


I am just getting started on AOO, and don't know the history of this 
discussion, but here are some general advantages of Java:


* No pointer arithmetic. Java "references", which are either null or a 
pointer to an object, are not subject to any direct arithmetic. 
Everything done with them is checked to ensure they always point to an 
object of appropriate class for the type of the pointer. If you see a 
java.lang.String reference it is either null or points to a String object.


* Every array carries around with it its size information, and all array 
accesses are checked to ensure they are accessing into the array, not 
before it or after it. No buffer overflow.


* Automatic garbage collection. Memory management is just a matter of 
making sure each component only keeps references to objects it is going 
to need in the future. This is actually what switched me from C++ to 
Java. I was working on performance models of large servers. I needed to 
keep the object representing e.g. a cache miss around until both address 
path and data path operations were complete, and either could finish 
first. My C++ program worked, but I had put a lot of thought into memory 
management. The next system I worked on I modeled in Java. I spent 
practically no time and smartness cycles on memory management.


In general, my experience is that it is easier to get to a solidly 
working program in Java than C++, easier to localize bugs, and easier to 
make changes safely. That ease of programming translates into easier 
changes in algorithms and data structures, and those are the changes 
that bring the really big performance wins for more complicated programs.


If we were starting from scratch, with no existing code, and discussing 
the choice of language for AOO I would be pushing extremely strongly for 
Java. As it is, you have a valid point about the effort and time for 
migration, which has to be traded off against the benefits.


Patricia

On 11/8/2015 5:19 AM, #PATHANGI JANARDHANAN JATINSHRAVAN# wrote:

Hi, I am pretty much a noob and have only started out contributing,
but may I ask why moving to Java from C++ is being considered? This
migration will take effort and time, and I was of the understanding
that C++ code runs faster than Java.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

2015-11-08 Thread toki

On 08/11/2015 14:32, Patricia Shanahan wrote:

>I am just getting started on AOO, and don't know the history of this
discussion,

Pretty much since Sun purchased StarWriter, there have been proposals to
make OpenOffice.org Java only. If one considers NeoOffice to be a Java
fork, then it is the only proposal to have gained any traction.

>but here are some general advantages of Java:

Things such as
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
are viewed as sufficient reason to avoid Java wherever and whenever
possible.

FWIW, that isn't the only list of known, unpatched zero day exploits of
Java, that are in the wild.

jonathon

signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL] Distribute only one source package

2015-11-08 Thread Rory O'Farrell

On Sun, 08 Nov 2015 20:53:44 +0100
Andrea Pescetti  wrote:

> Rory O'Farrell wrote:
> > On Sun, 8 Nov 2015 09:51:07 -0800 "Dennis E. Hamilton" wrote:
> >> There is interesting discussion on this thread that devolves into what 
> >> compression to use as the single source-package case.
> > My reaction is that most (all?) linux/non-windows builders will be happy 
> > with the proposed .bz2 compression.
> 
> Last time I had the occasion to see them, all normal file decompressors 
> for Windows (Winzip, WinRAR, 7-Zip) were able to extract a .tar.bz2 archive.

My windows experience is way out of date, as instanced by my only knowing it 
handled .ZIP.  If the default archive manager will handle .bz then there is no 
problem except user education; they may need to be told very positively that 
the archiver will handle that file type.

Rory

> 
> So, speculations aside, is there anyone who has a working stack for 
> building OpenOffice on Windows and feels it would be problematic to 
> extract a .tar.bz2 archive?
> 
> > For them we ought make available a package that opens in the default 
> > Windows Archive Manager, whatever that is.
> 
> Do Windows developers really use Windows' built-in utilities for 
> unzipping? I really think that the minimal stack for building OpenOffice 
> on Windows includes some .tar.bz2-capable programs. We do download and 
> expand .tar.bz2 files as part of the build process, so it seems obvious 
> that this is not an issue for Windows developers, meaning that this is 
> covered by standard tooling.
> 
> >> MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a 
> >> source release, using an SVN working copy of the released branch and 
> >> version.
> 
> So long as we (as the project) vote on ONE single source package (the 
> .tar.bz2 one), I'm absolutely OK with you doing that. People who want to 
> distribute their own "unofficial" archive produced with their utility of 
> choice can do that. We can advertise it as a "convenience source 
> package" on http://openoffice.apache.org/downloads.html and store it on 
> people.apache.org. This is entirely possible.
> 
> What we must avoid is that, in theory (since it practice it would be 
> interesting to know how many people do that), we ask people who vote on 
> a release to download 3 source packages, expand all of them (wasting 
> several GBytes of disk space) and ensure they are equivalent. If we have 
> one "canonical" source package, everybody knows what we are voting on. 
> Then we can have any number of "unofficial" archives in other formats.
> 
> >>  One produced on Windows for Windows should not present the 
> >> interoperability and interchange problems that other arrangements 
> >> introduce.
> 
> No idea on this. Maybe yes, maybe not.
> 
> >> I am going to appeal to the Apache Project Maturity Model because I 
> >> believe it is applicable here ...
> >> I think the relevant considerations of what should be *strived*for* are
> >> CD10: The project produces Open Source software, for distribution to the 
> >> public at no charge.
> >> CD20: The project's code is easily discoverable and publicly accessible.
> >> CD30: The code can be built in a reproducible way using widely available 
> >> standard tools.
> >> RE10: Releases consist of source code, distributed using standard and open 
> >> archive formats that are expected to stay readable in the long term.
> 
> bzip2 satisfies all of these requirements. We can ask dev@community if 
> you have any doubts. For sure, many Apache projects do not provide a ZIP 
> file (I admit they tend to prefer .tar.gz to .tar.bz2); no Apache 
> project that I know of distributes 3 source packages.
> 
> >> My question is, on what platform were the troublesome Zips produced, 
> >> using what tools?
> 
> They were done on a Mac, but this (like most of this discussion) is 
> entirely irrelevant. The fact that the .ZIP version has (probably) 
> issues is yet another reason to kill it, but my main reason is to make 
> it clear what we are voting on.
> 
> >> I note also that Zip format is considered standard and open enough that it 
> >> is the format employed for the ODF packages used by OpenOffice
> 
> Here other considerations apply, like decompression speed. But again, 
> I'm not proposing to drop ZIP since it's not standard. I'm proposing to 
> drop it since it's redundant.
> 
> >> Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know 
> >> whether it will unpack a .tar.bz2.
> 
> Several years ago it did. I assume it still does.
> 
> >> I notice that 7z does handle .rar and .msi and perhaps tar.* compressions 
> >> but I haven't checked those.
> 
> If you want to try in practice, try with this:
> 
> http://serf.googlecode.com/files/serf-1.2.1.tar.bz2
> 
> but I'm confident that you will be able to expand it on any machine 
> where OpenOffice can be built.
> 
> By the way, that library is a standard requirement we incorporate in 
>

RE: [PROPOSAL] Distribute only one source package

+1

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Sunday, November 8, 2015 12:03
> To: dev@openoffice.apache.org
> Subject: Re: [PROPOSAL] Distribute only one source package
[ ... ]
> 
> AOO build on Windows currently requires the use of Cygwin which has a
> full range of archive utilities. The downside is that it limits your
> choice of developers to people who are comfortable in a UNIX-like shell
> environment.

[orcmid] 
And because the Windows native development tools (as of VS 2008) are used
from within that environment, it gets very weird and is also rather brittle.

> 
> My ideal tool chain would be:
> 
> Open and extract-all on a zip file OR do an SVN checkout.
> 
> Open an appropriate IDE and load the project description file.
> 
> Build.
> 
> Run.

[orcmid] 
I think that is very important to strive for if we are to attract and
sustain development for the platform which is overwhelmingly (87%) used by
our end-users based on the only measures we have.

> 
> -
> 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

Experiment: Downloading 4.1.2 Source for Assessment of Its Zip Usage

This 

as the recommended download for the 4.1.2 source Zip produces an HTTP 404.

I am downloading r1709696-src.zip from 
.

(This is for testing the Zip and re-zipping it if necessary.)

Attempting to access the asc, md5, and sha256 at, e.g., 

all fail with HTTP 404.

The BACKUP sites listing on 

provides links to the source download, 

but does not explain how to get the asc, md5, and sha256 which is what that
section says these two sites should be used for.

Seeing what the failed URLs are, above, I found that
,
, and

sort of work.  

These open in my browser and I must then be careful how to save them as
text, possibly renaming them to get the correct name on the saved file.  If
there were explicit links on the web page, I could request download of the
files as is.  

In my case, even though I asked for the opened files to be saved as Text,
what I got was HTML in a text file.  I know how to fix the .asc so GnuPG
will recognize it correctly, though, after I also get the filenames as saved
this way to match the filename of the source.

Under VERIFY THE INTEGRITY OF THE FILES, no one is told how to get their
hands on any KEYS file, let-alone the one that applies to this release.
There is the small problem of learning what the gpg command line is for
verifying an external signature.  

For my troubles, already having a PGP public key for Andrea Pescetti and not
bothering to figure out how to get KEYS, I arrived at

d:\>gpg2 --verify apache-openoffice-4.1.2-r1709696-src.zip.asc
apache-openoffice-4.1.2-r1709696-src.zip
gpg: Signature made 10/25/15 10:29:25 Pacific Daylight Time using RSA key ID
8F0E4C63
gpg: Good signature from "Andrea Pescetti (Release Signing Key)
" [full]

Of course, this simplification works if the user understands what is
involved in how the two filenames must match:

d:\>gpg2 --verify apache-openoffice-4.1.2-r1709696-src.zip.asc
gpg: Signature made 10/25/15 10:29:25 Pacific Daylight Time using RSA key ID
8F0E4C63
gpg: Good signature from "Andrea Pescetti (Release Signing Key)
" [full]

Much friction for a novice developer or anyone who wants to see the source
code and follow the procedure.  It is useful to consider that this is the
first time someone might be undertaking this kind of source-code download
and they might be quite intelligent, just operating where they have no
experience yet.  In any case, one would like to minimize the number of ways
someone ends up feeling stupid when attempting all of this.

 -- Dennis E. Hamilton
orc...@apache.org
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Experiment: Downloading 4.1.2 Source for Assessment of Its Zip Usage


Dennis E. Hamilton wrote:

Attempting to access the asc, md5, and sha256 at, e.g.,

all fail with HTTP 404.


The links were broken since files were still in propagation when the 
page was updated, and I git them wrong. If you retry the whole process 
now, a significant part of your concerns should be addressed and we can 
focus on the other ones. I assume your starting point is 
http://openoffice.apache.org/downloads.html


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Distribute only one source package

2015-11-08 Thread Rory O'Farrell

On Sun, 8 Nov 2015 09:51:07 -0800
"Dennis E. Hamilton"  wrote:

> There is interesting discussion on this thread that devolves into what 
> compression to use as the single source-package case.

My reaction is that most (all?) linux/non-windows builders will be happy with 
the proposed .bz2 compression.  However I fear that Windows builders may think 
only in terms of 7zip (or zip as being  compression of choice).  For them we 
ought make available a package that opens in the default Windows Archive 
Manager, whatever that is.

> 
> I do not support this proposal as a first-choice alternative to what may be a 
> surmountable problem.
> 
> I want to speak to some higher-level issues, below.
> 
> MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a 
> source release, using an SVN working copy of the released branch and version. 
>  One produced on Windows for Windows should not present the interoperability 
> and interchange problems that other arrangements introduce.  Unzip onto 
> non-Windows platforms should also work properly.  These things are relatively 
> easy to check and confirm for a power user such as myself, despite my not 
> being a core developer of the code itself.  I will also document the 
> procedure so that anyone can replicate it.
> 
>It should be easy for other committers to unpack the zip and confirm its 
> reliability and accuracy on Windows and other platforms.  They could even add 
> their counter-signing digital signatures.  
> 
>If that fails, then it would be time for a Plan B.  (A possible unexpected 
> difficulty may have to do with line ends on text files across platforms, 
> depending on whether tools address that as well as SVN clients do.)
> 
>  - Dennis
> 
>  - - - - - - - - - - - -
> 
> The TL;DR:
> 
> I am going to appeal to the Apache Project Maturity Model because I believe 
> it is applicable here, whatever the status of the document at 
> .
> 
> I think the relevant considerations of what should be *strived*for* are
> 
> CD10: The project produces Open Source software, for distribution to the 
> public at no charge.
> 
> CD20: The project's code is easily discoverable and publicly accessible.
> 
> CD30: The code can be built in a reproducible way using widely available 
> standard tools.
> 
> RE10: Releases consist of source code, distributed using standard and open 
> archive formats that are expected to stay readable in the long term.
> 
> Something that is not in this list, but I see as a corollary, is that how we 
> do these things is part of demonstrating care for the downstream users of the 
> software we produce, for whatever reason they want to consult, examine, learn 
> from, or even develop with, and whenever they choose to do so with a given 
> source release.
> 
>  - - - - - - - - - - -
> 
> MY QUESTION: There should never be a permissions issue in unpacking a Zip 
> file on Windows.  The only barriers are (1) file names must be ones that are 
> acceptable and unique when extracted into an NTFS file system and (2) empty 
> directories are not created, even if loaded into later in the stream, and 
> there is no use of Zip extensions that apply only to Unix systems and Unix 
> permissions.  There are also concerns about length of full-path file names.  
> (Note that some of these apply to using SVN on Windows too.)
>My question is, on what platform were the troublesome Zips produced, using 
> what tools?  We may be seeing an interchange/interoperability problem that 
> comes from inter-platform incompatibilities.
> 
> MY CONCERN: These provisions are not just for project developers, but for the 
> public.  I don't think only distributing a .tar.bz2 is very adequate with 
> respect to CD20.  RE10 is presumably satisfied if there are no uses of 
> patented technologies, and assuming that no deviations from basic .tar 
> formatting are employed (e.g., no launching of shell scripts involved).  
> 
> I note also that Zip format is considered standard and open enough that it is 
> the format employed for the ODF packages used by OpenOffice and also the 
> packaging of .oxt extensions.  It is also the packaging format of choice for 
> OOXML, EPUB, and other domain-specific usages, including distribution of some 
> libraries used in AOO and other projects.  (I also notice that sometimes 
> those Zips of libraries don't unpack properly on Windows, but rezipping them 
> on Windows then works everywhere.)
> 
> The convention has been to use Zip for Windows oriented access to the source 
> and some flavor of .tar.* for the Unix-oriented world.  The basic use of Zip 
> for Windows tends to unzip easily on any platform that can deal with the 
> filename and folder hierarchies.
> 
> Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know 
> whether it will unpack a .tar.bz2.  Expecting a member of the public who 
> operates on

Re: [PROPOSAL] Distribute only one source package


Rory O'Farrell wrote:

On Sun, 8 Nov 2015 09:51:07 -0800 "Dennis E. Hamilton" wrote:

There is interesting discussion on this thread that devolves into what 
compression to use as the single source-package case.

My reaction is that most (all?) linux/non-windows builders will be happy with 
the proposed .bz2 compression.


Last time I had the occasion to see them, all normal file decompressors 
for Windows (Winzip, WinRAR, 7-Zip) were able to extract a .tar.bz2 archive.


So, speculations aside, is there anyone who has a working stack for 
building OpenOffice on Windows and feels it would be problematic to 
extract a .tar.bz2 archive?



For them we ought make available a package that opens in the default Windows 
Archive Manager, whatever that is.


Do Windows developers really use Windows' built-in utilities for 
unzipping? I really think that the minimal stack for building OpenOffice 
on Windows includes some .tar.bz2-capable programs. We do download and 
expand .tar.bz2 files as part of the build process, so it seems obvious 
that this is not an issue for Windows developers, meaning that this is 
covered by standard tooling.



MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a source 
release, using an SVN working copy of the released branch and version.


So long as we (as the project) vote on ONE single source package (the 
.tar.bz2 one), I'm absolutely OK with you doing that. People who want to 
distribute their own "unofficial" archive produced with their utility of 
choice can do that. We can advertise it as a "convenience source 
package" on http://openoffice.apache.org/downloads.html and store it on 
people.apache.org. This is entirely possible.


What we must avoid is that, in theory (since it practice it would be 
interesting to know how many people do that), we ask people who vote on 
a release to download 3 source packages, expand all of them (wasting 
several GBytes of disk space) and ensure they are equivalent. If we have 
one "canonical" source package, everybody knows what we are voting on. 
Then we can have any number of "unofficial" archives in other formats.



 One produced on Windows for Windows should not present the interoperability 
and interchange problems that other arrangements introduce.


No idea on this. Maybe yes, maybe not.


I am going to appeal to the Apache Project Maturity Model because I believe it 
is applicable here ...
I think the relevant considerations of what should be *strived*for* are
CD10: The project produces Open Source software, for distribution to the public 
at no charge.
CD20: The project's code is easily discoverable and publicly accessible.
CD30: The code can be built in a reproducible way using widely available 
standard tools.
RE10: Releases consist of source code, distributed using standard and open 
archive formats that are expected to stay readable in the long term.


bzip2 satisfies all of these requirements. We can ask dev@community if 
you have any doubts. For sure, many Apache projects do not provide a ZIP 
file (I admit they tend to prefer .tar.gz to .tar.bz2); no Apache 
project that I know of distributes 3 source packages.



My question is, on what platform were the troublesome Zips produced, using 
what tools?


They were done on a Mac, but this (like most of this discussion) is 
entirely irrelevant. The fact that the .ZIP version has (probably) 
issues is yet another reason to kill it, but my main reason is to make 
it clear what we are voting on.



I note also that Zip format is considered standard and open enough that it is 
the format employed for the ODF packages used by OpenOffice


Here other considerations apply, like decompression speed. But again, 
I'm not proposing to drop ZIP since it's not standard. I'm proposing to 
drop it since it's redundant.



Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know 
whether it will unpack a .tar.bz2.


Several years ago it did. I assume it still does.


I notice that 7z does handle .rar and .msi and perhaps tar.* compressions but I 
haven't checked those.


If you want to try in practice, try with this:

http://serf.googlecode.com/files/serf-1.2.1.tar.bz2

but I'm confident that you will be able to expand it on any machine 
where OpenOffice can be built.


By the way, that library is a standard requirement we incorporate in 
OpenOffice, so any system able to build OpenOffice must expand it at 
some point. This is the reason for me to assume that keeping only 
.tar.bz2 is not an issue. But, provided we get consensus on wanting  ONE 
"official" source package, if someone has real arguments for preferring 
.tar.gz over .tar.bz2, .tar.gz may work too.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Distribute only one source package

2015-11-08 Thread Regina Henschel


Hi Andrea,

+1 for your idea of only one source package.

Andrea Pescetti schrieb:

Rory O'Farrell wrote:

On Sun, 8 Nov 2015 09:51:07 -0800 "Dennis E. Hamilton" wrote:

There is interesting discussion on this thread that devolves into
what compression to use as the single source-package case.

My reaction is that most (all?) linux/non-windows builders will be
happy with the proposed .bz2 compression.


Last time I had the occasion to see them, all normal file decompressors
for Windows (Winzip, WinRAR, 7-Zip) were able to extract a .tar.bz2
archive.

So, speculations aside, is there anyone who has a working stack for
building OpenOffice on Windows and feels it would be problematic to
extract a .tar.bz2 archive?


You need Cygwin and tar anyway. So there is no problem to extract a 
tar.bz2 archive.





For them we ought make available a package that opens in the default
Windows Archive Manager, whatever that is.


Do Windows developers really use Windows' built-in utilities for
unzipping? I really think that the minimal stack for building OpenOffice
on Windows includes some .tar.bz2-capable programs. We do download and
expand .tar.bz2 files as part of the build process, so it seems obvious
that this is not an issue for Windows developers, meaning that this is
covered by standard tooling.


Using a tool outside Cygwin is dangerous. Remember the file permission 
troubles I had when building 4.1.2. If we don't deliver a .zip archive, 
it is less likely, that someone uses a tool outside of Cygwin.





MY OFFER: I will happily produce a signed, Windows-acceptable Zip for
a source release, using an SVN working copy of the released branch
and version.


So long as we (as the project) vote on ONE single source package (the
.tar.bz2 one), I'm absolutely OK with you doing that. People who want to
distribute their own "unofficial" archive produced with their utility of
choice can do that. We can advertise it as a "convenience source
package" on http://openoffice.apache.org/downloads.html and store it on
people.apache.org. This is entirely possible.

What we must avoid is that, in theory (since it practice it would be
interesting to know how many people do that), we ask people who vote on
a release to download 3 source packages, expand all of them (wasting
several GBytes of disk space) and ensure they are equivalent. If we have
one "canonical" source package, everybody knows what we are voting on.
Then we can have any number of "unofficial" archives in other formats.



Having only one official source package would make the work flow and the 
voting unambiguous. So I support it. I have no strong opinion whether to 
use .bz2 or .gz. They are both easily to handle with tar in Cygwin.


Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: update feed from 4.1.1 to 4.1.2 ready to go...

2015-11-08 Thread Kay Schenk



On 11/07/2015 01:00 AM, Andrea Pescetti wrote:
> Kay Schenk wrote:
>> Ok. Yeah, I remarked about the date in the attachments, so I will
>> change to Oct 28.
> 
> The issue is not much the date value, but the date format. I've now
> fixed the script to produce exactly the same format we have in
> legacy versions. At your option, you can re-run the script or
> manually set the Oct 28 date, as you wish. Updated script is in SVN
> at the same place:
> http://svn.apache.org/viewvc/openoffice/devtools/genUpdateFeed/generate-update-feed.sh?diff_format=h=markup
> 
> 
>> I will recommit 4.1.1 to 4.1.2 using the script version.
>> I don't plan on reattaching the corrections to the issue. I will
>> just do these fixes and commit on Sunday.
> 
> Perfect, thanks!
> 
> Regards,
>   Andrea.

All feeds should now be active.


-- 

MzK

“Somebody's gotta win, somebody's gotta lose.
 Just don't fight about it.
 Just try to get better."
   -- Yogi Berra




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

2015-11-08 Thread Kay Schenk



On 11/08/2015 05:19 AM, #PATHANGI JANARDHANAN JATINSHRAVAN# wrote:
> Hi, I am pretty much a noob and have only started out
> contributing, but may I ask why moving to Java from C++ is being
> considered? This migration will take effort and time, and I was
> of the understanding that C++ code runs faster than Java.
> 
> Thanks Jatin

I am also wondering about end user memory requirements with a Java
move. See: http://www.openoffice.org/dev_docs/source/sys_reqs_aoo41.html

for our current System Requirements.

In my experience, fine tuning a JVM to work properly for whatever it
is you're doing has been VERY tricky.

I don't disagree that moving to Java would simplify some our
maintenance aspects, but I'm generally concerned about performance
in this kind of environment.

> 
> 
> 
> On 11/8/15, 8:48 PM, "Fernando Cassia" 
> wrote:
> 
>> On Sat, Nov 7, 2015 at 4:41 PM, Dennis E. Hamilton
>>  wrote:
>> 
>>> There has been suggestion, and some expressed support, for
>>> AOO becoming a Java application.
>>> 
>> 
>> +1 I think it would be nice. Previous work on Java based office
>> suites show promise and that this is possible.
>> 
>> Cases in point:
>> 
>> 1. ThinkFree Office 
>> https://en.wikipedia.org/wiki/ThinkFree_Office 
>> http://www.linuxplanet.com/linuxplanet/reviews/1579/1/ (the
>> biggest annoyance back when I tried it were jagged fonts, but
>> the Java platform has gained support for font hinting in later
>> releases and even HiDPI fonts in Java9).
>> 
>> 2. JoeOffice 
>> http://www.infoworld.com/article/2614544/office-software/java-developer-says-he-built--launched-basic-open-source-office-suite-in-30-days.html
>>
>> 
Promising work, based on the Netbeans Platform.
>> 
>> 3.xfy (now: xMetal) 
>> http://www.infoworld.com/article/2671944/application-development/reinventing-the-office-suite.html
>>
>>
>> 
Never tried it, but the above article makes some good points.
>> 
>> 
>>> 
>>> 1. NO STANDING-STILL ASSUMPTION. My first assumption is that
>>> one can't cease Apache OpenOffice maintenance and support
>>> while something like a redevelopment on Java occurs. It is
>>> pretty unthinkable that development of a Java version can be
>>> accomplished inside the release cycle (even the past lengthy
>>> cycle), and that migration from AOO as we know it can't be
>>> done like throwing a switch on the universe.
>>> 
>> 
>> Of course not, Still, the umbrella AOO project can produce and
>> DOES produce AOO for several platforms, right, well, Java is a
>> platform too. "AOO for Java" or "AOO Java" sounds about right.
>> Independent of work on the C/C++ codebase.
>> 
>> 
>>> 2. FORKING TO MAKE AOO4J?  One could consider making a
>>> project fork.
>>> 
>> 
>> The word "fork" only has negative connotations and very little
>> positives, if you ask me. Think about all the negative
>> headlines that could be written with that word.
>> 
>> No thanks, I prefer "AOO extended to support Java" (AOO for
>> Java or AOO Java).
>> 
>> Remember that "Open Office" (the brand name recognition /
>> mindshare) is AOO's main asset. Even if you guys re-released
>> "Joe's Office" with an Apache Open Office brand name attached
>> to it, I bet you would get 10x more users than whatever "Joe's
>> Office" was able to achieve. ;)
>> 
>> Why not join forces and invite the "Joe's Office" developer to
>> such a project? Just thinking aloud.
>> 
>> Just my $0.02 FC
> 
> -
>
> 
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 

MzK

“Somebody's gotta win, somebody's gotta lose.
 Just don't fight about it.
 Just try to get better."
   -- Yogi Berra




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [PROPOSAL] Distribute only one source package

There is interesting discussion on this thread that devolves into what 
compression to use as the single source-package case.

I do not support this proposal as a first-choice alternative to what may be a 
surmountable problem.

I want to speak to some higher-level issues, below.

MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a source 
release, using an SVN working copy of the released branch and version.  One 
produced on Windows for Windows should not present the interoperability and 
interchange problems that other arrangements introduce.  Unzip onto non-Windows 
platforms should also work properly.  These things are relatively easy to check 
and confirm for a power user such as myself, despite my not being a core 
developer of the code itself.  I will also document the procedure so that 
anyone can replicate it.

   It should be easy for other committers to unpack the zip and confirm its 
reliability and accuracy on Windows and other platforms.  They could even add 
their counter-signing digital signatures.  

   If that fails, then it would be time for a Plan B.  (A possible unexpected 
difficulty may have to do with line ends on text files across platforms, 
depending on whether tools address that as well as SVN clients do.)

 - Dennis

 - - - - - - - - - - - -

The TL;DR:

I am going to appeal to the Apache Project Maturity Model because I believe it 
is applicable here, whatever the status of the document at 
.

I think the relevant considerations of what should be *strived*for* are

CD10: The project produces Open Source software, for distribution to the public 
at no charge.

CD20: The project's code is easily discoverable and publicly accessible.

CD30: The code can be built in a reproducible way using widely available 
standard tools.

RE10: Releases consist of source code, distributed using standard and open 
archive formats that are expected to stay readable in the long term.

Something that is not in this list, but I see as a corollary, is that how we do 
these things is part of demonstrating care for the downstream users of the 
software we produce, for whatever reason they want to consult, examine, learn 
from, or even develop with, and whenever they choose to do so with a given 
source release.

 - - - - - - - - - - -

MY QUESTION: There should never be a permissions issue in unpacking a Zip file 
on Windows.  The only barriers are (1) file names must be ones that are 
acceptable and unique when extracted into an NTFS file system and (2) empty 
directories are not created, even if loaded into later in the stream, and there 
is no use of Zip extensions that apply only to Unix systems and Unix 
permissions.  There are also concerns about length of full-path file names.  
(Note that some of these apply to using SVN on Windows too.)
   My question is, on what platform were the troublesome Zips produced, using 
what tools?  We may be seeing an interchange/interoperability problem that 
comes from inter-platform incompatibilities.

MY CONCERN: These provisions are not just for project developers, but for the 
public.  I don't think only distributing a .tar.bz2 is very adequate with 
respect to CD20.  RE10 is presumably satisfied if there are no uses of patented 
technologies, and assuming that no deviations from basic .tar formatting are 
employed (e.g., no launching of shell scripts involved).  

I note also that Zip format is considered standard and open enough that it is 
the format employed for the ODF packages used by OpenOffice and also the 
packaging of .oxt extensions.  It is also the packaging format of choice for 
OOXML, EPUB, and other domain-specific usages, including distribution of some 
libraries used in AOO and other projects.  (I also notice that sometimes those 
Zips of libraries don't unpack properly on Windows, but rezipping them on 
Windows then works everywhere.)

The convention has been to use Zip for Windows oriented access to the source 
and some flavor of .tar.* for the Unix-oriented world.  The basic use of Zip 
for Windows tends to unzip easily on any platform that can deal with the 
filename and folder hierarchies.

Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know 
whether it will unpack a .tar.bz2.  Expecting a member of the public who 
operates on Windows to know how to unpack a .tar.* is an unnecessary source of 
friction.  I notice that 7z does handle .rar and .msi and perhaps tar.* 
compressions but I haven't checked those.  



 - - - - - - - - - - - - -

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Saturday, November 7, 2015 15:08
> To: dev@openoffice.apache.org
> Subject: [PROPOSAL] Distribute only one source package
> 
> We currently distribute 3 source packages at
> https://archive.apache.org/dist/openoffice/4.1.2/source/
> 1) A .tar.bz2 file (209 MBytes)
> 2) A .tar.gz file (276 Mbytes)
>

Re: [PROPOSAL] Distribute only one source package


On 11/8/2015 11:53 AM, Andrea Pescetti wrote:
...

Do Windows developers really use Windows' built-in utilities for
unzipping? I really think that the minimal stack for building OpenOffice
on Windows includes some .tar.bz2-capable programs. We do download and
expand .tar.bz2 files as part of the build process, so it seems obvious
that this is not an issue for Windows developers, meaning that this is
covered by standard tooling.

...

It depends what you mean by standard tooling: tooling as needed 
currently for AOO building or normal tooling.


AOO build on Windows currently requires the use of Cygwin which has a 
full range of archive utilities. The downside is that it limits your 
choice of developers to people who are comfortable in a UNIX-like shell 
environment.


My ideal tool chain would be:

Open and extract-all on a zip file OR do an SVN checkout.

Open an appropriate IDE and load the project description file.

Build.

Run.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

I would be strongly opposed to deserializing untrusted code - it is full 
of problems.


On 11/8/2015 11:14 AM, toki wrote:

On 08/11/2015 14:32, Patricia Shanahan wrote:


I am just getting started on AOO, and don't know the history of this

discussion,

Pretty much since Sun purchased StarWriter, there have been proposals to
make OpenOffice.org Java only. If one considers NeoOffice to be a Java
fork, then it is the only proposal to have gained any traction.


but here are some general advantages of Java:


Things such as
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
are viewed as sufficient reason to avoid Java wherever and whenever
possible.

FWIW, that isn't the only list of known, unpatched zero day exploits of
Java, that are in the wild.

jonathon





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

BUGS

2015-11-08 Thread Call Dave

Be great when you all get the bugs out of this new version.  You spend 10
minutes on the download then when you go to put into your folder of choice
it won't work.  I don't want it in my main C drive, but will not happen
with this new version.   Would you not consider that a waste of 10 minutes
of my time.

Re: BUGS

2015-11-08 Thread JZA

I am not sure what you mean, could you somewhat explain better what the
issue is. That said, you dont need to 'halt' everything you do, while the
computer is downloading. Also there are advanced installation where you can
select where you need AOO to be installed.
You are presented with the option of custom installed and WHERE to be
installed:
http://www.onlinecomputertips.com/images/s89.jpg

Installation could be much faster using more ram (2-4GB) and a Solid state
hard drive, and using a more speedier operating system like GNU/Linux
instead of Windows.

But 10 minutes usually takes upackaging a 350MB software.

If you think this is too much, I recomend benchmarking against Microsoft
Office instalaltion and Adobe Photoshop installation so you can see how
much faster we are, since Microsoft Office should take u longer just
filling out the registration key, loading the DVD and getting it to
register online.

On Sun, Nov 8, 2015 at 6:30 PM, Call Dave <2calld...@gmail.com> wrote:

> Be great when you all get the bugs out of this new version.  You spend 10
> minutes on the download then when you go to put into your folder of choice
> it won't work.  I don't want it in my main C drive, but will not happen
> with this new version.   Would you not consider that a waste of 10 minutes
> of my time.
>

-- 
Alexandro Colorado
Apache OpenOffice Contributor
9060 55AB FFD2 2F02 0E1A  3409 599C 14FC 9450 D3CF

0 Downloads on stats

2015-11-08 Thread JZA

Giving some information to a student doing a paper on Open source adoption,
I notice that the stats failed recording the downloads from our provider.
http://www.openoffice.org/stats/downloads.html

On 7/17/2015 we had a 0 download that day. Wonder if this was a bug, and
wonder if we could add a note and do a revision of what could have happened.

Regards.

-- 
Alexandro Colorado
Apache OpenOffice Contributor
9060 55AB FFD2 2F02 0E1A  3409 599C 14FC 9450 D3CF

Hello

2015-11-08 Thread Urmi Shah

Hello,
I have completed Level 1 module.
-Urmi.

RE: Experiment: Downloading 4.1.2 Source for Assessment of Its Zip Usage

Thanks for the quick repair, Andrea.

I started at  (from the front
page), used the sidebar link to Source, which got me to, and then when that
took me to 
 and the recommended download didn't work, I
stayed on that page looking for what I described.

I concur that a good recommendation comes up for a download link now.  If I
remember to return to , I can
use "Save Target As" to download the associated asc, md5, and sha256 files.
I also found the KEYS file link on that page. (The meaningfulness of web of
trust to someone who is not in it is something to ponder later.) 

That's much better although there is a dissonance when some of the links on
a file entry at  go to download
pages and others provide files (not downloads) directly to the browser.

Much better than getting HTTP 404s though.  Thanks again.

 - Dennis

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, November 8, 2015 13:57
> To: dev@openoffice.apache.org
> Subject: Re: Experiment: Downloading 4.1.2 Source for Assessment of Its
> Zip Usage
> 
> Dennis E. Hamilton wrote:
> > Attempting to access the asc, md5, and sha256 at, e.g.,
> >  openoffice-4
> > .1.2-r1617669-src.zip.sha256>
> > all fail with HTTP 404.
> 
> The links were broken since files were still in propagation when the
> page was updated, and I git them wrong. If you retry the whole process
> now, a significant part of your concerns should be addressed and we can
> focus on the other ones. I assume your starting point is
> http://openoffice.apache.org/downloads.html
> 
> Regards,
>Andrea.
> 
> -
> 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

64-bit AOO for Windows (was RE: [QUESTION] Usability of Non-Optional Java Dependencies)

I think the benefits of an x64 version of OpenOffice are understated.  It has 
apparently been worth it for a cousin OO.o descendant to provide one.  

I think there are two factors that favor having an OpenOffice x64 release:

 1. The biggest benefits of x64 builds are (1) optimized compiling for a more 
modern, high-performance instruction set and any multi-threading advantages 
that arise, and (2) ability to gain the benefits of much more RAM beyond the 
3GB limit that applied under x86, reducing swapping and providing far greater 
input-output buffering.  I suspect (2) is the most noticeable, especially with 
large Calc files but maybe large documents too, although improved graphic 
hardware and software may matter more than we might thing.  There is also a 
benefit in using later Microsoft tooling at the same time, achieving possible 
entry into the Windows Store and using modern installer practices.

 2. I have seen justification of staying with x86 based on the fact that 
Microsoft recommends that Microsoft Office x86 still be used in preference over 
the x64 release to assure maximum compatibility with *existing* plug-ins and 
extensions.  I wonder if this is a red herring.  I have to assume that, since 
OpenOffice on Linux (including MacOS?) must match the bitness of those systems, 
that there has been no terrible difficulty around extensions and plug-ins being 
available/usable between x86 and x64 for those OpenOffice adopters.  Is that 
mistaken?

I also think that OpenOffice was limited in the past because there was no 
freely-available building of x64 applications with free versions of Visual 
Studio (i.e., the earliest Express editions and SDKs).  As far as I can tell, 
one can now produce x64 builds with current versions, including the free Visual 
Studio Community Edition.  Those editions don't produce x86 code for Windows XP 
very easily, but x64 is irrelevant for XP.  That might mean a different build 
for XP until one can retire XP support at some future feature release of AOO.  

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Monday, November 2, 2015 14:14
> To: dev@openoffice.apache.org
> Subject: Re: [QUESTION] Usability of Non-Optional Java Dependencies
> 
> On 01/11/2015 Damjan Jovanovic wrote:
> > 1. We don't have a Win64 version of AOO available for download.
> 
> This has never been a major request from our users, and also technically
> speaking the benefits a user would gain by running a 64-bit version are
> not so big. Sure, it look modern and it is good for marketing, and it is
> nice to have, but better OOXML compatibility (for example) would make
> many more users happy.
> 
[ ... ]

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Thinking of joining OpenOffice as a developer

Ah, found it.

As I said separately when I couldn't find this message, it is best to put the 
actually-used build commands in the source-code tree itself, so that no matter 
how things change over time, each release has what was used to build the 
project-distributed binaries with it.

 - Dennis

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Thursday, October 29, 2015 15:09
> To: dev@openoffice.apache.org
> Subject: Re: Thinking of joining OpenOffice as a developer
> 
> Dennis E. Hamilton wrote:
> >> From: Patricia Shanahan
> >> I started with
> >>
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_o
> >> n_Windows,
> >> but hit some issues and want to make sure I'm using the right guide.
> 
> The first line of that page says
> 
> "This page is archived for historical reasons only. It is no longer
> maintained and information may not be current."
> 
> If you missed it, many others may miss it. I've now created a wiki
> account for you (you will shortly receive a temporary password by mail)
> so that you can fix this and/or other issues you may find: of course
> this is best done by someone who is relatively new to the project.
> 
> > There may be additional information.  The easiest way is to find out
> exactly what the build parameters were  for the 4.1.2 release (which
> should be in the source code archive for that release).
> 
> No, they are not part of the source release. They never were. But this
> time I do have specs of all the systems and build flags we sued, so that
> we can aim at having a reproducible build. I'll put them somewhere in
> SVN (or would the wiki be better?).
> 
> Regards,
>Andrea.
> 
> -
> 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: 0 Downloads on stats

2015-11-08 Thread JZA

As a sidenote the stats havent been updated in 3 months, so would be nice
to do this.

On Sun, Nov 8, 2015 at 8:06 PM, JZA  wrote:

> Giving some information to a student doing a paper on Open source
> adoption, I notice that the stats failed recording the downloads from our
> provider.
> http://www.openoffice.org/stats/downloads.html
>
> On 7/17/2015 we had a 0 download that day. Wonder if this was a bug, and
> wonder if we could add a note and do a revision of what could have happened.
>
> Regards.
>
> --
> Alexandro Colorado
> Apache OpenOffice Contributor
> 9060 55AB FFD2 2F02 0E1A  3409 599C 14FC 9450 D3CF
>



-- 
Alexandro Colorado
Apache OpenOffice Contributor
9060 55AB FFD2 2F02 0E1A  3409 599C 14FC 9450 D3CF

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

Using some combination of general and special purpose tools to do the
bulk of the conversion makes sense to me.

In addition, once we have functionally correct Java code, refactoring
for maintainability becomes easier. I am most familiar with the tools
built into Eclipse: See
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm

Getting to good quality Java code might require a combination of
manually-selected refactoring and tool creation to automate common cases.

On 11/8/2015 12:58 AM, Damjan Jovanovic wrote:

Let's examine porting AOO to Java in more detail.

Java can easily call C code with JNA and also easily call even C++ with
BridJ (https://github.com/nativelibs4java/BridJ) (with its sister project
JNAerator even generating Java code to compile/link yours against by
examining C/C++ header files), and Java can easily call any UNO component.
C/C++ on the other hand can only call Java with great pain using the Java
invocation API, but UNO wraps that for us, so a Java component can be
called as easily as any UNO component. So ideally the smallest unit of
granularity while converting should be an UNO component, and C++ -> Java
call flow should be avoided.

The easiest way to avoid C++ -> Java calls is to convert top down, starting
with top level modules like main/desktop and working down. But if A uses B,
and A is ported to Java and calls B using JNA/BridJ, then when B is also
ported to Java, A's calls to B need to be ported from JNA/BridJ to pure
Java, so working top down, while easier, means a 2 phase porting process is
necessary. Porting modules that are only accessed via UNO, would avoid the
2 phase problem as UNO would be used before and after; main/xmlsecurity
which is only accessed via UNO and needs the category B nss library, is on
the chopping block :-).

The how of porting is maybe the most interesting. For the migration from
CppUnit to Google Test I did recently, the only reason I finished such a
massive undertaking in the time that I did, is that I quickly developed a
tool to parse source code and convert the API. The tens of thousands of
calls to CPPUNIT_ASSERT* in our source tree didn't require hundreds of
thousands of keystrokes. Most of my time was spent on the stuff that
couldn't be automated, like migrating makefiles, fixing failing tests, and
hooking the tests into the build. My migration attempt from dmake to gbuild
- 100% manually - has been a disaster by comparison: only main/formula was
migrated so far - even the tiny 4 file main/animations module mysteriously
crashes Impress when ported, and 1 test in main/tools doesn't link on
Windows...

I only consider the port to Java feasible because it could be mostly
automated. A while ago I discovered cpp-to-java-source-converter (
https://github.com/danfickle/cpp-to-java-source-converter), a compiler that
converts C++ to Java. It's written in Java, under the ASLv2. It uses the
C++ parser from the Eclipse CDT project. It's still incomplete, very slow,
full of errors, and it produces Java code even more complex than the C++
was. But I played with it, fixed a few bugs, forked it (
https://github.com/DamjanJovanovic/cpp-to-java-source-converter) and am
working on more improvements. And with some further work, I think it has
real potential. Obviously not all C++ code can be converted to Java: goto
statements, iterating a char pointer over a struct, and so on, but those
are rare and can always be converted manually. But for the rest, and with
some improvements to cpp-to-java-source-converter, the Java code produced
could be of very high quality: elimination of destructors that only release
memory, the rest converted to close() and RAII implemented as Java 7's
try-with-resources, pointer iteration converted to indexing or Java
iterators and possibly the enhanced for loop, etc.

Also cpp-to-java-source-converter could be patched to output JNA or BridJ
calls from the converted Java, and maybe to even do some API remapping in
place of calls to C++ APIs, like change ::std::map to java.util.Map.

Of course, it won't all be that easy: comments in the code would have to be
copied to Java manually (and hopefully translated from German),
preprocessor #define constants need research, some C++ idioms will be slow
in Java and need to be rewritten, etc. But I am hopeful that this is still
the most promising path, which will produce the highest quality Java code
in the shortest amount of time.

Even if the goal is 100% Java, there would still be a long transition
period where we use C++ as well. We should also improve the user experience
with Java before porting anything to Java. Then maybe we should start by
porting the dodgy modules like xmlsecurity.

Damjan

On Sat, Nov 7, 2015 at 9:41 PM, Dennis E. Hamilton
wrote:

There has been suggestion, and some expressed support, for AOO becoming a
Java application.

I don't want to discuss the merits of this, but how it might be

Re: [PROPOSAL] Distribute only one source package


On 08/11/2015 Marcus wrote:

Puh, too many compression formats that do the same. ;-)


Yes, there are at least a dozen compression formats better than 
.tar.bz2, but it's too easy to get lost in comparing them...


So take this as a proposal to drop ZIP and drop .tar.gz ; then .tar.bz2 
will be left, and if one wants to change it to something else this is 
another story, since all kinds of issues, from widespread support to 
hidden patent traps, from resource requirements to compression and 
decompression times, would have to be examined then.


Realistically, sources are about 2% of the size of a release, so the 
compressed size is not a major concern. Dropping ZIP and .tar.gz already 
cuts the source package size by 75%, which is good enough: we don't need 
a better compression right now, we need one "canonical" source package 
that can work on all systems where OpenOffice can be built.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[REPORT] Apache OpenOffice ODF in the Marketplace - AOO 4.1.1 downloads

Here are updates of the downloads for Apache OpenOffice 4.1.1, now that 4.1.2 
is being distributed by the mirror system.

>From Sourceforge,


Just shy of 50,000,000 downloads.  This number will be exceeded as older 
versions will still continue downloading, although at an ever-decreasing rate.

   87.7% for Windows
9.0% for Macintosh (0.1% small drop from end of August)
3.3% for everything else, including Linux

For the different countries in the same period (53.6 million for all 
distributions, not just 4.1.1), the breakdown can be found here: 
.

It is cool that there were 3 to Antartica: 2 for Windows, 1 for Macintosh.

 - Dennis



> -Original Message-
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Wednesday, September 23, 2015 18:38
> To: dev@openoffice.apache.org
> Subject: RE: [DISCUSS] Apache OpenOffice ODF in the Marketplace -
> Downloading
> 
> Here is a rough, top-level view of Apache OpenOffice by the operating
> systems it is downloaded for.  This should be no surprise.  To have some
> grounding on the immediate situation, here are the downloading
> statistics of Apache OpenOffice 4.1.1 so far.
> 
> From Sourceforge,
>  os?dates=2014-08-01+to+2015-08-31>.
> 
> Of the 41 million downloads that have occurred since release of 4.1.1,
> until the end of August,
> 
> 87.7% are for Windows
>  9.1% are for Macintosh
>  3.2% is everything else, including Linux
> 
> We know some sources of noise, but the overall picture is very clear and
> very decisive.
> 
> For example, some users download multiple times as a form of (usually-
> unsuccessful) trouble-shooting.  We know about that because the next
> step for some is to come to the forums or one of our mailing lists after
> those attempts fail.
> 
> There are also folks who download for use by multiple people and there
> may be some distribution via package installers that are not visible
> here.  That can't change the high-level pattern by much in the case of
> AOO.
> 
> The overall pattern of downloads, with no separation by version, can be
> seen in the chart from 2012-10-01 (around when Apache OpenOffice became
> an official top-level project) to 2015-08-31.  You can see consistent
> seasonal variation and also detect when new releases were introduced,
>  ne?dates=2012-10-01+to+2015-08-31>.
> 
> A more interesting statistic to notice, apart from the perpetual
> dominance of Windows and Macintosh users in the AOO "marketplace" is the
> fact that only about 16-17% of the downloads occur in the United States.
> 
> The SourceForge statistics are easy to operate with.  For refined
> analysis there are datasets and analysis scripts that Rob Weir has
> provided at  stats/>.
> 
> What is more difficult to determine is what folks are actually doing
> with Apache OpenOffice.  There may be ways to learn more.
> 
>  - Dennis
> 
> 
> 
> -Original Message-
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Friday, September 4, 2015 20:01
> To: dev@openoffice.apache.org
> Subject: [DISCUSS] Apache OpenOffice ODF in the Marketplace
> 
> I had not encountered the topic of "ODF in the market place" with regard
> to status of Apache OpenOffice.  Perhaps I have not been paying
> attention.
> 
> I am curious how we might characterize how support for ODF matters to
> Apache OpenOffice users and various institutions that value support for
> ODF in their reliance on Apache OpenOffice and related software.
> 
> How can we determine what the influence of ODF is with respect to Apache
> OpenOffice?
> 
> It strikes me there are two parts to this question.
> 
>  1. Who are the users of Apache OpenOffice?
> 
>  2. What are the ways ODF is (comparatively) significant to those users?
> 
> [ ... ]
> 
> WHO ARE THE USERS?
> 
> Although there are now over 150 million downloads of Apache OpenOffice,
> that does not tell us how many individual users are involved.
> 
> Perhaps the download counts just for AOO 4.1.1 would be a representable
> sample of a particularly-active segment of the user base, even though
> that would be underestimated a couple of ways.  But that, and the
> average weekly rate would be useful as "at least" figures.
> 
> The mix of platforms for those downloads is also important, reflecting
> the context in which those installed downloads are used by new users and
> those who are keeping their configurations current.
> 
> 
> [ ... ]
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For

Re: University student looking for experience in contributing to Open Office.


On 08/11/2015 PATHANGI JANARDHANAN JATINSHRAVAN wrote:

I have a build of Open Office where I am able to reproduce the bug where 
creating a table in design mode does not work, and it does not respond to a 
click. I will get to looking at this issue now.


Thanks Jatin, I had missed your patches, happy to see them!

And about https://bz.apache.org/ooo/show_bug.cgi?id=126622 the first 
attempt I would do is reverting the patch applied to 4.1.2 as part of 
issue https://bz.apache.org/ooo/show_bug.cgi?id=121492 and check if 
issues (which, by all discussions, are now considered to be 
Mac-specific) go away by reverting it.


If this is the case, then the next step is reworking the patch from 
https://bz.apache.org/ooo/show_bug.cgi?id=121492 so that it doesn't have 
side effects, but a simple revert could be tried just to see if the 
problem is there or somewhere else.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] How Many Pre-Built Binaries are Enough?