[4.1.5] Re: SDBC developments and the JDBC driver port

[Dave Fisher]

Hi Damjan,

A friend is sending me a JDK7.

But I agree.

I think that these changes should be backported to 4.1.5. The redland and 
raptor updates should be backported too.

RMs Jim / Matthias - what do you think?

Regards,
Dave

Sent from my iPhone

> On Oct 27, 2017, at 7:07 PM, Damjan Jovanovic  wrote:
> 
> Apply these commits to 4.1.x and you'll be able to build AOO with Java 8:
> 1697228
> 1697237
> 1697247
> 1697306
> 1697312
> 
> I don't know why they haven't been backported yet.
> 
> Damjan
> 
>> On Fri, Oct 27, 2017 at 10:31 PM, Dave Fisher  wrote:
>> 
>> Hi Matthias,
>> 
>> It is no longer easy to get EOLed JDKs. You have to pay Oracle for
>> support. You have to pay Apple to get the old SDKs you need for Mac
>> OpenOffice. I don’t mind paying Apple as I have the goal of trying to sign
>> the Application to avoid Gatekeeper. I have the Xcode stuff and I’ve found
>> JDK 6s. If a friend has the the JDK7 in /Libary/Java/JavaVirtualMachines/
>> and would ship it to me that would be AWESOME.
>> 
>> In my builds with JDK6 I am now having trouble with Help.
>> 
>> There is a lot wrong with the Building guides. Too many options - MacPort
>> or Brew, etc.
>> 
>> I’ve spent about 16 hours this week on this and … I am about done with it.
>> 
>> Regards,
>> Dave
>> 
>> On Oct 27, 2017, at 1:22 PM, Matthias Seidel 
>> wrote:
>> 
>> Am 27.10.2017 um 21:19 schrieb Dave Fisher:
>> 
>> Hi -
>> 
>> As an aside I am working on Mac builds for 4.1.4 and it looks like uno does 
>> not like JDK 8+, something to do with javadocs, but not sure as I am looking 
>> for JDK7 …
>> 
>> 
>> Do you need the SDK?
>> 
>> From our release notes (Known Issues):
>> 
>> For developers:
>> 
>>   - The OpenOffice SDK won't build with Java 8. Either build with
>>   --disable-odk or see the dev list archives for possible solutions.
>> 
>> Either go with Java 7 or use --disable-odk as configure switch.
>> 
>> Regards, Matthias
>> 
>> If I can get things working I will be willing to try builds for you on trunk 
>> or a branch as you make changes.
>> 
>> Regards,
>> Dave
>> 
>> 
>> On Oct 27, 2017, at 12:05 PM, Peter Kovacs  
>>  wrote:
>> 
>> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
>> 
>> Hi
>> 
>> *wave*
>> 
>> To update you on my development efforts, the PostgreSQL driver
>> continues to
>> advance. I recently added views and fixed a major problem where
>> "Refresh
>> Tables" causes everything done to tables from then on to fail (as
>> Base
>> keeps holding references to the old table/view/user/group containers,
>> so
>> container contents may change, but containers themselves must persist
>> for
>> the lifetime of the driver).
>> 
>> I did however run into a disturbing bug. When my SDBC driver in Java
>> calls
>> XStatement.close() on our underlying SDBC to JDBC converter driver
>> written
>> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
>> JDBC
>> driver, I get a reproducible unchecked
>> java.lang.IllegalClassChangeError
>> exception. After hours of debugging I did manage to work around it,
>> by
>> getting a new methodID before every JNI call to close() instead of
>> caching
>> it in a static global variable, which shouldn't be required as
>> methodIDs
>> are meant to persist for the lifetime of the JVM. Either it's a bug
>> in the
>> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
>> corruption or the like :(.
>> 
>> Instead of committing that senseless methodID hack, I've decided to
>> port
>> the SDBC-JDBC driver to Java, which should make memory corruption
>> impossible and any debugging and future maintenance much easier (the
>> JNI
>> code to call into Java is exceptionally complex and ugly, and
>> compiles into
>> a 15 MB pig of a library in a debug build!). Nothing is lost by using
>> Java,
>> as the C++ driver can't load JDBC drivers without Java either, and
>> performance should be identical as the slow boundary between native
>> and
>> Java is crossed an equal number of times, the crossing just happens
>> in the
>> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
>> 
>> WTF?!
>> 
>> So far the reusable parts of the PostgreSQL driver have been split
>> off into
>> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
>> itself
>> currently in the painful phase of dealing with JDBC classloading and
>> class
>> caching. The final architecture should be something along these
>> lines:
>> 
>> The rest of AOO (mostly C++)
>> |  |
>> |UNO   | UNO
>> |  v
>> |  PostgreSQL SDBC driver (Java)
>> |  | |
>> |  | UNO | UNO
>> v  v v
>> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
>> |  |  |
>> | Java | Java | C
>> v  v  v
>> other   PostgreSQL JDBC  PostgreSQL ODBC
>> JDBC driver (Java)driver (C)

Re: SDBC developments and the JDBC driver port

[Damjan Jovanovic]

Apply these commits to 4.1.x and you'll be able to build AOO with Java 8:
1697228
1697237
1697247
1697306
1697312

I don't know why they haven't been backported yet.

Damjan

On Fri, Oct 27, 2017 at 10:31 PM, Dave Fisher  wrote:

> Hi Matthias,
>
> It is no longer easy to get EOLed JDKs. You have to pay Oracle for
> support. You have to pay Apple to get the old SDKs you need for Mac
> OpenOffice. I don’t mind paying Apple as I have the goal of trying to sign
> the Application to avoid Gatekeeper. I have the Xcode stuff and I’ve found
> JDK 6s. If a friend has the the JDK7 in /Libary/Java/JavaVirtualMachines/
> and would ship it to me that would be AWESOME.
>
> In my builds with JDK6 I am now having trouble with Help.
>
> There is a lot wrong with the Building guides. Too many options - MacPort
> or Brew, etc.
>
> I’ve spent about 16 hours this week on this and … I am about done with it.
>
> Regards,
> Dave
>
> On Oct 27, 2017, at 1:22 PM, Matthias Seidel 
> wrote:
>
> Am 27.10.2017 um 21:19 schrieb Dave Fisher:
>
> Hi -
>
> As an aside I am working on Mac builds for 4.1.4 and it looks like uno does 
> not like JDK 8+, something to do with javadocs, but not sure as I am looking 
> for JDK7 …
>
>
> Do you need the SDK?
>
> From our release notes (Known Issues):
>
> For developers:
>
>- The OpenOffice SDK won't build with Java 8. Either build with
>--disable-odk or see the dev list archives for possible solutions.
>
> Either go with Java 7 or use --disable-odk as configure switch.
>
> Regards, Matthias
>
> If I can get things working I will be willing to try builds for you on trunk 
> or a branch as you make changes.
>
> Regards,
> Dave
>
>
> On Oct 27, 2017, at 12:05 PM, Peter Kovacs  
>  wrote:
>
> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
>
> Hi
>
> *wave*
>
> To update you on my development efforts, the PostgreSQL driver
> continues to
> advance. I recently added views and fixed a major problem where
> "Refresh
> Tables" causes everything done to tables from then on to fail (as
> Base
> keeps holding references to the old table/view/user/group containers,
> so
> container contents may change, but containers themselves must persist
> for
> the lifetime of the driver).
>
> I did however run into a disturbing bug. When my SDBC driver in Java
> calls
> XStatement.close() on our underlying SDBC to JDBC converter driver
> written
> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
> JDBC
> driver, I get a reproducible unchecked
> java.lang.IllegalClassChangeError
> exception. After hours of debugging I did manage to work around it,
> by
> getting a new methodID before every JNI call to close() instead of
> caching
> it in a static global variable, which shouldn't be required as
> methodIDs
> are meant to persist for the lifetime of the JVM. Either it's a bug
> in the
> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
> corruption or the like :(.
>
> Instead of committing that senseless methodID hack, I've decided to
> port
> the SDBC-JDBC driver to Java, which should make memory corruption
> impossible and any debugging and future maintenance much easier (the
> JNI
> code to call into Java is exceptionally complex and ugly, and
> compiles into
> a 15 MB pig of a library in a debug build!). Nothing is lost by using
> Java,
> as the C++ driver can't load JDBC drivers without Java either, and
> performance should be identical as the slow boundary between native
> and
> Java is crossed an equal number of times, the crossing just happens
> in the
> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
>
> WTF?!
>
> So far the reusable parts of the PostgreSQL driver have been split
> off into
> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
> itself
> currently in the painful phase of dealing with JDBC classloading and
> class
> caching. The final architecture should be something along these
> lines:
>
> The rest of AOO (mostly C++)
> |  |
> |UNO   | UNO
> |  v
> |  PostgreSQL SDBC driver (Java)
> |  | |
> |  | UNO | UNO
> v  v v
> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
> |  |  |
> | Java | Java | C
> v  v  v
> other   PostgreSQL JDBC  PostgreSQL ODBC
> JDBC driver (Java)driver (C)
> drivers |  |
>| network I/O  |
>v  v
>PostgreSQL server
>
>
> +1 Looks like a clean architecture, LIKE ! S2
>
> I've also already developed considerable support code for Java
> (logging,
> resource bundles, data structure manipulation), all ported from the
> support
> code for C++ under main/comphelper. Since it is generally useful to
> other
> Java UNO modules, should I move it elsewhere, such as
> main/javaunohelper
> which already contains 

Re: [PROPOSAL] Managing branches for future releases

[Andrea Pescetti]

Peter Kovacs wrote:

I hope I did not scare anyone with this lengthy explanation now.


No, but it is just off-topic. This is partially my fault since "Managing 
branches" in the subject could be read as a proposal for a branching 
model. But this is totally not the topic here.


The issue here is very simple and unrelated to the branching model. The 
issue is: if you want a release to be named "4.1.4" you have to update 
dozens of files to get it done properly, it is not a one-line change to 
set "VERSION = 4.1.4" as some would expect. This is stupid, should be 
scripted, caused two rebuilds of binaries in 4.1.4 due to distraction.


If we have to release 4.1.5 (not foreseen at the moment) we will want to 
spend our time in actually fixing the bugs, and not in the painful 
update of release numbers here and there. If we do it now, and maybe 
take the occasion for scripting it, we won't risk useless delays.


This is all I wanted to say, and I hope it's clear now.

We could go on for ages discussing branching models, but the point of 
this thread was actually to address the problem with actually changing 
release numbers in code, nothing else.


Regards,
  Andrea.

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

Re: [PROPOSAL] Managing branches for future releases

[Dave Fisher]

Hi -

I’ll bite on a discussion. Overall I think that we are mixing two different 
purposes.

(1) Keeping track of what is or may be released. This is what the current 
scheme does well when we are on a branch and not so well when we are on trunk.
(2) Managing the lifecycle of a particular release. You propose a fairly common 
step model. I think that we go to a release branch sometime in your TEST.

We have a very complex build process where a little change on Windows might 
make the Unix or Mac build unstable.

I would propose that we operate more like so.

We have two types of branches.

(A) Release branches as we do now. These have Test, Release and Maintenance 
phases. In this case all of our 4.1.X branches including 4.1.5 are in 
maintenance.
(B) Feature branches would be new for AOO. In these branches we co-operate 
between DEV and Test phases. We work out build issues on each platform for the 
feature in isolation. Community testers can be given test builds, etc.

Branches are merged to Trunk or a Release at certain times in the lifecycle. 
When a merge is done a phase of TEST is required on the result.

Example.

(1) Create an SDBC feature branch from trunk.
(2) Create a 4.2.0 release branch from trunk.
(3) Create an update Java feature branch from trunk.
(4) Develop and test the Java update.
(5) Merge the Java feature branch to SDBC feature branch.
(6) Develop and test the SDBC feature branch.
(7) Merge the SDBC feature branch to trunk and TEST.
(8) Merge trunk to 4.2.0 release branch.
(9) Test the 4.2.0 release branch.
(10) Release 4.2.0.

Other feature branches could be:
- Sign the Mac Application with an Apple Developer key.
- Bullet proof Windows Installer to reject spammers.

Regards,
Dave


> On Oct 27, 2017, at 2:28 PM, Peter Kovacs  wrote:
> 
> Disclaimer:
> I do not claime that one solution is the ultimate solution over the
> other.
> 
> But I would like to explain my approach as long as it takes until
> everybody says he understood what I am suggesting. Nothing more nothing
> less. No religeous war is intended or whished from my side.
> end disclaimer.
> 
> Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
>>> Why do you think it is a problem to go by state?
>> 
>> I cannot see what is behind the names. "test" - from what? Is it
>> still
>> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
>> for
>> everyone.
> It is a life cyle model. You do not need to know a release number.
> A release number does tell nothing.
> A life Cycle state tells you exactly which state the Product is in.
> 
> DEV: It is under development. The code can have serious bugs, break.
> But can also have the newst feature that may only partial implemented.
> In general the code is good enough that it compiles on the dev
> machines.
> 
> TEST: Often revered to unstable.
> The Code is in a feature freeze. It recieves bugfixes, that stabilize
> the Code until it reaches the maturity that we expect from it. TEST
> unlike DEV takes picks only new features up at a certain time.
> Usually after the Code has reached a maturity state.
> 
> 
> Release: often reverred to Stable.
> The branch that only contains best possible code, to have transperency.
> It also is the source to give people a clear state what is changing
> from one change to the next.
> 
> hotfix, means maintenance:
> This should be an exception. When we feel we need to fix something on
> release level, because we missed a bug in the maturity phase.
> 
> It is a complete different development model. We can use Release
> numbers to name a specific cycle. But we control the code not by that
> number. We could give it also a Name like "Eternia Version" Would have
> the same meaning.
> 
> Let me draw a picture, a fantasy example for illustration:
> Time >
> by live cycle:
>  4.1.4   4.1.5
> hotfix  -x--x---++--x--x---x+  4.2.0
> Release V+--V---A-
>  born:4.2.0   every x here a bugfix born:5.0.0
> 
> Test---A--x---x-x--x--x---xx--x-+-A---x--x---x-
> Dev xx-+-xxx-x--V-+
>   PSQL1&2  OOXML   Googlestuff  Root-lib| fix integration
>video feature
> 
> by release Number:
>   PSQL1&2  OOXML   Googlestuff  Root-lib  Sience-interface
> trunc -x--xx-+-xx---x-x--x--xx--xx-x+-+--x--x---x-
> 4.1.4 -x--x---+
> 4.1.5 +--x--x---x+
> 4.2.0+-xx---x-x--x--x---xx--x-+
> 5.0.0 +---x--x---x-
> 
> The above example does not break any history. You have a clear state,
> on the advancement of the code.
> You can compare at any given time the code (I.E. using fisheye). And
> you can archieve by time.
> In the above model we restrict sharing of changes to certain 

Re: Organisation der Community war: Was können wir gegen Trittbrettfahrer tun?

[Marcus]

Am 27.10.2017 um 21:49 schrieb Jörg Schmidt:



From: Marcus [mailto:marcus.m...@wtnet.de]
Sent: Friday, October 27, 2017 6:23 PM
To: dev-de@openoffice.apache.org
Subject: Re: Organisation der Community war: Was können wir
gegen Trittbrettfahrer tun?

Dieser Post ist allgemein zu sehen und nicht speziell als
Antwort auch
Michael's Post:

Ich lese hier viel von "Apache muss mal ...", "Apache sollte ...",
"Entscheidung von Apache nötig ...".

Das sieht für mich immer so aus, also ob man erwartet, dass
etwas getan
oder entschieden wird, bevor man selber etwas macht.


Dann darf ich Dir versichern das es mir darum _nicht_ geht und das die 
meritokratische Arbeitsweise bei Apache-Projekten verstanden habe.


OK, aber es liest für mich wirklich anders aus.


Meine Möglichkeiten (und die normaler Community-Mitglieder bzw. auch Committer) 
enden hingegen da wo es z.B. gilt im Namen des Projektes tätig zu werden.
Es ist nicht möglich lokale Öffentlichkeits-/Pressearbeit zu betreiben indem 
man versucht die eigene Meinung kundzutun, sondern dazu braucht es eine 
Legitimation, zumindest ausdrücklich seitens der Community, nach dem was man 
mir seit Jahren sagt, aber auch von Apache.


Naja, aber wir sind hier alle privat und einzelnd unterwegs.
Wir haben keinen Vorstand oder tada, Pressesprecher. Wir können gerne 
versuchen, einen in unserer Mitte zu finden. Aber ansonsten werden das 
einzelne Personen übernehmen (müssen).



Natürlich gibt es Regeln, wie man hier arbeiten kann. Das
dient aber der
Organisation und Struktur, damit es nicht ganz im Chaos versinkt.


Diese Regeln sind mir bekannt und die meine ich nicht.


- Willst Du, dass eine Webseite anders aussieht/anderen Text hat
--> mach es. *)


nun ja, ich würde da (ganz freiwillig) zumindest(*) den Weg des lazy consensus 
gehen bevor ich Hand anlege (es sei den es ginge nur um eine Bagatelle), denn 
dieser Weg ist etwas was ich sehr sinnvoll finde um einerseits schnell handeln 
zu können, andererseits aber nichts im Alleingang zu tun.

(*)
bei größeren Dingen würde ich vorher lieber eine normale Diskussion anstoßen


Bei größeren Dinge ist das durchaus OK. Zumindest sagen, was Du machen 
willst.


Was immer gut ankommt ist eine Beispielwebseite, mit dem was Du 
darstellen/zeigen willst. Die können wir uns ansehen, kommentieren und 
letztendlich finalisieren.



Oder kurz:
Willst Du .., mach es ...


1.
genau das hatte ich vor, z.B. der Thread hier diente mir eigentlich dazu mit 
Vertretern der de-Community zu diskutieren ob wir nicht gemäß meines Vorschlags 
(auf der internationalen dev-Liste Pressemeldung dazu anregen) verfahren wollen.
Nicht ein Wort dazu jedoch von Michael oder Dir ... war mein Vorschlag zu 
versteckt? ... bist Du nicht einverstanden? ... ist das Thema zu banal?


Vielleicht liegt es aber auch daran, dass Du viel und gerne diskutierst 
bzw. diskutieren willst. Da ist es zumindest für mich immer anstrengend, 
dass alles zu verfolgen. ;-)


BTW:
Wenn Du etwas auf den de-Seiten ändern willst, musst Du nicht auf der 
großen dev-Liste nachfragen. Ich denke, dass können wir hier unter uns 
ausmachen. Mit Matthias haben wir ja auch einen kompeteten Kopf, was 
technische Umsetzung und Alternativen angeht.



2.
die Probleme beginnen hingegen dann wenn ich Michaels rechtliche Hinweise 
erstnehme (und das tue ich), denn dann muss ich mich damit auseinandersetzen 
das ich rechtlichen Beistand brauche und das ich Geld brauche den zu bezahlen.
Dafür viele mir ein (wie schon geschrieben) Betroffene anzuschreiben und die 
Öffentlichkeit zu informieren und zu versuchen dieses Geld z.B durch 
Crowdfunding zu beschaffen.
Das aber tue ich nicht als "Jörg", die Privatperson, sondern das ist eine 
Aufgabe für die Gemeinschaft bzw. für Jörg und andere von der Gemeinschaft dafür 
aktzeptierte/beauftragte Personen.


WTF? Rechtlichen Beistand? Bezahlen?
Hier komme ich nicht mehr mit.


Ich kann Dir aber sagen das ich demnächst Dir und einigen Anderen eine Email 
schicken werde, an der ich schon knapp zwei Wochen rumschreibe und in der es um 
derart Dinge geht wie Du sie hier beschreibst und wo ich handeln möchte aber 
auch Unterstützung brauche.
Vielleicht renne ich da ja offene Türen ein, wir werden sehen.


Dann möchte ich Dich bitten, eines zu berücksichtigen: In der Kürze 
liegt die Würze und Time Is Money.


Sorry, bitte nicht zu persönlich nehmen, aber Deine Mails sind oft doch 
recht lang. Wobei ich denke, dass das sicher auch kürzer geht.


Marcus


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

Re: [PROPOSAL] Managing branches for future releases

[Marcus]

Am 27.10.2017 um 23:28 schrieb Peter Kovacs:

Disclaimer:
I do not claime that one solution is the ultimate solution over the
other.

But I would like to explain my approach as long as it takes until
everybody says he understood what I am suggesting. Nothing more nothing
less. No religeous war is intended or whished from my side.
end disclaimer.

Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:

Why do you think it is a problem to go by state?


I cannot see what is behind the names. "test" - from what? Is it
still
for 4.1.x or the new 4.2.0 or what? I really think it is not clear
for
everyone.


[ looong mail]

So I hope this rather lengthy email is explaining all stuff.
I hope I did not scare anyone with this lengthy explanation now.


sorry, but yes.

At the moment I've not the time and mood to read and understand such 
long mails. So, please don't expect an answer from me.


If the majority of the community is supporting your 
proposal/suggestion/..., then fine.


Marcus


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

Re: [PROPOSAL] Managing branches for future releases

[Peter Kovacs]

Disclaimer:
I do not claime that one solution is the ultimate solution over the
other.

But I would like to explain my approach as long as it takes until
everybody says he understood what I am suggesting. Nothing more nothing
less. No religeous war is intended or whished from my side.
end disclaimer.

Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
> > Why do you think it is a problem to go by state?
> 
> I cannot see what is behind the names. "test" - from what? Is it
> still 
> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
> for 
> everyone.
It is a life cyle model. You do not need to know a release number.
A release number does tell nothing.
A life Cycle state tells you exactly which state the Product is in.

DEV: It is under development. The code can have serious bugs, break.
But can also have the newst feature that may only partial implemented.
In general the code is good enough that it compiles on the dev
machines.

TEST: Often revered to unstable.
The Code is in a feature freeze. It recieves bugfixes, that stabilize
the Code until it reaches the maturity that we expect from it. TEST
unlike DEV takes picks only new features up at a certain time.
Usually after the Code has reached a maturity state.


Release: often reverred to Stable.
The branch that only contains best possible code, to have transperency.
It also is the source to give people a clear state what is changing
from one change to the next.

hotfix, means maintenance:
This should be an exception. When we feel we need to fix something on
release level, because we missed a bug in the maturity phase.

It is a complete different development model. We can use Release
numbers to name a specific cycle. But we control the code not by that
number. We could give it also a Name like "Eternia Version" Would have
the same meaning.

Let me draw a picture, a fantasy example for illustration:
Time >
by live cycle:
  4.1.4   4.1.5
hotfix  -x--x---++--x--x---x+  4.2.0   
Release V+--V---A-
  born:4.2.0   every x here a bugfix born:5.0.0
   
Test---A--x---x-x--x--x---xx--x-+-A---x--x---x-
Dev xx-+-xxx-x--V-+
   PSQL1&2  OOXML   Googlestuff  Root-lib| fix integration
video feature

by release Number:
   PSQL1&2  OOXML   Googlestuff  Root-lib  Sience-interface
trunc -x--xx-+-xx---x-x--x--xx--xx-x+-+--x--x---x-
4.1.4 -x--x---+
4.1.5 +--x--x---x+
4.2.0+-xx---x-x--x--x---xx--x-+
5.0.0 +---x--x---x-

The above example does not break any history. You have a clear state,
on the advancement of the code.
You can compare at any given time the code (I.E. using fisheye). And
you can archieve by time.
In the above model we restrict sharing of changes to certain moments of
time. So the state is always defined.

The lower example due the nature of the approach you have in each
branch a single "fork". The advantage is that you can maintain each
Version from the other. You can also reintegrate a external Fork based
on someotherworks with ease.
But comparing branches is not guaranteed, since they are disconected to
each other. Both could be potential be maintained.
Plus at any moment you can have bugs or features introduce to your
branch, as you like, but probably it is not intended.
Archiving is done by time on trunc, and by release on branche. Getting
time and branch together again might be difficult. Maybe we could
archieve both if we go by time and branch so only complete branches are
saved.

Of course a lot of things assumed here is pure agreement and disciplin.
However I do not see any benefit to us in maintaining each version as
an own branch, since we do not want to maintain the branches.
As you see in the Picture.

It is the methology of thinging. In released based production it is of
course dreadfull to mix branches, because you do your controling by
release numbering.
In my suggested model you do not controlling by a release number but by
state of the code. by which we push our core value "stability over
Feature" into our steering centre.

Also we would like to have almost none hotfixes. Maybe they can be done
as branches  seperatly since there it can realy get confusing which
state a hotfix branch is in. And we need it only for ensuring that fix
does not break anything else. So normaly hoitfix brnches have a short
live period.

Also some thoughts about Release number:
The methology of Agile programming is often reduced to release often.
Which may translate to the idea that release number needs to rattle up.
(Firefox anyone?)
I think it is a stupid Idea, and does not work. It comes from an aera
when Versionening systems 

Re: Korrektur der Seite http://www.openoffice.org/de/dev/pre_submission_de.html

[Jörg Schmidt]

Hallo Mathias, 

> From: Matthias Seidel [mailto:matthias.sei...@hamburg.de] 

> >> da die Links größtenteils ins Nichts führt.
> > Sorry, aber dann lass uns die Links wieder richtig legen 
> das sie funktinieren, denn es handelt sich um wichtigen 
> Content, Das ist hier auch ausführlich in der deutschen 
> Community diskutiert worden.
> 
> Du hast Zugang zum CMS, kein Problem.

OK, ich werde versuchen das in Ordnung zu bringen, aber bitte lass mir etwa 
Zeit.


Außerdem:
bitte entschuldige wenn meine letzte Email wohl etwas forsch war, da tut mir 
leid. Leider neige ich dazu häufig etwas forsch zu formulieren, was eigentlich 
nur Offenheit ist, aber was häufig anders rüberkommt.

Frag ggf. Jan ;-) ... denn der kennt meine Art und wird Dir wohl bestätigen das 
das nicht so gemeint ist wie es sich gelegentlich anhört, denn ich wäre betrübt 
wenn ich jetzt durch eine unbedachte Mail Dich verärgert hätte, umso mehr als 
ich Dic auf der internationalen Liste als einen der Aktiven erlebew die 
derzeitig das Projekt aus einer gewissen Stagnation wieder zur mehr Aktivität 
führen.


> Aber geändert hat niemand etwas?

Naja, mit meinen Worten gesprochen, deshalb weil wir uns im Klaren waren nicht 
annährernd genug Kapazitäten zu haben die Seite in ansehbarer Zeit so 
aktualisieren zu können. Gleichzeitig wären partielle Änderungen nur Stückwerk 
gewesen und da hatten wir leider auch Raphaels Tun noch vor Augen, der zwar 
schnell die Optik der Startseite verbessert hat, uns dann aber mit 
Detailarbeiten einfach allein lies und diese Detailarbeiten waren gerade nicht 
optional sondern betrafen Links die wir wieder hinbiegen mussten.


Lass mich bitte sagen:
Die Diskussion auf der internationalen dev fand ich prima und konstruktiv, und 
es war letztlich überhaupt nicht schlimm das die Seite gelöscht war, denn das 
Wiederherstellen war ja schnell erlegt, auch fand ich es unwichtig das unsere 
Einschätzung der Aktualität der Seite etwas differierte, dennich kann mich da 
unproblematisch auch mit Deiner Einschätzung anfrenden.

Mein Ärger entstand da wo Du heute auf der de-dev schriebst das Du offenbar 
eine _größere_ Anzahl von Seiten verschoben hast, augenscheinlich ohne das Du 
davon irgendwen informiert hast. 
Selbst eine ganz kurze Info, hier schnell auf die de-dev geschrieben hätte 
notfalls gereicht, aber garkeine Info ist wirklich schlecht.

Mir wurde beim Lesen Deiner Mail auch bewusst das all die Fälle der letzten 
Zeit, wo ich den Eindruck hatte es wären Seiten weg, aber mir das 
stillschweigend damit erklärte das das wohl Fehlfunktionen im CMS wären, wohl 
darauf zurückzuführen sind das Du die Seiten verschoben hast. Das das die 
Ursache sein könnte kam mir aber bis zu Deinem Post garnicht in den Sinn, 
weshalb ich auch bisher nicht 'in die Runde' gefragt hatte ob irgendwer an der 
Webseite gearbeitet hat. 
Das ich aktuell doch allgemein fragte war nur der besonderen Wichtigkeit der 
einen konkreten Seite geschuldet.


Gruß
Jörg


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

Re: [Issue 127574] New: Out of date OSX version

[Marcus]

Please remember to use something like the follwoing to provide a commit 
message that is automatically logged into the BZ issue:


#i123456# 

Marcus



Am 27.10.2017 um 22:56 schrieb Dave Fisher:

Hi -

I fixed this issue. I just created a BZ id - dave2w...@comcast.net - would 
someone grant me PMC rights.

Thanks,
Dave


On Oct 27, 2017, at 1:41 PM, bugzi...@apache.org wrote:

https://bz.apache.org/ooo/show_bug.cgi?id=127574

  Issue ID: 127574
Issue Type: DEFECT
   Summary: Out of date OSX version
   Product: Infrastructure
   Version: current
  Hardware: All
OS: All
Status: CONFIRMED
  Severity: Normal
  Priority: P5 (lowest)
 Component: Website general issues
  Assignee: iss...@openoffice.apache.org
  Reporter: s...@apache.org
  Target Milestone: ---

https://www.openoffice.org/porting/mac/
says that AOO supports only up to OSX 10.10 (Yosemite)

However AFAIK it also supports Sierra (10.12)
(and El Capitan - 10.11)

Also I think Apple are now calling it macOS



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

Re: [Issue 127574] New: Out of date OSX version

[Andrea Pescetti]

Dave Fisher wrote:

I just created a BZ id - dave2w...@comcast.net - would someone grant me PMC 
rights.


Use your @apache.org e-mail for the Bugzilla account and you will get 
them automatically (of course they can be granted manually too, by a 
Bugzilla admin, if you prefer to use a non-ASF mail instead).


Regards,
  Andrea.

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

Re: [Issue 127574] New: Out of date OSX version

[Dave Fisher]

Hi -

I fixed this issue. I just created a BZ id - dave2w...@comcast.net - would 
someone grant me PMC rights.

Thanks,
Dave

> On Oct 27, 2017, at 1:41 PM, bugzi...@apache.org wrote:
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127574
> 
>  Issue ID: 127574
>Issue Type: DEFECT
>   Summary: Out of date OSX version
>   Product: Infrastructure
>   Version: current
>  Hardware: All
>OS: All
>Status: CONFIRMED
>  Severity: Normal
>  Priority: P5 (lowest)
> Component: Website general issues
>  Assignee: iss...@openoffice.apache.org
>  Reporter: s...@apache.org
>  Target Milestone: ---
> 
> https://www.openoffice.org/porting/mac/
> says that AOO supports only up to OSX 10.10 (Yosemite)
> 
> However AFAIK it also supports Sierra (10.12)
> (and El Capitan - 10.11)
> 
> Also I think Apple are now calling it macOS
> 
> --
> You are receiving this mail because:
> You are the assignee for the issue.



signature.asc
Description: Message signed with OpenPGP

Re: SDBC developments and the JDBC driver port

[Dave Fisher]

Hi Matthias,

It is no longer easy to get EOLed JDKs. You have to pay Oracle for support. You 
have to pay Apple to get the old SDKs you need for Mac OpenOffice. I don’t mind 
paying Apple as I have the goal of trying to sign the Application to avoid 
Gatekeeper. I have the Xcode stuff and I’ve found JDK 6s. If a friend has the 
the JDK7 in /Libary/Java/JavaVirtualMachines/ and would ship it to me that 
would be AWESOME.

In my builds with JDK6 I am now having trouble with Help.

There is a lot wrong with the Building guides. Too many options - MacPort or 
Brew, etc.

I’ve spent about 16 hours this week on this and … I am about done with it.

Regards,
Dave

> On Oct 27, 2017, at 1:22 PM, Matthias Seidel  
> wrote:
> 
> Am 27.10.2017 um 21:19 schrieb Dave Fisher:
>> Hi -
>> 
>> As an aside I am working on Mac builds for 4.1.4 and it looks like uno does 
>> not like JDK 8+, something to do with javadocs, but not sure as I am looking 
>> for JDK7 …
> 
> Do you need the SDK?
> 
> From our release notes (Known Issues):
> 
> For developers:
> The OpenOffice SDK won't build with Java 8. Either build with --disable-odk 
> or see the dev list archives for possible solutions.
> Either go with Java 7 or use --disable-odk as configure switch.
> 
> Regards, Matthias
> 
>> 
>> If I can get things working I will be willing to try builds for you on trunk 
>> or a branch as you make changes.
>> 
>> Regards,
>> Dave
>> 
>>> On Oct 27, 2017, at 12:05 PM, Peter Kovacs  
>>>  wrote:
>>> 
>>> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
 Hi
>>> *wave*
 To update you on my development efforts, the PostgreSQL driver
 continues to
 advance. I recently added views and fixed a major problem where
 "Refresh
 Tables" causes everything done to tables from then on to fail (as
 Base
 keeps holding references to the old table/view/user/group containers,
 so
 container contents may change, but containers themselves must persist
 for
 the lifetime of the driver).
 
 I did however run into a disturbing bug. When my SDBC driver in Java
 calls
 XStatement.close() on our underlying SDBC to JDBC converter driver
 written
 in C++, and it calls java.sql.Statement.close() in the PostgreSQL
 JDBC
 driver, I get a reproducible unchecked
 java.lang.IllegalClassChangeError
 exception. After hours of debugging I did manage to work around it,
 by
 getting a new methodID before every JNI call to close() instead of
 caching
 it in a static global variable, which shouldn't be required as
 methodIDs
 are meant to persist for the lifetime of the JVM. Either it's a bug
 in the
 JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
 corruption or the like :(.
 
 Instead of committing that senseless methodID hack, I've decided to
 port
 the SDBC-JDBC driver to Java, which should make memory corruption
 impossible and any debugging and future maintenance much easier (the
 JNI
 code to call into Java is exceptionally complex and ugly, and
 compiles into
 a 15 MB pig of a library in a debug build!). Nothing is lost by using
 Java,
 as the C++ driver can't load JDBC drivers without Java either, and
 performance should be identical as the slow boundary between native
 and
 Java is crossed an equal number of times, the crossing just happens
 in the
 JNI bridge under main/bridges instead of the SDBC-JDBC driver.
>>> WTF?!
 So far the reusable parts of the PostgreSQL driver have been split
 off into
 a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
 itself
 currently in the painful phase of dealing with JDBC classloading and
 class
 caching. The final architecture should be something along these
 lines:
 
 The rest of AOO (mostly C++)
 |  |
 |UNO   | UNO
 |  v
 |  PostgreSQL SDBC driver (Java)
 |  | |
 |  | UNO | UNO
 v  v v
 SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
 |  |  |
 | Java | Java | C
 v  v  v
 other   PostgreSQL JDBC  PostgreSQL ODBC
 JDBC driver (Java)driver (C)
 drivers |  |
| network I/O  |
v  v
PostgreSQL server
 
>>> +1 Looks like a clean architecture, LIKE ! S2
 I've also already developed considerable support code for Java
 (logging,
 resource bundles, data structure manipulation), all ported from the
 support
 code for C++ under main/comphelper. Since it is generally useful to
 other
 Java UNO modules, should I move it elsewhere, such as
 main/javaunohelper
 which already contains similar 

Re: SDBC developments and the JDBC driver port

[Matthias Seidel]

Am 27.10.2017 um 21:19 schrieb Dave Fisher:
> Hi -
>
> As an aside I am working on Mac builds for 4.1.4 and it looks like uno does 
> not like JDK 8+, something to do with javadocs, but not sure as I am looking 
> for JDK7 …

Do you need the SDK?

From our release notes (Known Issues):

For developers:

  * The OpenOffice SDK won't build with Java 8. Either build with
--disable-odk or see the dev list archives for possible solutions.

Either go with Java 7 or use --disable-odk as configure switch.

Regards, Matthias


>
> If I can get things working I will be willing to try builds for you on trunk 
> or a branch as you make changes.
>
> Regards,
> Dave
>
>> On Oct 27, 2017, at 12:05 PM, Peter Kovacs  wrote:
>>
>> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
>>> Hi
>> *wave*
>>> To update you on my development efforts, the PostgreSQL driver
>>> continues to
>>> advance. I recently added views and fixed a major problem where
>>> "Refresh
>>> Tables" causes everything done to tables from then on to fail (as
>>> Base
>>> keeps holding references to the old table/view/user/group containers,
>>> so
>>> container contents may change, but containers themselves must persist
>>> for
>>> the lifetime of the driver).
>>>
>>> I did however run into a disturbing bug. When my SDBC driver in Java
>>> calls
>>> XStatement.close() on our underlying SDBC to JDBC converter driver
>>> written
>>> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
>>> JDBC
>>> driver, I get a reproducible unchecked
>>> java.lang.IllegalClassChangeError
>>> exception. After hours of debugging I did manage to work around it,
>>> by
>>> getting a new methodID before every JNI call to close() instead of
>>> caching
>>> it in a static global variable, which shouldn't be required as
>>> methodIDs
>>> are meant to persist for the lifetime of the JVM. Either it's a bug
>>> in the
>>> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
>>> corruption or the like :(.
>>>
>>> Instead of committing that senseless methodID hack, I've decided to
>>> port
>>> the SDBC-JDBC driver to Java, which should make memory corruption
>>> impossible and any debugging and future maintenance much easier (the
>>> JNI
>>> code to call into Java is exceptionally complex and ugly, and
>>> compiles into
>>> a 15 MB pig of a library in a debug build!). Nothing is lost by using
>>> Java,
>>> as the C++ driver can't load JDBC drivers without Java either, and
>>> performance should be identical as the slow boundary between native
>>> and
>>> Java is crossed an equal number of times, the crossing just happens
>>> in the
>>> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
>> WTF?!
>>> So far the reusable parts of the PostgreSQL driver have been split
>>> off into
>>> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
>>> itself
>>> currently in the painful phase of dealing with JDBC classloading and
>>> class
>>> caching. The final architecture should be something along these
>>> lines:
>>>
>>> The rest of AOO (mostly C++)
>>> |  |
>>> |UNO   | UNO
>>> |  v
>>> |  PostgreSQL SDBC driver (Java)
>>> |  | |
>>> |  | UNO | UNO
>>> v  v v
>>> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
>>> |  |  |
>>> | Java | Java | C
>>> v  v  v
>>> other   PostgreSQL JDBC  PostgreSQL ODBC
>>> JDBC driver (Java)driver (C)
>>> drivers |  |
>>>| network I/O  |
>>>v  v
>>>PostgreSQL server
>>>
>> +1 Looks like a clean architecture, LIKE ! S2
>>> I've also already developed considerable support code for Java
>>> (logging,
>>> resource bundles, data structure manipulation), all ported from the
>>> support
>>> code for C++ under main/comphelper. Since it is generally useful to
>>> other
>>> Java UNO modules, should I move it elsewhere, such as
>>> main/javaunohelper
>>> which already contains similar support code, or is there somewhere
>>> better?
>> I think javaunohelper makes more sense to me then comphelper. However I
>> do not like "helper" modules at all, since they express patchwork like
>> "I do magic" kind of concept.
>>
>> My personal favourite would be to have modules that are called what
>> they do:
>> - logging, ressourcemanagement, structure managment (or something that
>> line) And that we end up with maybe more self describing architecture.
>>
>>> There are also some API-changing improvements I would like to make to
>>> main/javaunohelper and/or main/ridljar. Is it ok to do those in
>>> trunk? Are
>>> Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1
>>> and
>>> 4.2?
>> I would say go for it as long as they compile for you.  ut thats only
>> me. Would not rate my opinion high.
>>
>> All the Best
>> Peter
>>
>> 

Re: Organisation der Community war: Was können wir gegen Trittbrettfahrer tun?

[Jörg Schmidt]

> From: Marcus [mailto:marcus.m...@wtnet.de] 
> Sent: Friday, October 27, 2017 6:23 PM
> To: dev-de@openoffice.apache.org
> Subject: Re: Organisation der Community war: Was können wir 
> gegen Trittbrettfahrer tun?
> 
> Dieser Post ist allgemein zu sehen und nicht speziell als 
> Antwort auch 
> Michael's Post:
> 
> Ich lese hier viel von "Apache muss mal ...", "Apache sollte ...", 
> "Entscheidung von Apache nötig ...".
> 
> Das sieht für mich immer so aus, also ob man erwartet, dass 
> etwas getan 
> oder entschieden wird, bevor man selber etwas macht.

Dann darf ich Dir versichern das es mir darum _nicht_ geht und das die 
meritokratische Arbeitsweise bei Apache-Projekten verstanden habe.

Meine Möglichkeiten (und die normaler Community-Mitglieder bzw. auch Committer) 
enden hingegen da wo es z.B. gilt im Namen des Projektes tätig zu werden.
Es ist nicht möglich lokale Öffentlichkeits-/Pressearbeit zu betreiben indem 
man versucht die eigene Meinung kundzutun, sondern dazu braucht es eine 
Legitimation, zumindest ausdrücklich seitens der Community, nach dem was man 
mir seit Jahren sagt, aber auch von Apache.

Gerade unser schlechtes Abscheiden in den deutschen Medien hat eine Ursache: es 
ist niemand da der offiziell Kontakt herstellt und Kontakt hält. Aber nur 
dadurch werden wir für die Medienvertreter präsent und sie werden uns 
entsprechend in ihren Veröffentlichungen berücksichtigen und/oder um z.B. 
Interviews oder Artikel bitten die uns als Community helfen bekannter zu werden.

> Natürlich gibt es Regeln, wie man hier arbeiten kann. Das 
> dient aber der 
> Organisation und Struktur, damit es nicht ganz im Chaos versinkt.

Diese Regeln sind mir bekannt und die meine ich nicht.

> - Willst Du, dass eine Webseite anders aussieht/anderen Text hat
> --> mach es. *)

nun ja, ich würde da (ganz freiwillig) zumindest(*) den Weg des lazy consensus 
gehen bevor ich Hand anlege (es sei den es ginge nur um eine Bagatelle), denn 
dieser Weg ist etwas was ich sehr sinnvoll finde um einerseits schnell handeln 
zu können, andererseits aber nichts im Alleingang zu tun.

(*)
bei größeren Dingen würde ich vorher lieber eine normale Diskussion anstoßen

> Willst Du, dass Bad Boys keine Malware mehr verteilen
> --> fang an, etwas dagegen zu tun.
> 
> Willst Du, dass die deutsche Presse wieder mehr über AOO schreiben,
> dann ...
> 
> Oder kurz:
> Willst Du .., mach es ...

1.
genau das hatte ich vor, z.B. der Thread hier diente mir eigentlich dazu mit 
Vertretern der de-Community zu diskutieren ob wir nicht gemäß meines Vorschlags 
(auf der internationalen dev-Liste Pressemeldung dazu anregen) verfahren wollen.
Nicht ein Wort dazu jedoch von Michael oder Dir ... war mein Vorschlag zu 
versteckt? ... bist Du nicht einverstanden? ... ist das Thema zu banal?

2.
die Probleme beginnen hingegen dann wenn ich Michaels rechtliche Hinweise 
erstnehme (und das tue ich), denn dann muss ich mich damit auseinandersetzen 
das ich rechtlichen Beistand brauche und das ich Geld brauche den zu bezahlen.
Dafür viele mir ein (wie schon geschrieben) Betroffene anzuschreiben und die 
Öffentlichkeit zu informieren und zu versuchen dieses Geld z.B durch 
Crowdfunding zu beschaffen.
Das aber tue ich nicht als "Jörg", die Privatperson, sondern das ist eine 
Aufgabe für die Gemeinschaft bzw. für Jörg und andere von der Gemeinschaft 
dafür aktzeptierte/beauftragte Personen.

Mö, ich bin nicht zu schüchtern, nur sobald es um solche Dinge geht will ich 
privat und ehrenamtlich strikt trennen, weil erstens die Community ein 
(moralisches) Recht darauf hat das ich mich so verhalte und es zweitens nach 
meinen eigenen Wertmaßstäben der einzig richtige Weg ist.


Du siehst also, meine 'Gründe' sind andere als Du wohl dachtest. 


Ich kann Dir aber sagen das ich demnächst Dir und einigen Anderen eine Email 
schicken werde, an der ich schon knapp zwei Wochen rumschreibe und in der es um 
derart Dinge geht wie Du sie hier beschreibst und wo ich handeln möchte aber 
auch Unterstützung brauche.
Vielleicht renne ich da ja offene Türen ein, wir werden sehen.



Gruß
Jörg


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

Re: SDBC developments and the JDBC driver port

[Marcus]

Am 27.10.2017 um 20:44 schrieb Matthias Seidel:

Am 27.10.2017 um 11:18 schrieb Damjan Jovanovic:


To update you on my development efforts, the PostgreSQL driver continues to
advance. I recently added views and fixed a major problem where "Refresh
Tables" causes everything done to tables from then on to fail (as Base
keeps holding references to the old table/view/user/group containers, so
container contents may change, but containers themselves must persist for
the lifetime of the driver).

...


That sounds great! But I understand only a fraction of it... ;-)

Keep up the good work!


this is also my obstacle.

I don't know what this all means. So, I'm mostly silent when it comes to 
such mails. Please forbear with the non-coders. ;-)


But it feels really good when we can see work in the code that is more 
than a little fix.


Therefore thanks a lot for your efforts. :-)
And keep up the great work even when you don't get the feedbak or 
answers that you would expect - or when it takes some time.


Marcus


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

Re: SDBC developments and the JDBC driver port

[Dave Fisher]

Hi -

As an aside I am working on Mac builds for 4.1.4 and it looks like uno does not 
like JDK 8+, something to do with javadocs, but not sure as I am looking for 
JDK7 …

If I can get things working I will be willing to try builds for you on trunk or 
a branch as you make changes.

Regards,
Dave

> On Oct 27, 2017, at 12:05 PM, Peter Kovacs  wrote:
> 
> Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
>> Hi
> *wave*
>> 
>> To update you on my development efforts, the PostgreSQL driver
>> continues to
>> advance. I recently added views and fixed a major problem where
>> "Refresh
>> Tables" causes everything done to tables from then on to fail (as
>> Base
>> keeps holding references to the old table/view/user/group containers,
>> so
>> container contents may change, but containers themselves must persist
>> for
>> the lifetime of the driver).
>> 
>> I did however run into a disturbing bug. When my SDBC driver in Java
>> calls
>> XStatement.close() on our underlying SDBC to JDBC converter driver
>> written
>> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
>> JDBC
>> driver, I get a reproducible unchecked
>> java.lang.IllegalClassChangeError
>> exception. After hours of debugging I did manage to work around it,
>> by
>> getting a new methodID before every JNI call to close() instead of
>> caching
>> it in a static global variable, which shouldn't be required as
>> methodIDs
>> are meant to persist for the lifetime of the JVM. Either it's a bug
>> in the
>> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
>> corruption or the like :(.
>> 
>> Instead of committing that senseless methodID hack, I've decided to
>> port
>> the SDBC-JDBC driver to Java, which should make memory corruption
>> impossible and any debugging and future maintenance much easier (the
>> JNI
>> code to call into Java is exceptionally complex and ugly, and
>> compiles into
>> a 15 MB pig of a library in a debug build!). Nothing is lost by using
>> Java,
>> as the C++ driver can't load JDBC drivers without Java either, and
>> performance should be identical as the slow boundary between native
>> and
>> Java is crossed an equal number of times, the crossing just happens
>> in the
>> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
> WTF?!
>> 
>> So far the reusable parts of the PostgreSQL driver have been split
>> off into
>> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
>> itself
>> currently in the painful phase of dealing with JDBC classloading and
>> class
>> caching. The final architecture should be something along these
>> lines:
>> 
>> The rest of AOO (mostly C++)
>> |  |
>> |UNO   | UNO
>> |  v
>> |  PostgreSQL SDBC driver (Java)
>> |  | |
>> |  | UNO | UNO
>> v  v v
>> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
>> |  |  |
>> | Java | Java | C
>> v  v  v
>> other   PostgreSQL JDBC  PostgreSQL ODBC
>> JDBC driver (Java)driver (C)
>> drivers |  |
>>| network I/O  |
>>v  v
>>PostgreSQL server
>> 
> +1 Looks like a clean architecture, LIKE ! S2
>> I've also already developed considerable support code for Java
>> (logging,
>> resource bundles, data structure manipulation), all ported from the
>> support
>> code for C++ under main/comphelper. Since it is generally useful to
>> other
>> Java UNO modules, should I move it elsewhere, such as
>> main/javaunohelper
>> which already contains similar support code, or is there somewhere
>> better?
> I think javaunohelper makes more sense to me then comphelper. However I
> do not like "helper" modules at all, since they express patchwork like
> "I do magic" kind of concept.
> 
> My personal favourite would be to have modules that are called what
> they do:
> - logging, ressourcemanagement, structure managment (or something that
> line) And that we end up with maybe more self describing architecture.
> 
>> 
>> There are also some API-changing improvements I would like to make to
>> main/javaunohelper and/or main/ridljar. Is it ok to do those in
>> trunk? Are
>> Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1
>> and
>> 4.2?
> 
> I would say go for it as long as they compile for you.  ut thats only
> me. Would not rate my opinion high.
> 
> All the Best
> Peter
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: SDBC developments and the JDBC driver port

[Peter Kovacs]

Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic:
> Hi
*wave*
> 
> To update you on my development efforts, the PostgreSQL driver
> continues to
> advance. I recently added views and fixed a major problem where
> "Refresh
> Tables" causes everything done to tables from then on to fail (as
> Base
> keeps holding references to the old table/view/user/group containers,
> so
> container contents may change, but containers themselves must persist
> for
> the lifetime of the driver).
> 
> I did however run into a disturbing bug. When my SDBC driver in Java
> calls
> XStatement.close() on our underlying SDBC to JDBC converter driver
> written
> in C++, and it calls java.sql.Statement.close() in the PostgreSQL
> JDBC
> driver, I get a reproducible unchecked
> java.lang.IllegalClassChangeError
> exception. After hours of debugging I did manage to work around it,
> by
> getting a new methodID before every JNI call to close() instead of
> caching
> it in a static global variable, which shouldn't be required as
> methodIDs
> are meant to persist for the lifetime of the JVM. Either it's a bug
> in the
> JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
> corruption or the like :(.
> 
> Instead of committing that senseless methodID hack, I've decided to
> port
> the SDBC-JDBC driver to Java, which should make memory corruption
> impossible and any debugging and future maintenance much easier (the
> JNI
> code to call into Java is exceptionally complex and ugly, and
> compiles into
> a 15 MB pig of a library in a debug build!). Nothing is lost by using
> Java,
> as the C++ driver can't load JDBC drivers without Java either, and
> performance should be identical as the slow boundary between native
> and
> Java is crossed an equal number of times, the crossing just happens
> in the
> JNI bridge under main/bridges instead of the SDBC-JDBC driver.
WTF?!
> 
> So far the reusable parts of the PostgreSQL driver have been split
> off into
> a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is
> itself
> currently in the painful phase of dealing with JDBC classloading and
> class
> caching. The final architecture should be something along these
> lines:
> 
> The rest of AOO (mostly C++)
>  |  |
>  |UNO   | UNO
>  |  v
>  |  PostgreSQL SDBC driver (Java)
>  |  | |
>  |  | UNO | UNO
>  v  v v
> SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
>  |  |  |
>  | Java | Java | C
>  v  v  v
> other   PostgreSQL JDBC  PostgreSQL ODBC
> JDBC driver (Java)driver (C)
> drivers |  |
> | network I/O  |
> v  v
> PostgreSQL server
> 
+1 Looks like a clean architecture, LIKE ! S2
> I've also already developed considerable support code for Java
> (logging,
> resource bundles, data structure manipulation), all ported from the
> support
> code for C++ under main/comphelper. Since it is generally useful to
> other
> Java UNO modules, should I move it elsewhere, such as
> main/javaunohelper
> which already contains similar support code, or is there somewhere
> better?
I think javaunohelper makes more sense to me then comphelper. However I
do not like "helper" modules at all, since they express patchwork like
"I do magic" kind of concept.

My personal favourite would be to have modules that are called what
they do:
- logging, ressourcemanagement, structure managment (or something that
line) And that we end up with maybe more self describing architecture.

> 
> There are also some API-changing improvements I would like to make to
> main/javaunohelper and/or main/ridljar. Is it ok to do those in
> trunk? Are
> Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1
> and
> 4.2?

I would say go for it as long as they compile for you.  ut thats only
me. Would not rate my opinion high.

All the Best
Peter

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

Re: SDBC developments and the JDBC driver port

[Matthias Seidel]

Hi Damjan,

Am 27.10.2017 um 11:18 schrieb Damjan Jovanovic:
> Hi
>
> To update you on my development efforts, the PostgreSQL driver continues to
> advance. I recently added views and fixed a major problem where "Refresh
> Tables" causes everything done to tables from then on to fail (as Base
> keeps holding references to the old table/view/user/group containers, so
> container contents may change, but containers themselves must persist for
> the lifetime of the driver).
>
> ...

That sounds great! But I understand only a fraction of it... ;-)

Keep up the good work!

Regards, Matthias

>
> Damjan
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Korrektur der Seite http://www.openoffice.org/de/dev/pre_submission_de.html

[Matthias Seidel]

Am 27.10.2017 um 20:04 schrieb Jörg Schmidt:
> Hallo Mathias,
>
>> From: Matthias Seidel [mailto:matthias.sei...@hamburg.de] 
>> Sent: Friday, October 27, 2017 5:28 PM
>> Ich würde noch vorschlagen, die komplette rechte Navigation auszublenden,
> für diese _einzelne_ Seite ist mir das natürlich nicht so wichtig, aber die 
> rechte Navigation darf nicht für die komplette de-Seiute entfernt werden 
> solange es keinen Ersatz gibt.
>
>> da die Links größtenteils ins Nichts führt.
> Sorry, aber dann lass uns die Links wieder richtig legen das sie 
> funktinieren, denn es handelt sich um wichtigen Content, Das ist hier auch 
> ausführlich in der deutschen Community diskutiert worden.

Du hast Zugang zum CMS, kein Problem.
Aber bitte nicht nur wieder ausführlich diskutieren...

>
> Mir ist jede Alternative recht, nur der Content muss unbedingt erhalten 
> bleiben.
>
>> In der gesamten Zeit konnte ich keine nennenswerten Aktivitäten 
>> der "Deutschen Community" bzgl. der deutschsprachigen Seiten feststellen.
> richtig, denn es ist ja niemand hier der sich kontinuierlich kümmert.
>
> Mir persönlich ist auch nur bekannt das Raphael vor laaanger Zeit einmal 
> adhoc-Änderungen auf der deutschen Startseite gemacht hat und seitdem habe 
> wohl weitgehend nur ich Detailänderungen auf einigen einzelnen Seiten 
> gemacht, namentlich dann wenn auf unseren Mailinglisten darüber diskutiert 
> worden war oder auch einige Male Berichtigungen/Aktualisierungen auf der 
> Seite der Referenzkunden, wenn es von Denen direkte Bitten um Korrektur gab:
> http://www.openoffice.org/de/marketing/referenzkunden.html
>
> Falls Günter jetzt als Committter aktzeptiert würde, gäbe es zukünftig 
> vielleicht mit Günter zumindest Einen der sich kontinuierlich kümmern wird. 
> imho ist auch gerade Kontinuität wichtig, weil dann leichter Änderungen 
> möglich sind weil jemand den Überblick hat. 
>
>> Google.de lieferte fast ausschließlich Treffer auf total veraltete Inhalte.
> das erstaunt mich etwas, denn bei den meisten Inhalten geht es imho um 
> Formalien, z.B. das Wort "OpenOffice.org", diverse Verlinkungen auf 
> SUN-Seiten und Ähnliches. 
> Beispielsweise erscheint die gesamte Doku veraltet:
> http://www.openoffice.org/de/doc/index.html
>
> ist aber zu 95% aktuell und ist, auf jeden Fall die beste deutsche Doku die 
> derzeitig da ist. 
> Seit etwas über einem Jahr bemühen wir uns seitens des Teams der ProOO-Box (3 
> Leute) die Doku zu aktualisieren und wereden diese dann natürlich asuch auf 
> die OO-Seiten veröffentlichen, leider geht das auch nur langsam voran, weil 
> wir alle 3 berufstätig sind, und z.B. ich bereits regelmäßig 10-15 Stunden 
> pro Woche ehrenamtlich im Forum tätig bin.

Sei versichert, dass auch ich einer regelmäßigen Arbeit nachgehe... ;-)

>
>> wurden sie in ein Unterverzeichnis "Archive" verschoben und 
>> dieses mittels "robots.txt" ausgeblendet.
>   
>> Einzelne Seiten habe ich später wieder aktiviert, so z.B. 
>> https://www.openoffice.org/de/abgezockt/ da diese von pkzip.de aus verlinkt 
>> wird.
>> Das können wir in Zukunft mit entsprechend Seiten auch gerne 
>> wieder tun (wie auch im hier diskutierten Fall).
> Ein Archiv war in der deutschen Community diskutiert und verworfen worden.

Aber geändert hat niemand etwas?

>  
> Ich hätte zumindest erwartet, das solche Dinge dann als lazy consensus auf 
> der Liste behandelt werden, so wie es vorgesehen ist.
>
>> Und ich bin überzeugt, dass es hier weniger um Organisation 
>> als um die Koordination der nun zunehmenden Aktivitäten geht.
> Mir ist die gesamte Organisation der Webseiten egal WENN denn jemand die 
> Fäden in der Hand hielte und zwar dauerhaft und derjenige die Funktion und 
> Konstanz der Seiten 'garantiert'.
>
> Da ich bisher niemanden gesehen habe der das tut muss ich mich natürlich 
> gegen unbesprochene Änderungen deshalb wehren weil auch die Webseiten für 
> mich ein wichtiges tägliches Arbeitsmittel sind wenn ich ehrenamtlich (im 
> Projekt oder im Forum) Anwendern helfe - das ist mein ganzes Anliegen.

Ich halte euch sicher von nichts ab...
Zur Zeit habe ich genügend andere Dinge (für OpenOffice) zu tun,
insofern bin ich froh, wenn ihr euch des Themas zukünftig annehmt.

Gruß, Matthias

>
>
>
> Gruß
> Jörg 
>
>
> -
> To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-de-h...@openoffice.apache.org
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Korrektur der Seite http://www.openoffice.org/de/dev/pre_submission_de.html

[Jörg Schmidt]

Hallo Mathias,

> From: Matthias Seidel [mailto:matthias.sei...@hamburg.de] 
> Sent: Friday, October 27, 2017 5:28 PM

> Ich würde noch vorschlagen, die komplette rechte Navigation auszublenden,

für diese _einzelne_ Seite ist mir das natürlich nicht so wichtig, aber die 
rechte Navigation darf nicht für die komplette de-Seiute entfernt werden 
solange es keinen Ersatz gibt.

> da die Links größtenteils ins Nichts führt.

Sorry, aber dann lass uns die Links wieder richtig legen das sie funktinieren, 
denn es handelt sich um wichtigen Content, Das ist hier auch ausführlich in der 
deutschen Community diskutiert worden.

Mir ist jede Alternative recht, nur der Content muss unbedingt erhalten bleiben.

> In der gesamten Zeit konnte ich keine nennenswerten Aktivitäten 
> der "Deutschen Community" bzgl. der deutschsprachigen Seiten feststellen.

richtig, denn es ist ja niemand hier der sich kontinuierlich kümmert.

Mir persönlich ist auch nur bekannt das Raphael vor laaanger Zeit einmal 
adhoc-Änderungen auf der deutschen Startseite gemacht hat und seitdem habe wohl 
weitgehend nur ich Detailänderungen auf einigen einzelnen Seiten gemacht, 
namentlich dann wenn auf unseren Mailinglisten darüber diskutiert worden war 
oder auch einige Male Berichtigungen/Aktualisierungen auf der Seite der 
Referenzkunden, wenn es von Denen direkte Bitten um Korrektur gab:
http://www.openoffice.org/de/marketing/referenzkunden.html

Falls Günter jetzt als Committter aktzeptiert würde, gäbe es zukünftig 
vielleicht mit Günter zumindest Einen der sich kontinuierlich kümmern wird. 
imho ist auch gerade Kontinuität wichtig, weil dann leichter Änderungen möglich 
sind weil jemand den Überblick hat. 

> Google.de lieferte fast ausschließlich Treffer auf total veraltete Inhalte.

das erstaunt mich etwas, denn bei den meisten Inhalten geht es imho um 
Formalien, z.B. das Wort "OpenOffice.org", diverse Verlinkungen auf SUN-Seiten 
und Ähnliches. 
Beispielsweise erscheint die gesamte Doku veraltet:
http://www.openoffice.org/de/doc/index.html

ist aber zu 95% aktuell und ist, auf jeden Fall die beste deutsche Doku die 
derzeitig da ist. 
Seit etwas über einem Jahr bemühen wir uns seitens des Teams der ProOO-Box (3 
Leute) die Doku zu aktualisieren und wereden diese dann natürlich asuch auf die 
OO-Seiten veröffentlichen, leider geht das auch nur langsam voran, weil wir 
alle 3 berufstätig sind, und z.B. ich bereits regelmäßig 10-15 Stunden pro 
Woche ehrenamtlich im Forum tätig bin.

> wurden sie in ein Unterverzeichnis "Archive" verschoben und 
> dieses mittels "robots.txt" ausgeblendet.

> Einzelne Seiten habe ich später wieder aktiviert, so z.B. 
> https://www.openoffice.org/de/abgezockt/ da diese von pkzip.de aus verlinkt 
> wird.
> Das können wir in Zukunft mit entsprechend Seiten auch gerne 
> wieder tun (wie auch im hier diskutierten Fall).

Ein Archiv war in der deutschen Community diskutiert und verworfen worden.
 
Ich hätte zumindest erwartet, das solche Dinge dann als lazy consensus auf der 
Liste behandelt werden, so wie es vorgesehen ist.

> Und ich bin überzeugt, dass es hier weniger um Organisation 
> als um die Koordination der nun zunehmenden Aktivitäten geht.

Mir ist die gesamte Organisation der Webseiten egal WENN denn jemand die Fäden 
in der Hand hielte und zwar dauerhaft und derjenige die Funktion und Konstanz 
der Seiten 'garantiert'.

Da ich bisher niemanden gesehen habe der das tut muss ich mich natürlich gegen 
unbesprochene Änderungen deshalb wehren weil auch die Webseiten für mich ein 
wichtiges tägliches Arbeitsmittel sind wenn ich ehrenamtlich (im Projekt oder 
im Forum) Anwendern helfe - das ist mein ganzes Anliegen.




Gruß
Jörg 


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

Re: [Build] XCode 8.3.3 / 4.1.4 - quicktime.h header missing

[Dave Fisher]

Hi Jim,

Thanks. Not quite what is in devtools, I’ll adjust.

That said here is something from my system:

$ /usr/libexec/java_home -v 1.7
Unable to find any JVMs matching version "1.7".
/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home

What is yours?

I guess I need to look further back on the legacy code page.

Regards,
Dave

> On Oct 27, 2017, at 10:40 AM, Jim Jagielski  wrote:
> 
> Attached is the build script I've been using (also in devtools/build-scripts):
> it describes the env and the programs installed (and versions)... I do use 
> Java7
> 
> #!/bin/sh
> ### 4.1.2 Script:
> ### 4.1.2 Script: echo "### Configure"
> ### 4.1.2 Script: ./configure \
> ### 4.1.2 Script:  --with-build-version="$(date +"%Y-%m-%d 
> %H:%M:%S (%a, %d %b %Y)")" \
> ### 4.1.2 Script:  --enable-verbose \
> ### 4.1.2 Script:  --enable-category-b \
> ### 4.1.2 Script:  --enable-wiki-publisher \
> ### 4.1.2 Script:  --enable-bundled-dictionaries \
> ### 4.1.2 Script:  --without-stlport \
> ### 4.1.2 Script:  
> --with-dmake-path=/Users/jsc/dev/tools/bin/dmake \
> ### 4.1.2 Script:  --with-epm=/Users/jsc/dev/tools/bin/epm/epm \
> ### 4.1.2 Script:  --with-openldap \
> ### 4.1.2 Script:  
> --with-junit=/Users/jsc/dev/tools/junit/junit-4.11.jar \
> ### 4.1.2 Script:  
> --with-packager-list=/Users/jsc/dev/svn/aoo-build-pack.lst
> ### 4.1.2 Script:  
> --with-jdk-home=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home
>  \
> ### 4.1.2 Script:  
> --with-ant-home=/Users/jsc/dev/tools/apache-ant-1.9.3/dist \
> ### 4.1.2 Script:  --with-lang="kid ast bg ca ca-XR ca-XV cs da 
> de el en-GB en-US es eu fi fr gd gl he hi hu it ja km ko lt nb nl pl pt pt-BR 
> ru sk sl sr sv ta th tr vi zh-CN zh-TW"
> ### 4.1.2 Script:
> ### 4.1.2 Script:
> #
> # Build-script for AOO 4.1.x on OSX 10.12
> #
> # System Setup:
> #  XCode 8.3.3 (Updated w/ https://github.com/devernay/xcodelegacy.git)
> #
> # Local Changes:
> #   MacPorts:
> # o apache-ant (1.9.9)
> # o gnutar (1.29) (symlink gnutar to gtar)
> # o perl5 (perl5.22)
> # o p5-archive-*
> # o p5-lwp-*
> # o p5-xml-parser
> #
> #   Oracle JAVA 1.7 JDK
> #
> #   /usr/local:
> # o dmake
> # 
> http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
> # ./configure --prefix=/usr/local ; make install
> # o epm
> # http://www.msweet.org/files/project2/epm-4.3-source.tar.gz
> # $ ./configure --prefix=/usr/local ; make install
> #
> # o openssl (1.0.2j)
> # https://www.openssl.org/source/openssl-1.0.2j.tar.gz
> # $ export MACOSX_DEPLOYMENT_TARGET=10.7
> # $ ./Configure darwin64-x86_64-cc no-shared --prefix=/usr/local 
> --openssldir=/usr/local ; make install
> #
> #   Env:
> # LIBRARY_PATH=/usr/local/lib
> # C_INCLUDE_PATH=/usr/local/include
> # CPLUS_INCLUDE_PATH=/usr/local/include
> # MACOSX_DEPLOYMENT_TARGET=10.7
> # 
> PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:.
> #
> #   Notes:
> # o openssl required for serf; we build non-shared so all
> #   linkings are to the static libs
> #
> # o JDK 1.7 seems to work better; and it's always best to
> #   have just *one* version of te JDK installed.
> #
> 
> if [ ! -d ../main -o ! -d sal ] ; then
>   echo "CHDIR into AOO's main/ directory first!"
>   exit 1
> fi
> 
> if [ -z "$JAVA_HOME" ] ; then
>   JAVA_HOME=$(/usr/libexec/java_home -v 1.7)
> fi
> if [ ! -d "$JAVA_HOME" ] ; then
>echo "JAVA_HOME not found: $JAVA_HOME"
>exit 1
> fi
> export JAVA_HOME
> echo "JAVA_HOME is: $JAVA_HOME..."
> 
> if [ -z "$ANT_HOME" ] ; then
>   ANT_HOME=/usr/local/share/java/apache-ant
> fi
> if [ ! -d "$ANT_HOME" ] ; then
>echo "ANT_HOME not found: $ANT_HOME"
>exit 1
> fi
> export ANT_HOME
> echo "ANT_HOME is: $ANT_HOME..."
> 
> if [ -z "$JUNIT_PATH" ] ; then
>   JUNIT_PATH=/usr/local/share/java/junit.jar
> fi
> if [ ! -e "$JUNIT_PATH" ] ; then
>echo "JUNIT_PATH not found: $JUNIT_PATH"
>exit 1
> fi
> export JUNIT_PATH
> echo "JUNIT_PATH is: $JUNIT_PATH..."
> 
> if [ ! -e external/unowinreg/unowinreg.dll ] ; then
>   echo "Downloading unowinreg.dll..."
>   curl -o external/unowinreg/unowinreg.dll 
> http://www.openoffice.org/tools/unowinreg_prebuild/680/unowinreg.dll
> fi
> 
> LANGS="ast bg ca ca-XR ca-XV cs da de el en-GB en-US es eu fi fr gd gl he hi 
> hu it ja km ko lt nb nl pl pt pt-BR ru sk sl sr sv ta th tr vi zh-CN zh-TW"
> 
> if [ ! -e configure -o configure.in -nt configure ] ; then
>   echo "Running autoconf..."
>   autoconf || exit 1
> fi
> ./configure   \
>--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") - `uname 
> -sm`" \
>   --with-vendor="Apache OpenOffice Community Build" \
>   

Re: [Build] XCode 8.3.3 / 4.1.4 - quicktime.h header missing

[Jim Jagielski]

Attached is the build script I've been using (also in devtools/build-scripts):
it describes the env and the programs installed (and versions)... I do use Java7

#!/bin/sh
### 4.1.2 Script:
### 4.1.2 Script: echo "### Configure"
### 4.1.2 Script: ./configure \
### 4.1.2 Script:  --with-build-version="$(date +"%Y-%m-%d %H:%M:%S 
(%a, %d %b %Y)")" \
### 4.1.2 Script:  --enable-verbose \
### 4.1.2 Script:  --enable-category-b \
### 4.1.2 Script:  --enable-wiki-publisher \
### 4.1.2 Script:  --enable-bundled-dictionaries \
### 4.1.2 Script:  --without-stlport \
### 4.1.2 Script:  --with-dmake-path=/Users/jsc/dev/tools/bin/dmake 
\
### 4.1.2 Script:  --with-epm=/Users/jsc/dev/tools/bin/epm/epm \
### 4.1.2 Script:  --with-openldap \
### 4.1.2 Script:  
--with-junit=/Users/jsc/dev/tools/junit/junit-4.11.jar \
### 4.1.2 Script:  
--with-packager-list=/Users/jsc/dev/svn/aoo-build-pack.lst
### 4.1.2 Script:  
--with-jdk-home=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home 
\
### 4.1.2 Script:  
--with-ant-home=/Users/jsc/dev/tools/apache-ant-1.9.3/dist \
### 4.1.2 Script:  --with-lang="kid ast bg ca ca-XR ca-XV cs da de 
el en-GB en-US es eu fi fr gd gl he hi hu it ja km ko lt nb nl pl pt pt-BR ru 
sk sl sr sv ta th tr vi zh-CN zh-TW"
### 4.1.2 Script:
### 4.1.2 Script:
#
# Build-script for AOO 4.1.x on OSX 10.12
#
# System Setup:
#  XCode 8.3.3 (Updated w/ https://github.com/devernay/xcodelegacy.git)
#
# Local Changes:
#   MacPorts:
# o apache-ant (1.9.9)
# o gnutar (1.29) (symlink gnutar to gtar)
# o perl5 (perl5.22)
# o p5-archive-*
# o p5-lwp-*
# o p5-xml-parser
#
#   Oracle JAVA 1.7 JDK
#
#   /usr/local:
# o dmake
# 
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
# ./configure --prefix=/usr/local ; make install
# o epm
# http://www.msweet.org/files/project2/epm-4.3-source.tar.gz
# $ ./configure --prefix=/usr/local ; make install
#
# o openssl (1.0.2j)
# https://www.openssl.org/source/openssl-1.0.2j.tar.gz
# $ export MACOSX_DEPLOYMENT_TARGET=10.7
# $ ./Configure darwin64-x86_64-cc no-shared --prefix=/usr/local 
--openssldir=/usr/local ; make install
#
#   Env:
# LIBRARY_PATH=/usr/local/lib
# C_INCLUDE_PATH=/usr/local/include
# CPLUS_INCLUDE_PATH=/usr/local/include
# MACOSX_DEPLOYMENT_TARGET=10.7
# 
PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:.
#
#   Notes:
# o openssl required for serf; we build non-shared so all
#   linkings are to the static libs
#
# o JDK 1.7 seems to work better; and it's always best to
#   have just *one* version of te JDK installed.
#

if [ ! -d ../main -o ! -d sal ] ; then
echo "CHDIR into AOO's main/ directory first!"
exit 1
fi

if [ -z "$JAVA_HOME" ] ; then
JAVA_HOME=$(/usr/libexec/java_home -v 1.7)
fi
if [ ! -d "$JAVA_HOME" ] ; then
echo "JAVA_HOME not found: $JAVA_HOME"
exit 1
fi
export JAVA_HOME
echo "JAVA_HOME is: $JAVA_HOME..."

if [ -z "$ANT_HOME" ] ; then
ANT_HOME=/usr/local/share/java/apache-ant
fi
if [ ! -d "$ANT_HOME" ] ; then
echo "ANT_HOME not found: $ANT_HOME"
exit 1
fi
export ANT_HOME
echo "ANT_HOME is: $ANT_HOME..."

if [ -z "$JUNIT_PATH" ] ; then
JUNIT_PATH=/usr/local/share/java/junit.jar
fi
if [ ! -e "$JUNIT_PATH" ] ; then
echo "JUNIT_PATH not found: $JUNIT_PATH"
exit 1
fi
export JUNIT_PATH
echo "JUNIT_PATH is: $JUNIT_PATH..."

if [ ! -e external/unowinreg/unowinreg.dll ] ; then
echo "Downloading unowinreg.dll..."
curl -o external/unowinreg/unowinreg.dll 
http://www.openoffice.org/tools/unowinreg_prebuild/680/unowinreg.dll
fi

LANGS="ast bg ca ca-XR ca-XV cs da de el en-GB en-US es eu fi fr gd gl he hi hu 
it ja km ko lt nb nl pl pt pt-BR ru sk sl sr sv ta th tr vi zh-CN zh-TW"

if [ ! -e configure -o configure.in -nt configure ] ; then
echo "Running autoconf..."
autoconf || exit 1
fi
./configure   \
--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") - `uname 
-sm`" \
--with-vendor="Apache OpenOffice Community Build" \
--enable-verbose \
--with-openldap \
--enable-category-b \
--enable-bundled-dictionaries \
--enable-wiki-publisher \
--with-junit="$JUNIT_PATH" \
--with-jdk-home="$JAVA_HOME" \
--with-ant-home="$ANT_HOME" \
--with-epm=/usr/local/bin/epm \
--with-dmake-path=/usr/local/bin/dmake \
--without-stlport \
--with-package-format="installed dmg" \
--disable-systray \
--with-alloc=system \
--with-lang="${LANGS}" \
| tee config.out || exit 1

./bootstrap || exit 1
source ./MacOSXX64Env.Set.sh || exit 1
cd instsetoo_native
time perl 

Re: [Build] XCode 8.3.3 / 4.1.4 - quicktime.h header missing

[Dave Fisher]

Hi Jim,

OK. That helped, but now I am stuck because in odk and javadoc generation.

dmake:  Error code 1, while making 
'../../unxmaccx.pro/bin/odkcommon/docs/java/ref/index.html'
dmake:  '../../unxmaccx.pro/bin/odkcommon/docs/java/ref/index.html' removed.

1 module(s):
odk
need(s) to be rebuilt

I think I need to switch to JDK 7, but that is no longer easy. Do you have any 
advice?

Regards,
Dave

> On Oct 27, 2017, at 4:01 AM, Jim Jagielski  wrote:
> 
> I also run from the Terminal... well, iTerm.
> 
>> On Oct 26, 2017, at 8:08 PM, Dave Fisher  wrote:
>> 
>> Downloading the SDK now.
>> 
>> While I wait - I run from terminal are you running elsewhere?
>> 
>>> On Oct 26, 2017, at 4:59 PM, Jim Jagielski >> > wrote:
>>> 
>>> sdk 10.9 lacks Python. No idea why.
>>> 
>>> Install sdk 10.11 and configure should find and use that one.
>>> 
>>> All this is fixed in trunk.
>>> 
 On Oct 26, 2017, at 7:29 PM, Dave Fisher > wrote:
 
 Hi -
 
 Well this is a royal pain to setup.
 
 I’ve done the xcodelegacy and have installed the 10.7 and 10.9 SDKs.
 
 I have a fresh copy of the branch AOO414. I run and now it cannot find 
 python headers.
 
 checking which python to use... compiling against system python 
 (/usr/bin/python)
 compiling against system python (version 2.7)
 checking Python.h usability... no
 checking Python.h presence... no
 checking for Python.h... no
 configure: error: Python headers not found
 
 I need help. What the heck happened to my Python setup?
 
 Thanks,
 Dave
 
> On Oct 26, 2017, at 1:00 PM, Dave Fisher   >> wrote:
> 
> Hi Jim,
> 
> I’m building AOO 4.1.4 using macOS12 library and made it all the way to 
> VCL where I get:
> 
> /Users/davewave/Development/aoo-4.1.4/main/vcl/aqua/source/dtrans/PictToBmpFlt.cxx:34:10:
>  fatal error: 'QuickTime/QuickTime.h' file not found
> #include 
> 
> Do I need to use XCodeLegacy and point to 10.7?
> 
> Regards,
> Dave
> 
>> On Oct 25, 2017, at 12:24 PM, Dave Fisher > > >> wrote:
>> 
>> Hi -
>> 
>> I am now on Xcode 8.3.3. Cleaned up and reset.
>> 
>> I now I’m on an issues with Redland:
>> 
>> configure: error: Raptor  is too old - see http://librdf.org/raptor/ 
>>  > > to get a 2.0.7 or newer
>> dmake:  Error code 1, while making 
>> '../unxmaccx.pro/misc/build/so_configured_so_rasqal'
>> 
>> 1 module(s):
>>  redland
>> need(s) to be rebuilt
>> 
>> Reason(s):
>> 
>> ERROR: error 65280 occurred while making 
>> /Users/davewave/Development/aoo/main/redland/rasqal
>> 
>> When you have fixed the errors in that module you can resume the build 
>> by running:
>> 
>>  build --all:redland
>> 
>> Looking into this it looks bogus and I went past the check and now:
>> 
>> configure: error: Rasqal is not installed or too old - see 
>> http://librdf.org/rasqal/ 
>> > > to get a version in range 0.9.25 to 0.9.99
>> dmake:  Error code 1, while making 
>> '../unxmaccx.pro/misc/build/so_configured_so_redland'
>> 
>> 1 module(s):
>>  redland
>> need(s) to be rebuilt
>> 
>> Reason(s):
>> 
>> ERROR: error 65280 occurred while making 
>> /Users/davewave/Development/aoo/main/redland/redland
>> 
>> When you have fixed the errors in that module you can resume the build 
>> by running:
>> 
>>  build --all:redland
>> 
>> Looks like I have something off in my environment.
>> 
>> Regards,
>> Dave
>> 
>> 
>>> On Oct 25, 2017, at 8:19 AM, Dave Fisher >> >> >> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> Thanks. I have Xcode 9 which has the following:
>>> 
>>> $ xcodebuild -showsdks
>>> iOS SDKs:
>>> iOS 11.0-sdk iphoneos11.0
>>> 
>>> iOS Simulator SDKs:
>>> Simulator - iOS 11.0-sdk iphonesimulator11.0
>>> 
>>> macOS SDKs:
>>> macOS 10.13 -sdk macosx10.13
>>> 
>>> tvOS SDKs:
>>> tvOS 11.0   -sdk appletvos11.0
>>> 
>>> tvOS Simulator SDKs:
>>>   

Re: Organisation der Community war: Was können wir gegen Trittbrettfahrer tun?

[Marcus]

Dieser Post ist allgemein zu sehen und nicht speziell als Antwort auch 
Michael's Post:


Ich lese hier viel von "Apache muss mal ...", "Apache sollte ...", 
"Entscheidung von Apache nötig ...".


Das sieht für mich immer so aus, also ob man erwartet, dass etwas getan 
oder entschieden wird, bevor man selber etwas macht.


Das ist aber nicht Apache. Hier geht es daraum, etwas *selber* zu machen.

Natürlich gibt es Regeln, wie man hier arbeiten kann. Das dient aber der 
Organisation und Struktur, damit es nicht ganz im Chaos versinkt.


- Willst Du, dass eine Webseite anders aussieht/anderen Text hat
--> mach es. *)

Willst Du, dass Bad Boys keine Malware mehr verteilen
--> fang an, etwas dagegen zu tun.

Willst Du, dass die deutsche Presse wieder mehr über AOO schreiben,
dann ...

Oder kurz:
Willst Du .., mach es ...

Natürlich muss man sich öfter mal abstimmen, ob die eigene Gedanken auch 
von anderen mitgetragen werden. Aber das passiert im Project oder PMC. 
Aber nicht allgemein mit Apache.


Das Motto "Just do it" ist manchmal nicht mit Smiley zu sehen, sondern 
absolut ernst gemeint.


Also, wir alle sind ein bisschen Apache. ;-)

*) An Code und Webseite darf natürlich nicht jeder gleich ran wie er 
will. Dafür muss man zeigen, dass man es erst meint und auch länger 
dabei bleibt. Nur dann kann man Committer werden und ohne Hilfe von 
anderen Änderungen in das Repository einchecken.


My 2ct.

Marcus



Am 27.10.2017 um 15:11 schrieb Dr. Michael Stehmann:

Am 27.10.2017 um 14:02 schrieb Jörg Schmidt:


diese Arbeit muss auch lokal geführt werden und dazu braucht es konkrete, 
lokale Ansprechpartner. Das ist eine ganz grundlegende Frage und um das zu 
erreichen müssen lokale Community und PMC zusammenarbeiten um mit Apache zu 
einer diesbezüglichen Lösung zu kommen.


Das gibt es doch schon längst:

Lokale Öffentlichkeitsarbeit in Gestalt von Ständen auf Events wird von
Personen durchgeführt, die sich hierfür auch verantwortlich fühlen.

Diesen redet hinsichtlich der Gestaltung der Stände etc. auch niemand 'rein.

Sie erhalten auf Nachfrage Unterstützung durch die entsprechende Stelle
bei Apache.

Niemand wirft ihnen irgendwelche Knüppel zwischen die Beine (würden sie
sich auch nicht gefallen lassen).

Diese Personen wurden dann in Anerkennung der Bedeutung dieser Arbeit
ins PMC aufgenommen, obwohl sie zu Apache OpenOffice bislang keine
einzige Codezeile beigetragen haben.

Dies wiederum war wohl für Apache eine echte Premiere.

Apache ließ sich auch davon überzeugen, dass Apache als Gesamtheit an
der FOSDEM mit einem Stand vertreten sein sollte. Insoweit war Apache
also bereit, die Erfahrungen und Ratschläge, die vom OpenOffice-Projekt
kamen, zu akzeptieren.

Die vorhandenen Strukturen sind also nur informeller, als dies früher
der Fall war. Im Vordergrund steht mehr die Aufgabe und nicht der Titel
("Ansprechperson für ").

Solltest Du also Pressearbeit im deutschsprachigen Raum für Apache
OpenOffice machen wollen, ist wohl die einzige Konsequenz, mit der Du
seitens Apache zu rechnen hast, dass Du ins PMC von OpenOffice
eingeladen wirst.

Gruß
Michael



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

Re: 4.1.4 virus warning - False positive?

[Rory O'Farrell]

On Fri, 27 Oct 2017 17:55:04 +0200
Matthias Seidel  wrote:

> Am 27.10.2017 um 11:07 schrieb Rory O'Farrell:
> > On Forum today was posted the following from a user
> >
> >> My G-data (my Antivirus software) has reported as follows::
> >> Junkware (PUP): Win32.Adware.Narn.D (Engine B)
> >> Datei: Updater.exe
> >> Verzeichnis: C:\Users\xxx\AppData\Roaming\OpenOffice Updater
> > This is most likely a "false positive" and I have so advised the poster, 
> > but I bring it to the developers' attention just in case.
> 
> Thanks Rory,
> 
> This directory is *not* created by our official build but by a
> repackaged installation from openoffice.de.
> 
> We already had some users reporting virus warnings (Kaspersky) when
> installing this "false" package.
> 
> Regards, Matthias
> 
> > The forum thread is at
> > https://forum.openoffice.org/en/forum/viewtopic.php?f=6=90938=430252
> >
> > Rory
> 
> 

Thank.  I will pass that message on to the poster.
-- 
Rory O'Farrell 

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

Re: 4.1.4 virus warning - False positive?

[Matthias Seidel]

Am 27.10.2017 um 11:07 schrieb Rory O'Farrell:
> On Forum today was posted the following from a user
>
>> My G-data (my Antivirus software) has reported as follows::
>> Junkware (PUP): Win32.Adware.Narn.D (Engine B)
>> Datei: Updater.exe
>> Verzeichnis: C:\Users\xxx\AppData\Roaming\OpenOffice Updater
> This is most likely a "false positive" and I have so advised the poster, but 
> I bring it to the developers' attention just in case.

Thanks Rory,

This directory is *not* created by our official build but by a
repackaged installation from openoffice.de.

We already had some users reporting virus warnings (Kaspersky) when
installing this "false" package.

Regards, Matthias

> The forum thread is at
> https://forum.openoffice.org/en/forum/viewtopic.php?f=6=90938=430252
>
> Rory




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Korrektur der Seite http://www.openoffice.org/de/dev/pre_submission_de.html

[Matthias Seidel]

Am 27.10.2017 um 13:22 schrieb Jörg Schmidt:
> Hallo,
>
> so, die Seite:
> http://www.openoffice.org/de/dev/pre_submission_de.html 
>
> habe ich jetzt aktualisiert, wie versprochen.

Danke dafür!
Ich würde noch vorschlagen, die komplette rechte Navigation
auszublenden, da die Links größtenteils ins Nichts führt.
Das habe ich bei einer anderen Seite
(https://www.openoffice.org/de/foren.html) schon gemacht. Ich kann das
auch gerne übernehmen.

> Meine weiteren Anmerkungen zur Organisation der Arbeit bleiben bestehen, ich 
> kann diesbezüglich aber nichts tun wenn hier kein Feedback kommt.
> Es wäre gut wenn sich Mathias hierzu zu Wort melden würde, denn zwar habe ich 
> mich bemüht das Problem einer nicht-aktuellen Seite im jetzigen Fall 
> kurzfristig zu beseitigen, aber für die Zukunft sollten wir vermeiden das 
> sich das Problem wiederholt das Seiten wegen Nicht-Aktualität abgeschaltet 
> werden müssen.

Hier muss ich mal etwas ausführlicher werden (wer mich kennt, weiß dass
ich mich eigentlich eher kurz fasse):

Als ich mich vor etwas mehr als einem Jahr begann mich stärker für
OpenOffice zu engagieren war die Homepage in einem eher "ungepflegten"
Zustand.

Seitdem habe ich Tonnen von "mixed content" berichtigt, so dass wir nun
tatsächlich bald auf HTTPS umleiten können.
Zusätzlich habe ich in Zusammenarbeit mit Muttersprachlern die Dänische,
Schwedische, Polnische und Koreanische Seite übersetzt.

In der gesamten Zeit konnte ich keine nennenswerten Aktivitäten der
"Deutschen Community" bzgl. der deutschsprachigen Seiten feststellen.
Google.de lieferte fast ausschließlich Treffer auf total veraltete
Inhalte. Um diese Seiten von den Suchergebnissen auszunehmen wurden sie
in ein Unterverzeichnis "Archive" verschoben und dieses mittels
"robots.txt" ausgeblendet.

Einzelne Seiten habe ich später wieder aktiviert, so z.B.
https://www.openoffice.org/de/abgezockt/ da diese von pkzip.de aus
verlinkt wird.
Das können wir in Zukunft mit entsprechend Seiten auch gerne wieder tun
(wie auch im hier diskutierten Fall).

> (Das sich Günter mit dem Gedanken trägt zukünftig vielleicht bei der 
> Aktualisierung von Webseiten zu helfen, ist ein positives Ergebnis dieses 
> Threads, hat aber nichts mit der Frage der Organisation zu tun.)
>

Das ist auf jeden Fall ein erfreuliches Ergebnis!
Und ich bin überzeugt, dass es hier weniger um Organisation als um die
Koordination der nun zunehmenden Aktivitäten geht.

Gruß, Matthias

> Gruß
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-de-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Was können wir gegen Trittbrettfahrer tun?

[Jörg Schmidt]

> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] 

> Siehe beispielsweise Punkt 5.
> 
> Natürlich können wir auch versuchen, Verbraucheraufklärung zu 
> betreiben,
> aber Du weißt doch, wie schwierig die Zusammenarbeit mit der 
> Presse ist.

Aber doch ALLEIN durch UNSERE Schuld. Seit Jahren haben wir uns nicht um 
vernüftigen Kontakt zu den Medien bemüht, warum also könnten wir beklagen das 
die Zusammenarbeit stockt. 

> > Genau das ist es was ich nicht verstehe und was ich leider 
> überall bei AOO sehe, klares Bewusstsein für die Probleme, 
> aber Passivität wenn es darum geht etwas zu tun.
> 
> Wir haben eben nicht mehr die Ressourcen, alle Probleme, die 
> wir sehen,
> auch nur annähernd zu lösen. 

Aber wir handeln gemäß dem 'Apache way' oder etwa nicht? Warum also ist 
Meritokratie an einigen Stellen erwünscht und an anderen Stellen nicht?

> Das ist bedauerlich, aber die Ursachen
> hierfür sind beim besten willen nicht von heute auf morgen zu
> beseitigen. Für die Ursachen sind übrigens IMO die, die dem 
> Projekt treu
> geblieben oder neu hinzu gestoßen sind, am allerwenigsten 
> verantwortlich.

Na das kann ich unterschreiben. Aber WENN Du dieser Meinung bist, warum ziehst 
Du daraus keine Schlussfolgerungen? Warum stehst Du nicht im täglichen 
Projektbetrieb auf Seite Derer die Du hier als 'unschuldig' siehst?

> > In Letzterem will ich genau sein, denn die Community ansich 
> ist garnicht passiv, aber sie wird seit Jahren von Apache 
> ausgebremst wenn es um das konkrete Handeln geht. Mir ist 
> ganz und garnicht klar wovor Apache sich da fürchtet und 
> warum sich Apache als so unflexibel erweist.
> 
> Ich sehe kein "Ausbremsen" seitens Apache.

In zwei Absätzen, jetzt zwei Meinungen, die sich um 180 Grad unterscheiden?

Michael, ich verstehe Dich nicht obwohl ich mir größte Mühe gebe, denn es geht 
um ein gemeinsames Anliegen.

JEDER der die deutsche Community bei OOo erlebt hat weiß was möglich war und 
darf erahnen was auch heute möglich wäre. Einziger Bremser ist Apache, denn 
wenn ich als 50-jähriger Freiberufler mit einem promovierten Rechtsanwalt 
wirklich darüber streiten müsste, das es bespielsweise in Bezug auf die Arbeit 
mit den Medien, das natürlich ein konkreter Verantwortlicher tun muss und der 
dazu angemessene Handlungsmöglichkeiten braucht dann wäre ich im falschen Film.

*DAS* ist das Thema und das ist das Thema seit Jahren und zwar nicht nur in 
Bezug auf Pressearbeit.

> Ich sehe vielmehr dort großes Wohlwollen 

das sehe ich leider NICHT!

Was ich sehe sind fleissige Entwickler, die aber auch unter recht begrenzten 
Möglichkeiten arbeiten müssen, weil Apache es zugelassen hat das wesentliche 
Teile von OO in Händen von IBM lagen und es damit natürlich provoziert hat das 
das Projekt in eine schwierige Lage kommen musste als IBM die Segel gestrichen 
hat.

Heute sind wir gottseidank wieder auf dem richtigen Weg, aber nicht durch 
Apache sondern durch die praktische Arbeit einiger Entwickler.

> Um deren Erledigung sollten wir uns aber als Projektcommunity 
> vorrangig
> bemühen.

Genau das fordere ich doch. 

Es fehlen hier dafür keine Ressourcen sondern es fehlt eine vernünftige 
Regelung von Verantwortlichkeiten, die praktischen Erfordernissen Rechenschaft 
trägt.
Und an genau dieser Stelle erwarte ich das das PMC endlich im Sinne des 
Projektes tätig wird.

Um zu erläuern worum es geht, greife ich einen Punkt raus, nämlich den der 
Öffentlichkeitsarbeit:

diese Arbeit muss auch lokal geführt werden und dazu braucht es konkrete, 
lokale Ansprechpartner. Das ist eine ganz grundlegende Frage und um das zu 
erreichen müssen lokale Community und PMC zusammenarbeiten um mit Apache zu 
einer diesbezüglichen Lösung zu kommen.

Ich erinnere mich noch sehr gut wie Florian einst bei de-OOo mustergültig 
demonstrierte wie eine solcher Ansprechpartner funktionieren muss und was 
dessen Aufgaben sind. 
Und ehe das heute nicht ähnlich wird, wird das nichts und die ganze Arbeit der 
Entwickler kommt nicht in ihrer wirklichen Potenz zum tragen.



Gruß
Jörg


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

Re: [Build] XCode 8.3.3 / 4.1.4 - quicktime.h header missing

[Jim Jagielski]

I also run from the Terminal... well, iTerm.

> On Oct 26, 2017, at 8:08 PM, Dave Fisher  wrote:
> 
> Downloading the SDK now.
> 
> While I wait - I run from terminal are you running elsewhere?
> 
>> On Oct 26, 2017, at 4:59 PM, Jim Jagielski > > wrote:
>> 
>> sdk 10.9 lacks Python. No idea why.
>> 
>> Install sdk 10.11 and configure should find and use that one.
>> 
>> All this is fixed in trunk.
>> 
>>> On Oct 26, 2017, at 7:29 PM, Dave Fisher >> > wrote:
>>> 
>>> Hi -
>>> 
>>> Well this is a royal pain to setup.
>>> 
>>> I’ve done the xcodelegacy and have installed the 10.7 and 10.9 SDKs.
>>> 
>>> I have a fresh copy of the branch AOO414. I run and now it cannot find 
>>> python headers.
>>> 
>>> checking which python to use... compiling against system python 
>>> (/usr/bin/python)
>>> compiling against system python (version 2.7)
>>> checking Python.h usability... no
>>> checking Python.h presence... no
>>> checking for Python.h... no
>>> configure: error: Python headers not found
>>> 
>>> I need help. What the heck happened to my Python setup?
>>> 
>>> Thanks,
>>> Dave
>>> 
 On Oct 26, 2017, at 1:00 PM, Dave Fisher >> wrote:
 
 Hi Jim,
 
 I’m building AOO 4.1.4 using macOS12 library and made it all the way to 
 VCL where I get:
 
 /Users/davewave/Development/aoo-4.1.4/main/vcl/aqua/source/dtrans/PictToBmpFlt.cxx:34:10:
  fatal error: 'QuickTime/QuickTime.h' file not found
 #include 
 
 Do I need to use XCodeLegacy and point to 10.7?
 
 Regards,
 Dave
 
> On Oct 25, 2017, at 12:24 PM, Dave Fisher   >> wrote:
> 
> Hi -
> 
> I am now on Xcode 8.3.3. Cleaned up and reset.
> 
> I now I’m on an issues with Redland:
> 
> configure: error: Raptor  is too old - see http://librdf.org/raptor/ 
>   > to get a 2.0.7 or newer
> dmake:  Error code 1, while making 
> '../unxmaccx.pro/misc/build/so_configured_so_rasqal'
> 
> 1 module(s): 
>   redland
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making 
> /Users/davewave/Development/aoo/main/redland/rasqal
> 
> When you have fixed the errors in that module you can resume the build by 
> running:
> 
>   build --all:redland
> 
> Looking into this it looks bogus and I went past the check and now:
> 
> configure: error: Rasqal is not installed or too old - see 
> http://librdf.org/rasqal/ 
>  > to get a version in range 0.9.25 to 0.9.99
> dmake:  Error code 1, while making 
> '../unxmaccx.pro/misc/build/so_configured_so_redland'
> 
> 1 module(s): 
>   redland
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making 
> /Users/davewave/Development/aoo/main/redland/redland
> 
> When you have fixed the errors in that module you can resume the build by 
> running:
> 
>   build --all:redland
> 
> Looks like I have something off in my environment.
> 
> Regards,
> Dave
> 
> 
>> On Oct 25, 2017, at 8:19 AM, Dave Fisher > > >> wrote:
>> 
>> Hi Jim,
>> 
>> Thanks. I have Xcode 9 which has the following:
>> 
>> $ xcodebuild -showsdks
>> iOS SDKs:
>>  iOS 11.0-sdk iphoneos11.0
>> 
>> iOS Simulator SDKs:
>>  Simulator - iOS 11.0-sdk iphonesimulator11.0
>> 
>> macOS SDKs:
>>  macOS 10.13 -sdk macosx10.13
>> 
>> tvOS SDKs:
>>  tvOS 11.0   -sdk appletvos11.0
>> 
>> tvOS Simulator SDKs:
>>  Simulator - tvOS 11.0   -sdk appletvsimulator11.0
>> 
>> watchOS SDKs:
>>  watchOS 4.0 -sdk watchos4.0
>> 
>> watchOS Simulator SDKs:
>>  Simulator - watchOS 4.0 -sdk watchsimulator4.0
>> 
>> I modified configure to target 10.13 and adjusted the egrep:
>> 
>> sdk_found=`xcodebuild -showsdks | $EGREP "sdk macosx10.(10|11|12|13)" | 
>> sed -e "s/.*sdk //" | head -n1`
>> 
>> Also - 
>> #   sdk_target=10.9  
>>   
>>   sdk_target=10.13
>> 
>> The 

Re: Was können wir gegen Trittbrettfahrer tun?

[Dr. Michael Stehmann]

Hallo,

Am 27.10.2017 um 11:23 schrieb Jörg Schmidt:

>>
>> 5. In Fällen, die als Betrug zulasten der Verbraucher gewertet werden
>> können, ist es jedem unbenommen, die zuständigen Behörden oder
>> nichtstaatlichen Organisationen (Verbraucherverbände etc.) zu
>> informieren und um eine Prüfung der Angelegenheit zu bitten.
> 
> Und wir als Community sollten nichts tun?

Siehe beispielsweise Punkt 5.

Natürlich können wir auch versuchen, Verbraucheraufklärung zu betreiben,
aber Du weißt doch, wie schwierig die Zusammenarbeit mit der Presse ist.

> 
> Genau das ist es was ich nicht verstehe und was ich leider überall bei AOO 
> sehe, klares Bewusstsein für die Probleme, aber Passivität wenn es darum geht 
> etwas zu tun.

Wir haben eben nicht mehr die Ressourcen, alle Probleme, die wir sehen,
auch nur annähernd zu lösen. Das ist bedauerlich, aber die Ursachen
hierfür sind beim besten willen nicht von heute auf morgen zu
beseitigen. Für die Ursachen sind übrigens IMO die, die dem Projekt treu
geblieben oder neu hinzu gestoßen sind, am allerwenigsten verantwortlich.

> In Letzterem will ich genau sein, denn die Community ansich ist garnicht 
> passiv, aber sie wird seit Jahren von Apache ausgebremst wenn es um das 
> konkrete Handeln geht. Mir ist ganz und garnicht klar wovor Apache sich da 
> fürchtet und warum sich Apache als so unflexibel erweist.

Ich sehe kein "Ausbremsen" seitens Apache.

Ich sehe vielmehr dort großes Wohlwollen und eine starke Unterstützung
von OpenOffice. Ja wir bräuchten vielleicht noch mehr Hilfe, aber auch
die Ressourcen von Apache sind begrenzt.

Und wir sollten bedenken, dass wir als Endanwenderprojekt Probleme an
Apache herantragen, für die es bei Apache (noch) keine eingefahrenen
Lösungsverfahren gibt.
> 
> Ressourcen? 
> Wir hätten Ressourcen wenn wir wollten. 
> Wenn ich könnte wie ich wollte würde ich jedenfalls die Betroffenen im Namen 
> der Community anschreiben, mich entschuldigen und sie bitten uns zu helfen 
> gegen die 'Abzocker' vorzugehen, gleichzeitig würde ich Öffentlichkeit an 
> anderen Stellen herstellen und mich ggf. mit Betroffenen anderer Projekte 
> vernetzen. Ich mag nicht glauben das in einer Welt wo es Vertretern von FSF & 
> Co. gelingt sich effektiv gegen Lizenzverletztungen juristisch zu wehren, es 
> uns nicht gelingen kann etwas für betrogene Anwender zu tun.

Dieser Eindruck liegt nur daran, und das sage ich als jemand, der ein
wenig Einblick hat, dass hauptsächlich die Erfolge an die große Glocke
gehängt werden, was verständlich ist, nicht aber die Schwierigkeiten,
Probleme und Mühen der Rechtsverfolgung.

Die Freie-Software-Gemeinschaft hat verschiedene Institutionen und
Gruppen in jahrelanger Arbeit aufgebaut, die Urheberrechtsverletzungen,
bzw. Lizenzverletzungen bearbeiten. Diese Arbeit beruht auf der
Grundlage des Copyleft.

Dennoch beruhen die Erfolge auf dem Engagement Einzelner, die als
Rechteinhaber (Urheber- oder zumindest ausschließliche Nutzungsrechte am
Code) klagebefugt waren.

Die Apache-Lizenz ist aber eine, die solchen juristischen Streitigkeiten
weitmöglichst aus dem Wege gehen möchte.
> 
> und ein persönliches Wort:
> mir tut der Anwender leid und gleichzeitig fühle ich mich tatsächlich 
> beschämt das unseren Anwendern so etwas widerfährt. Und weil ich so empfinde, 
> deshalb ist für mich die Frage so drängend was man tun kann um die Situation 
> zumindest etwas zu verbessern.
> Was ich tun würde hatte ich geschrieben und dafür würde ich mir die 
> Unterstützung der deutschen Community und des PMC wünschen.
> 

Deine Gesinnung (Schutz und Verteidigung der Schwachen und Betrogenen)
ist edel. Verbraucherschutz ist auch notwendig, gehört aber nicht gerade
zu den Kernaufgaben unseres Projektes.

Um deren Erledigung sollten wir uns aber als Projektcommunity vorrangig
bemühen.

Gruß
Michael



signature.asc
Description: OpenPGP digital signature

Re: Was können wir gegen Trittbrettfahrer tun?

[Jörg Schmidt]

> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] 
> Sent: Friday, October 27, 2017 10:18 AM
> To: dev-de@openoffice.apache.org
> Subject: Re: Was können wir gegen Trittbrettfahrer tun?
> 
> 
> 
> Am 26.10.2017 um 20:38 schrieb Günter Feierabend:
> 
> > Tatsächlich weiß ich nicht, inwieweit das Führen des Namens 
> „OpenOffice" im Titel der Internetseite erlaubt ist, wenn 
> diese von Trittbrettfahrern eingerichtet wurde, die nichts 
> mit der offiziellen Seite (egal ob Apache oder damals .org) 
> und der mit ihr verbundenen Arbeit zu tun haben. Dies wird 
> wohl auch mit (nicht-)eingetragenen Marken- oder Produktnamen 
> zusammenhängen?
> > 
> > 
> > 
> > Vielleicht weiß Michael etwas dazu?
> > 
> Nunja:
> 
> 1. Es ist Sache des Rechteinhabers gegen die Verletzung seiner
> Markenrechte oder "unlauteren Wettbewerb" unter Ausnutzung 
> seines guten
> Rufes vorzugehen.
> 
> Rechteinhaber ist, soweit ersichtlich, die ASF.
> 
> 2. Apache hat Regeln aufgestellt, die eine Nutzung ihrer Bezeichnungen
> etc. erlauben. Diese sind wohl als Lizenz zu werten.
> 
> Es wäre daher zunächst im Einzelfall penibel zu prüfen, ob und wodurch
> diese Regeln verletzt wurden.
> 
> 3. Dann ist eine adäquate Reaktion zu überlegen: Eigentlich 
> will man ja
> nicht, dass diese Downloadmöglichkeiten verschwinden, sondern dass die
> Regeln (s.o.) eingehalten werden.
> 
> All' diese Überlegungen und Maßnahmen erfordern Ressourcen.
> 
> 4. Schließlich ist zu bedenken, dass jahrelang die Nutzung einer
> "openoffice"-Domäne durch einen Privaten geduldet wurde, unter der man
> dann das Debiananwenderhandbuch fand.
> 
> 5. In Fällen, die als Betrug zulasten der Verbraucher gewertet werden
> können, ist es jedem unbenommen, die zuständigen Behörden oder
> nichtstaatlichen Organisationen (Verbraucherverbände etc.) zu
> informieren und um eine Prüfung der Angelegenheit zu bitten.

Und wir als Community sollten nichts tun?

Genau das ist es was ich nicht verstehe und was ich leider überall bei AOO 
sehe, klares Bewusstsein für die Probleme, aber Passivität wenn es darum geht 
etwas zu tun. 
In Letzterem will ich genau sein, denn die Community ansich ist garnicht 
passiv, aber sie wird seit Jahren von Apache ausgebremst wenn es um das 
konkrete Handeln geht. Mir ist ganz und garnicht klar wovor Apache sich da 
fürchtet und warum sich Apache als so unflexibel erweist. 


Ressourcen? 
Wir hätten Ressourcen wenn wir wollten. 
Wenn ich könnte wie ich wollte würde ich jedenfalls die Betroffenen im Namen 
der Community anschreiben, mich entschuldigen und sie bitten uns zu helfen 
gegen die 'Abzocker' vorzugehen, gleichzeitig würde ich Öffentlichkeit an 
anderen Stellen herstellen und mich ggf. mit Betroffenen anderer Projekte 
vernetzen. Ich mag nicht glauben das in einer Welt wo es Vertretern von FSF & 
Co. gelingt sich effektiv gegen Lizenzverletztungen juristisch zu wehren, es 
uns nicht gelingen kann etwas für betrogene Anwender zu tun.


und ein persönliches Wort:
mir tut der Anwender leid und gleichzeitig fühle ich mich tatsächlich beschämt 
das unseren Anwendern so etwas widerfährt. Und weil ich so empfinde, deshalb 
ist für mich die Frage so drängend was man tun kann um die Situation zumindest 
etwas zu verbessern.
Was ich tun würde hatte ich geschrieben und dafür würde ich mir die 
Unterstützung der deutschen Community und des PMC wünschen.



Gruß
Jörg





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

SDBC developments and the JDBC driver port

[Damjan Jovanovic]

Hi

To update you on my development efforts, the PostgreSQL driver continues to
advance. I recently added views and fixed a major problem where "Refresh
Tables" causes everything done to tables from then on to fail (as Base
keeps holding references to the old table/view/user/group containers, so
container contents may change, but containers themselves must persist for
the lifetime of the driver).

I did however run into a disturbing bug. When my SDBC driver in Java calls
XStatement.close() on our underlying SDBC to JDBC converter driver written
in C++, and it calls java.sql.Statement.close() in the PostgreSQL JDBC
driver, I get a reproducible unchecked java.lang.IllegalClassChangeError
exception. After hours of debugging I did manage to work around it, by
getting a new methodID before every JNI call to close() instead of caching
it in a static global variable, which shouldn't be required as methodIDs
are meant to persist for the lifetime of the JVM. Either it's a bug in the
JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
corruption or the like :(.

Instead of committing that senseless methodID hack, I've decided to port
the SDBC-JDBC driver to Java, which should make memory corruption
impossible and any debugging and future maintenance much easier (the JNI
code to call into Java is exceptionally complex and ugly, and compiles into
a 15 MB pig of a library in a debug build!). Nothing is lost by using Java,
as the C++ driver can't load JDBC drivers without Java either, and
performance should be identical as the slow boundary between native and
Java is crossed an equal number of times, the crossing just happens in the
JNI bridge under main/bridges instead of the SDBC-JDBC driver.

So far the reusable parts of the PostgreSQL driver have been split off into
a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is itself
currently in the painful phase of dealing with JDBC classloading and class
caching. The final architecture should be something along these lines:

The rest of AOO (mostly C++)
 |  |
 |UNO   | UNO
 |  v
 |  PostgreSQL SDBC driver (Java)
 |  | |
 |  | UNO | UNO
 v  v v
SDBC-JDBC driver (Java)  SDBC-ODBC driver (C++)
 |  |  |
 | Java | Java | C
 v  v  v
other   PostgreSQL JDBC  PostgreSQL ODBC
JDBC driver (Java)driver (C)
drivers |  |
| network I/O  |
v  v
PostgreSQL server

I've also already developed considerable support code for Java (logging,
resource bundles, data structure manipulation), all ported from the support
code for C++ under main/comphelper. Since it is generally useful to other
Java UNO modules, should I move it elsewhere, such as main/javaunohelper
which already contains similar support code, or is there somewhere better?

There are also some API-changing improvements I would like to make to
main/javaunohelper and/or main/ridljar. Is it ok to do those in trunk? Are
Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1 and
4.2?

Damjan

4.1.4 virus warning - False positive?

[Rory O'Farrell]

On Forum today was posted the following from a user

> My G-data (my Antivirus software) has reported as follows::

> Junkware (PUP): Win32.Adware.Narn.D (Engine B)
> Datei: Updater.exe
> Verzeichnis: C:\Users\xxx\AppData\Roaming\OpenOffice Updater

This is most likely a "false positive" and I have so advised the poster, but I 
bring it to the developers' attention just in case.

The forum thread is at
https://forum.openoffice.org/en/forum/viewtopic.php?f=6=90938=430252

Rory
-- 
Rory O'Farrell 

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