Build of 2.0 alpha with java 5

[OPENSTEP]

Overall, after you get your head around how we build (e.g. we're just a "patch" to OOo's code) the worst part is going to be searching for the documentation on how OOo itself works. And then you may just find it's in German...

Parts of Neo are cryptic mostly because it's a bit convoluted to grok makefiles and JNI at times. After a few times it all makes sense. Figuring out OOo's type system is much more painful

ed

[boydf]

i got NeoOffice 2.0.2 Alpha working on my MacBook Pro with Java 5.0_06

It took about 24 hours to recompile but I finally got it working tonight.
I had to change the following three files in the xmerge directory to fix a name conflict with Java 5.0. The files changed are:

source/xmerge/java/org/openoffice/xmerge/ConvertData.java
source/xmerge/java/org/openoffice/xmerge/converter/xml/xslt/DocumentDeserializerImpl.java
source/xmerge/java/org/openoffice/xmerge/converter/xml/xslt/PluginFactoryImpl.java

the xmerge code uses a enum for a variable name but that is a reserved word in Java 5. I did not compile with -source 1.4. Its a native java 5.0 app compile. I changed the enum to enum_ele and restarted the compile.

it took 15GB of disk to compile neooffice and build the distribution CD.


boyd[/b]

[OPENSTEP]

So if I'm understanding, the compile was done with Java 1.5 as the default...I still think the VM that gets embedded into the runtime will be 1.4. There are portions of the VCL that are specifically tied to particular Java runtimes and may have issues shifting to other ones.

Thus far all of my compiles have been with Java 1.4 as the default so I may have not encoutnered any of the xmerge compile errors.

ed

[Pu7o]

[boydf]

[devnull]

[oihenart]

It seems that boysdf has compiled a version of NeoOffice 2.0 Alpha for Intel. It would be a great news. We are using NeoOffice in public schools in Geneva for two years now but now we have a big problem, because we will have two schools with Mac Intel in august. We have to prepare an computer image to be put on theses macs in june, and we cant put NeoOffice. The only choice is to put OpenOffice, and i prefer not.

So if there is a version which runs on Intel, why don't thinking to make EAP for both PPC and Intel, why wait until this summer to do it ?

Thanks again for all the great work soon done : NeoOffice 2.0 Alpha is a rock !

[pluby]

[oihenart]

I think that boydf doesn't want to take that for himsel, but he wanted to upload it on NeoOffice site. But i understand that if you release an intel version, you have to assure support.

So we will be patient, but it's hard to wait !!!

Christian

[LemonAid]

Let's all take a deep breath.

Just because something complies does NOT mean it's ready to be used by the public.

One of the reasons that most of us use NeoOffice is because it works - and Works well! Every step requires a LOT of testing and fixes. Look at all the items that have already been found in NeoOffice 2.0 PPC Alpha. This was the results of 100's of hours of development efforts.

Rushing into something that has not been testing is just asking for lots of problems.
Patrick and Ed are already working overtime (on a shoe-string budget) with the efforts to advance NeoOffice. I can understand why they are NOT willing to spend any more time on supporting something that has not be throughly designed and tested.

If you want to build and run something of your own, then you can do so (obeying Trademark regulations - of course) on your own. It's not fair to ask others to spend their precious time and efforts supporting something they did not build.

I know it's hard to wait but the results are well worth it.
Please be patient. Things have gone well in the past and I have faith in Patrick, Ed and the NeoOffice supporters.

Please understand that the concerns expressed on this message are not because we don't care, but that there are limits to what can be supported .

Philip (excited, but willing to wait for the quality I have come to expect from NeoOffice! )

[OPENSTEP]

Just for reference since others are reading this, there's more details in the following topic:

http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=2613

In realilty, the best thing that folks who can build Intel stuff can do is to help us "prescreen" not only the build process but also the build for errors. It's *insanely* helpful since right now we don't have either the manpower or hardware to do that!

I view open source development in the same way as commercial development. It's 10 times more cost effective to address bugs in development than it is once things get into the hands of end-users. When something is found during development, it's easy for it to be fixed without much overhead. Not only is it less frustrating for a user, but in addition to fixing the code, once something's found by a user you have to communicate with a user (sometimes irate), sort through what the problem is, get details on their configuration or task, file a bug issue, debug the problem, assemble a test patch, get the original reporter to verify correctness, and then eventually respin and post a public combined patch for other users.

It's a lot easier to just check a file into CVS What complicates matters is that we don't have a tech support/customer support staff or full SQA department which normally assist in the end-user involved process like they staff full-time at real companies.

Just a small glimpse of what goes on in addition to coding

ed