from:"Tilmann"

Re: DOAP for JDO

2024-06-29 Thread Tilmann


It seems we already have one?

https://projects.apache.org/project.html?db-_jdo

Best,
TIl


On 27/06/2024 04:56, Craig Russell wrote:

Topic to discuss:

Volunteers to create a DOAP for JDO along the lines of Derby:

https://projects.apache.org/project.html?db-derby


Craig L Russell
c...@apache.org

Re: Minutes: JDO TCK meeting Tuesday November 21 1100 PST 2000 CET

2023-11-25 Thread Tilmann Zäschke


Great, that works perfectly! :-)

On 21/11/2023 22:22, Michael Bouschen wrote:

Hi,


...

3. JDO-830: "tck: Migrate JUnit tests to version 5" 
https://issues.apache.org/jira/browse/JDO-830

PR #85 https://github.com/apache/db-jdo/pull/85

Still some issues with ConsoleLauncher writing to log files...
Good to merge. If still (color) issues with Console, another JIRA can 
be filed.


I found a way to disable the color in the junit result. The 
ConsoleLauncher has an option --disable-ansi-colors that does the job.


I checked in a change that makes use of option --disable-ansi-colors 
into the main branch. Please give it a try.


Regards Michael


Merged.

...

Re: Minutes: JDO TCK meeting Tuesday October 31 1200 PDT 2000 CET

2023-11-05 Thread Tilmann


Hi Michael,

could you create PR?

That would simplify reviewing the code.

I think I can create a PR if you agree?

Best,
Til


On 02/11/2023 20:28, Michael Bouschen wrote:

Hi,

1. JDO-830: "tck: Migrate JUnit tests to version 
5"https://issues.apache.org/jira/browse/JDO-830

Currently using JUnit 5.9.3. But it no longer works subclassing the 
ConsoleLauncher because now with JUnit 5.10.0. the execute method no longer 
returns the number of tests, errors, failures, etc. So we will need to look 
into where the information is stored so we can maintain compatibility with how 
it works today.

See the branch at:https://github.com/apache/db-jdo/tree/JDO-830

...


Update: JUnit provides an Interface TestExecutionListener and an
implementing class SummaryGeneratingListener that calculates the
number of tests, succeeds, failures etc.
I could add a subclass of SummaryGeneratingListener that prints the
test result in the file TCK-results.txt. This class is activated
through a service provider interface, so I added a file
org.junit.platform.launcher.TestExecutionListener under
META-INF/services including the name of the subclass
TCKSummaryGeneratingListener. I think this is the intended way to
handle the test execution result.

You find the update in the branch
https://github.com/apache/db-jdo/tree/JDO-830.

Regards
Michael

--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel:   +49 30 235520-0
Fax:  +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de
Web: www.akquinet.de 

Geschäftsführung: Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[LinkedIn]  [xing]
 [kununu]
 [Instagram]

Re: Fwd: [apache/db-jdo] JDO-827 Simplify JNDI (PR #81)

2023-07-08 Thread Tilmann Zäschke

These are from four/five distinct events with 1-2 emails each: two 
commits, sonarcloud pass, the merge, and finally deleting the branch. 
(actually _four_  events, sonarcloud is trigger by commit I think)


One solution may be to have only the PR description in the header so 
that all emails concerning a single PR end up in the same thread. I 
doubt though that this is technically possible (or desirable).


Maybe we can stop Sonartype from sending emails? Or send them only if it 
actually fails?

I am also not sure why we get two emails for the merge.

Til


On 08/07/2023 01:33, Craig Russell wrote:

There are over half a dozen messages regarding JDO-827/PR#81.

Is there a problem with the asf.yaml configuration that prevents these from 
being threaded?

I know we updated asf.yaml recently but somehow this does not meet my 
expectations.

Thanks,
Craig


Begin forwarded message:

From: Tilmann 
Subject: Re: [apache/db-jdo] JDO-827 Simplify JNDI (PR #81)
Date: July 6, 2023 at 11:43:49 PDT
To: apache/db-jdo 
Cc: Subscribed 
Reply-To: apache/db-jdo 



Merged #81 <https://github.com/apache/db-jdo/pull/81> into main.

—
Reply to this email directly, view it on GitHub 
<https://github.com/apache/db-jdo/pull/81#event-9746958051>, or unsubscribe 
<https://github.com/notifications/unsubscribe-auth/AD4M6RCW3D3TOUV7QNSTPXLXO4BOLANCNFSM6AAZYSIERU>.
You are receiving this because you are subscribed to this thread.


Craig L Russell
c...@apache.org

Re: Reschedule June 29 meeting?

2023-06-27 Thread Tilmann Zäschke


2100 CET works for me.

Best,
Til

On 27/06/2023 18:11, Craig Russell wrote:

I may have a conflict on Thursday June 29 at 1100/2000.

Can we reschedule the call for one hour later? Thursday June 29 1200 PDT 2100 
CET.

Thanks,
Craig

Craig L Russell
c...@apache.org

Re: Mailing list configurations for discussion

2023-05-18 Thread Tilmann Zäschke


https://community.apache.org/contributors/mailing-lists


That looks good to me. Since these are just .asf.yam setting, I suppose it 
should be easy to just try it out?

Best,
Til

On 18/05/2023 02:37, Craig Russell wrote:

Take a look at this:

https://community.apache.org/contributors/mailing-lists

It may make sense for us to re-examine our mail lists, notifications, etc.

WDYT?
Craig

Craig L Russell
c...@apache.org

Re: [db-jdo] 01/01: Update PropertyUtils.java

2023-04-04 Thread Tilmann Zäschke


I had the same problem (1.8.0-331 is not in the allowed range [11,).)

My simple workaround was to use Java 11 (or later) to run the tool.
You can also try autoformatting from your IDE, just check that it 
formats only what you want to be changed.


But I agree that we should probably discuss this:

- Is there a version of that tool that runs with Java 8?

- Alternatively, is it okay to say that we require Java 11 to DEVELOP 
the TCK while requiring Java 8 to RUN it?


Best,
Til


On 04.04.23 02:27, Craig Russell wrote:

Hi Tobias,

Thanks for the hint. I changed the javadoc for the two methods and tried again.

The error message wasn't helpful but I ran mvn locally and now get:

org.apache.maven.enforcer.rule.api.EnforcerRuleException: Detected JDK Version: 
1.8.0-331 is not in the allowed range [11,).
 
I have 1.8.361 installed according to the Java control panel (last updated today).

But my env has
JAVA_HOME /Library/Java/JavaVirtualMachines/jdk1.8.0_331.jdk/Contents/Home

I looked in my /Library/Java/JavaVirtualMachines and there is only the one VM 
installed there.

But that's just on my local machine. What is the problem with the GitHub runner?

I also found this from stackOverflow:

  clr% /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
 1.8.361.09 (x86_64) "Oracle Corporation" - "Java" /Library/Internet 
Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
 1.8.0_331 (x86_64) "Oracle Corporation" - "Java SE 8" 
/Library/Java/JavaVirtualMachines/jdk1.8.0_331.jdk/Contents/Home
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home

Any ideas?
Thanks,
Craig


On Apr 3, 2023, at 14:17, Tobias Bouschen 
 wrote:

Hi Craig,

the instructions on how to run the format jobs are given in the readme: 
https://github.com/apache/db-jdo#formatting-using-maven

GJF also formats javadoc. So my guess would be that the new javadoc is not formatted 
correctly. The issue is probably that the javadoc has a linebreak even though the 
character limit is not reached on the first line. If you want the second line to 
actually be printed as a second line in the javadoc, you have to add '' 
between the two lines. If you just add a blank line between the two javadoc lines, 
the formatter should do this for you.

Best regards,
Tobias

On 03/04/2023 22:25, Craig Russell wrote:

So the code format check failed. I cannot see anything wrong with the changes I 
made.

https://github.com/apache/db-jdo/actions/runs/4591159720/jobs/8107138939?pr=73

Error:  To fix formatting errors, run "mvn 
com.spotify.fmt:fmt-maven-plugin:format"
8275
  
Error:
  Non complying file: 
/home/runner/work/db-jdo/db-jdo/exectck/src/main/java/org/apache/jdo/exectck/PropertyUtils.java
While I try to figure out how to run com.spotify.fmt could anyone just tell me 
what the problem is?

Thanks,
Craig


Begin forwarded message:

From: c...@apache.org
Subject: [db-jdo] 01/01: Update PropertyUtils.java
Date: April 2, 2023 at 15:28:40 PDT
To: "jdo-comm...@db.apache.org" 
Reply-To: jdo-dev@db.apache.org

This is an automated email from the ASF dual-hosted git repository.

clr pushed a commit to branch clr-apache-array-copy
in repository https://gitbox.apache.org/repos/asf/db-jdo.git

commit 034060cb69ad0a10f9bdf5aca4d5a0c9c9c11e8c
Author: Craig L Russell 
AuthorDate: Sun Apr 2 15:28:34 2023 -0700

Update PropertyUtils.java

JDO-819 Fix code smells
Use "Arrays.copyOf", "Arrays.asList", "Collections.addAll" or 
"System.arraycopy" instead.
---
.../java/org/apache/jdo/exectck/PropertyUtils.java | 23 ++
1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/exectck/src/main/java/org/apache/jdo/exectck/PropertyUtils.java 
b/exectck/src/main/java/org/apache/jdo/exectck/PropertyUtils.java
index 07473bce..eef6d73c 100644
--- a/exectck/src/main/java/org/apache/jdo/exectck/PropertyUtils.java
+++ b/exectck/src/main/java/org/apache/jdo/exectck/PropertyUtils.java
@@ -16,6 +16,7 @@ package org.apache.jdo.exectck;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
+import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.Properties;
@@ -28,31 +29,27 @@ public class PropertyUtils {
   }

   /**
-   * Separates white space separated items from a String into Collection 
entries Used to collect
-   * command line argument lists into a Collection
+   * Separates white space separated items from a String into a Set
+   * Used to collect command line arguments
*
* @param names String of white space separated items
-   * @param list HashSet to contain String items
+   * @param set Set to contain String items
*/
-  public static void string2Set(String names, Collection list) {
+  public static void string2Set(String names, Collection set) {
 String[] items = names.split("[ \t\n]");
-for (String s : items) {
-  list.add(s);
-}
+

Re: JDO TCK Conference Call Thursday March 16 1200 PDT 2000 CET

2023-03-16 Thread Tilmann Zäschke


Sorry, just got the blue screen of death.

Next week Thursday is fine if you haven't decided yet...

Cheers, Til


On 15/03/2023 21:02, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday March 16 12:00 Pacific 
Daylight Time (PDT) 20:00 Central European Time (CET) to discuss JDO 
TCK issues and status.


We use the following dial-in for audio and video:
https://us02web.zoom.us/j/87074698575?pwd=bmZXeVV3dVowRHFDWk9KWFdVWjc3dz09 



Agenda:

1. JIRA JDO-819 "Code quality analysis" 
https://issues.apache.org/jira/browse/JDO-819
   JIRA JDO-823 "Fix sonarcloud issues of type Code Smells" 
https://issues.apache.org/jira/browse/JDO-823


Sonarcloud link: https://sonarcloud.io/summary/overall?id=db-jdo

 * Standard outputs shoudl not be used to log anything:
https://sonarcloud.io/project/issues?resolved=false=java%3AS106=MAJOR=CODE_SMELL=db-jdo
 * Unsed type parameters shoudl be removed:
https://sonarcloud.io/project/issues?resolved=false=java%3AS2326=MAJOR=CODE_SMELL=db-jdo
 * Exception classes should be immutable:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1165=MINOR=CODE_SMELL=db-jdo
 * Arrays should be be copied using loops:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3012=MINOR=CODE_SMELL=db-jdo
 * Arrays should not be created for varargs parameters:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3878=MINOR=CODE_SMELL=db-jdo
 * Loops shoudl not contain more than a single "break" or "continue"
   statement:
https://sonarcloud.io/project/issues?resolved=false=java%3AS135=MINORtypes=CODE_SMELL=db-jdo
 * Mutable fields sould not be "public static":
https://sonarcloud.io/project/issues?resolved=false=java%3AS2386=MINOR=CODE_SMELL=db-jdo
 * Type parameter names should comply with naming convention:
https://sonarcloud.io/project/issues?resolved=false=java%3AS119=MINOR=CODE_SMELL=db-jdo
 * Unused local variables should be removed:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1481=MINOR=CODE_SMELL=db-jdo

 * Cognitive Complexity of methods should not be too high:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3776=CRITICAL=CODE_SMELL=db-jdo

 * Raw types should not be used:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3740=MAJOR=db-jdo



2. JIRA JDO-709 "Standardize field/property converters" 
https://issues.apache.org/jira/browse/JDO-709


3. JIRA JDO-822: "Verify compatibility with JDK 20" 
https://issues.apache.org/jira/browse/JDO-822


4. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


5. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his 
advice on JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case 
using annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former participants 
in JDO development and see if and how they want to be recognized on 
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651

Re: JDO TCK Conference Call Wednesday March 1 1200 PST 2100 CET

2023-03-01 Thread Tilmann Zäschke


I am getting "the host has another meeting in progress" ...?


On 01/03/2023 18:57, Tobias Bouschen wrote:

Hi all,

sorry for the short notice again, but I won't be able to attend 
today's conference call. I will see you all next week.


Best regards,
Tobias

On 28/02/2023 20:58, Michael Bouschen wrote:

Hi,

We will have our regular meeting Wednesday March 1 12:00 Pacific 
Standard Time (PST) 21:00 Central European Time (CET) to discuss JDO 
TCK issues and status.


We use the following dial-in for audio and video:
https://us02web.zoom.us/j/87074698575?pwd=bmZXeVV3dVowRHFDWk9KWFdVWjc3dz09 



Agenda:

1. JIRA JDO-819 "Code quality analysis" 
https://issues.apache.org/jira/browse/JDO-819
   JIRA JDO-823 "Fix sonarcloud issues of type Code Smells" 
https://issues.apache.org/jira/browse/JDO-823


Sonarcloud link: https://sonarcloud.io/summary/overall?id=db-jdo

 * Try-catch blocks should not be nested:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1141=MAJOR=db-jdo 


 * Utility classes should not habe public constructors:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1118=MAJOR=db-jdo 


 * Sections of code should not be commented out:
https://sonarcloud.io/project/issues?resolved=false=java%3AS125=MAJOR=db-jdo 


 * Throwable and Error shoudl not be caught:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1181=MAJOR=db-jdo 


 * Constructors of an abstract" class should not be declared "public":
https://sonarcloud.io/project/issues?resolved=false=java%3AS5993=MAJOR=db-jdo 


 * Cognitive Complexity of methods should not be too high:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3776=CRITICAL=CODE_SMELL=db-jdo 


 * Raw types should not be used:
https://sonarcloud.io/project/issues?resolved=false=java%3AS3740=MAJOR=db-jdo 



2. JIRA JDO-709 "Standardize field/property converters" 
https://issues.apache.org/jira/browse/JDO-709


3. JIRA JDO-822: "Verify compatibility with JDK 20" 
https://issues.apache.org/jira/browse/JDO-822


4. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


5. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his 
advice on JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case 
using annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former 
participants in JDO development and see if and how they want to be 
recognized on the JDO and DB web 
sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651

Re: JDO TCK Conference Call Wednesday February 8 1200 PST 2100 CET

2023-02-08 Thread Tilmann Zäschke


Hi Michael,

in the minutes last week it said:

Next meeting: Thursday February 9 1200 PST 2100 CET

Is it Feb 8 or Feb 9?

If it is today, I cannot make it, I will simply join next week :-)

Til


On 08.02.23 08:41, Michael Bouschen wrote:

Hi,

We will have our regular meeting Wednesday February 8 12:00 Pacific 
Standard Time (PST) 21:00 Central European Time (CET) to discuss JDO 
TCK issues and status.


We use the following dial-in for audio and video:
https://us02web.zoom.us/j/87074698575?pwd=bmZXeVV3dVowRHFDWk9KWFdVWjc3dz09 



Agenda:

1. JIRA JDO-819 "Code quality analysis" 
https://issues.apache.org/jira/browse/JDO-819
   JIRA JDO-823 "Fix sonarcloud issues of type Code Smells" 
https://issues.apache.org/jira/browse/JDO-823


Sonarcloud link: https://sonarcloud.io/summary/overall?id=db-jdo

2. JIRA JDO-709 "Standardize field/property converters" 
https://issues.apache.org/jira/browse/JDO-709


3. JIRA JDO-822: "Verify compatibility with JDK 20" 
https://issues.apache.org/jira/browse/JDO-822


4. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


5. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his 
advice on JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case 
using annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former participants 
in JDO development and see if and how they want to be recognized on 
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651

Re: JDO TCK Conference Call Thursday February 2 1100 PST 2000 CET

2023-02-01 Thread Tilmann Zäschke


Unfortunately I have to skip tomorrow, something came up.

Best,
Til

On 01/02/2023 21:06, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday February 2 11:00 Pacific 
Standard Time (PST) 20:00 Central European Time (CET) to discuss JDO 
TCK issues and status.


We use the following dial-in for audio and video:
https://us02web.zoom.us/j/87074698575?pwd=bmZXeVV3dVowRHFDWk9KWFdVWjc3dz09 



Agenda:

1. JIRA JDO-819 "Code quality analysis" 
https://issues.apache.org/jira/browse/JDO-819
   JIRA JDO-823 "Fix sonarcloud issues of type Code Smells" 
https://issues.apache.org/jira/browse/JDO-823


Sonarcloud link: https://sonarcloud.io/summary/overall?id=db-jdo 
<https://sonarcloud.io/summary/overall?id=db-jdo>


Some candidate code smells to be discussed:
https://sonarcloud.io/project/issues?resolved=false=java%3AS1948=CRITICAL=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS2692=CRITICAL=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS1192=CRITICAL=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS1214=CRITICAL=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS127=MAJOR=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS112=MAJOR=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS1185=MINOR=db-jdo 

https://sonarcloud.io/project/issues?resolved=false=java%3AS1481=MINOR=db-jdo 



2. JIRA JDO-709 "Standardize field/property converters" 
https://issues.apache.org/jira/browse/JDO-709


3. JIRA JDO-822: "Verify compatibility with JDK 20" 
https://issues.apache.org/jira/browse/JDO-822


4. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


5. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his 
advice on JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case 
using annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former participants 
in JDO development and see if and how they want to be recognized on 
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651

Re: JDO 709 test case

2023-01-29 Thread Tilmann Zäschke

I submitted an issue here: 
https://github.com/datanucleus/datanucleus-api-jdo/issues/127


Best,
Til

On 29/01/2023 12:48, Tilmann Zäschke wrote:

Michael,

just to let you know, I got the Attribute test case working. I'll let 
you know if I hit any more issues. I will clean up and commit soon 
(hopefully).


I hope you haven't invested too much time yet...

Best,
Til

JDO 709 test case

2023-01-29 Thread Tilmann Zäschke


Michael,

just to let you know, I got the Attribute test case working. I'll let 
you know if I hit any more issues. I will clean up and commit soon 
(hopefully).


I hope you haven't invested too much time yet...

Best,
Til

Re: JDO TCK Conference Call Thursday January 5 1100 PST 2000 CET

2023-01-05 Thread Tilmann Zäschke

Has the meeting already started? I can't get in  ("The meeting host 
will let you in soon")





On 04/01/2023 22:21, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday January 5 11:00 Pacific 
Standard Time (PST) 20:00 Central European Time (CET) to discuss JDO 
TCK issues and status.


We use the following dial-in for audio and video:
https://us02web.zoom.us/j/87074698575?pwd=bmZXeVV3dVowRHFDWk9KWFdVWjc3dz09 



Agenda:

1. JIRA JDO-819 "Code quality analysis" 
https://issues.apache.org/jira/browse/JDO-819
   JIRA JDO-823 "Fix sonarcloud issues of type Code Smells" 
https://issues.apache.org/jira/browse/JDO-823


2. JIRA JDO-709 "Standardize field/property converters" 
https://issues.apache.org/jira/browse/JDO-709


3. JIRA JDO-822: "Verify compatibility with JDK 20" 
https://issues.apache.org/jira/browse/JDO-822


4. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


5. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann see what else is needed to have the analysis 
integrated into GitHub repo.
[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his 
advice on JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case 
using annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former participants 
in JDO development and see if and how they want to be recognized on 
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651


Regards Michael

Re: Minutes: JDO TCK Conference Call Thursday December 15 1100 PST 2000 CET

2022-12-16 Thread Tilmann

> 4. JIRA JDO-819 "Code quality analysis"
https://issues.apache.org/jira/browse/JDO-819
<https://issues.apache.org/jira/browse/JDO-819>

I forgot to mention, instead of '// NOSONAR' it is also easily possible
to mark problems as "false positive" in the web UI.

In my opinion this would be preferred over '// NOSONAR' because using
the web UI avoids cluttering the code with '// NOSONAR' statements.

Maybe something to discuss in the next meeting.

Best,

Til

On 16.12.22 16:49, Craig Russell wrote:

Attendees: Michael Bouschen, Tilmann Zäschke, Tobias Bouschen, Craig Russell

Next meeting: Thursday December 29 1100 PST 2000 CET

Agenda:

1. Derby vulnerability
See https://issues.apache.org/jira/browse/DERBY-7147
<https://issues.apache.org/jira/browse/DERBY-7147>

No rush to upgrade Derby from 10.14.2 (current JDO dependency for tck) to
10.14.3 (fixed version). The tck does not use LDAP which is the attack vector.
AI Michael look into upgrading.

2. JIRA JDO-820: "Clean up copyright NOTICE and references":
https://issues.apache.org/jira/browse/JDO-820
Ist there anything left?
Nothing left. Resolved.

Which Fix Version do we want to use?
Next version whatever that is. 3.2.2 and 3.3

3. JIRA JDO-821: "Fix sonarcloud issues of type Bugs"
https://issues.apache.org/jira/browse/JDO-821
See PR #65: https://github.com/apache/db-jdo/pull/65
<https://github.com/apache/db-jdo/pull/65>

4. JIRA JDO-819 "Code quality analysis" https://issues.apache.org/jira/browse/JDO-819
<https://issues.apache.org/jira/browse/JDO-819>

Changes in PR#65 can be merged.
Tilmann is looking at the SonarCloud "security" issues. Seem to be innocuous.

Still more SonarCloud issues (code smell) to address. For example:
https://sonarcloud.io/project/issues?issues=AYTeBPbL_-S9Jt7nsSUW=AYTeBPbL_-S9Jt7nsSUW=db-jdo

<https://sonarcloud.io/project/issues?issues=AYTeBPbL_-S9Jt7nsSUW=AYTeBPbL_-S9Jt7nsSUW=db-jdo>

Every subclass of JDOUserException smells. Not really an issue for us.

Anyone who looks into a SonarCloud issue should add a comment to the JDO-819
JIRA with the analysis and resolution and possibly a PR. At some point we may
close the issue after the items are low enough importance.

5. JIRA JDO-709 "Standardize field/property converters"
https://issues.apache.org/jira/browse/JDO-709

6. JIRA JDO-815 "Change headers on source files to use https:// instead of http:// "
https://issues.apache.org/jira/browse/JDO-815
<https://issues.apache.org/jira/browse/JDO-815>

Ready to resolve.
AI Craig resolve it.

7. JIRA JDO-822: "Verify compatibility with JDK 20"
https://issues.apache.org/jira/browse/JDO-822
<https://issues.apache.org/jira/browse/JDO-822>

8. JIRA JDO-812 "Move to JDK 11 as the lowest supported version"
https://issues.apache.org/jira/browse/JDO-812

9. Other issues

Action Items from weeks past:

[Nov 23 2022] AI Tilmann see what else is needed to have the analysis
integrated into GitHub repo.
[Nov 23 2022] AI Tilmann follow up with Andy/DataNucleus for his advice on
JDO-709.
[Oct 20 2022] AI Craig update the JIRA JDO-709 to request a test case using
annotations and results of the test.
[Dec 09 2021] AI Craig: Try to contact all current/former participants in JDO
development and see if and how they want to be recognized on the JDO and DB web
sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert Group
members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL
datastores" https://issues.apache.org/jira/browse/JDO-651

Craig L Russell
c...@apache.org

Re: Minutes: JDO TCK Conference Call Thursday November 17 1100 PST 2000 CET

2022-11-22 Thread Tilmann


Hi Craig and Michael,

could you please have a look at
https://issues.apache.org/jira/browse/INFRA-23891 and register with
Sonarcloud (if you are still up for becoming co-admin)?

I think all you have to do is to log in tosonarcloud.io
with your ASF GitHub credentials.

See also:
https://cwiki.apache.org/confluence/display/INFRA/SonarCloud+for+ASF+projects

Best,
Til

Re: Unable to make October 13 JDO meeting

2022-10-11 Thread Tilmann Zäschke


Wednesday October 12 at noon PDT 21 CEDT


Works for me.

Best, Til


On 11/10/2022 18:47, Bouschen, Michael wrote:

Hi Craig,

we could have the meeting Wednesday October 12 at noon PDT 21 CEDT, in case 
that helps.

What do the others think?

Regards Michael


Hi,

Sorry for the late notice, but I have a doctor appointment basically all day on 
Thursday.

I expect to be available the following week pretty much any time.

Apologies,
Craig

Craig L Russell
c...@apache.org





--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel:   +49 30 235520-33
Fax:  +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de
Web:   www.akquinet.de

Geschäftsführung: Martin Weber, Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[Facebook]  
[XING]  
[LinkedIn]  
[Twitter]

Re: JDO TCK Conference Call Thursday September 15 11 PDT 20 CEST

2022-09-14 Thread Tilmann Zäschke


Dear all,

my apologies, but again something came up and I cannot make it tomorrow.

Regards,
Tilmann



On 14/09/2022 21:04, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday September 15 11:00 Pacific 
Daylight Time (PDT) 20:00 Central European Summer Time (CEST) to 
discuss JDO TCK issues and status.


We use the following dial-in for audio and video. You need a Skype 
account to join.

https://join.skype.com/lKWOxZDu2O5U

Agenda:
1. JIRA JDO-818 "Use Google Java Style as the code format conventions 
for the JDO project" https://issues.apache.org/jira/browse/JDO-818
New PR #57 "Maven plugin using Google Java Formatter" 
https://github.com/apache/db-jdo/pull/57


2. PR #50 "Update pom.xml to change http to https" 
https://github.com/apache/db-jdo/pull/50
Relates JIRA "Change headers on source files to use https:// instead 
of http:// " https://issues.apache.org/jira/browse/JDO-815


3. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812


4. Other issues

Action Items from weeks past:

[Jun 15 2022] AI Craig verify that changing the headers now passes the 
RAT test without any other changes.
[Dec 09 2021] AI Craig: Try to contact all current/former participants 
in JDO development and see if and how they want to be recognized on 
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert 
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr 
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to 
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651


Regards Michael

Re: Minutes: JDO TCK Conference Call Thursday August 25 11 PDT 20 CEST

2022-08-31 Thread Tilmann Zäschke


Dear all,

unfortunately I cannot attend tomorrow. See you all next week.

Best,
Til


On 25/08/2022 21:06, Craig Russell wrote:

Attendees: Michael Bouschen, Tilmann Zäschke, Tobias Bouschen, Craig Russell

Next meeting: Thursday September 1 1100 PDT 2000 CEDT

Agenda:

1. JIRA JDO-817 "Check Compiler warnings" 
https://issues.apache.org/jira/browse/JDO-817
see PR 54 "Update pom.xml to show compiler warnings" 
https://github.com/apache/db-jdo/pull/54

No change since last week. Ready to merge?
Remove throws clause from Query and Extent close method
SingleFieldIdentity becomes a generic class so user-written subclasses are 
affected
README.md has a discussion of the warnings
Resolved: merge PR; change main branch to 3.3-SNAPSHOT. Squash/merge.

2. JIRA JDO-818 "Use Google Java Style as the code format conventions for the JDO 
project" https://issues.apache.org/jira/browse/JDO-818
see PR #55 "GJF reformat" https://github.com/apache/db-jdo/pull/55
see https://google.github.io/styleguide/javaguide.html

Proposal: run the tool on main (3.3-SNAPSHOT) after merging JDO-817. Discuss 
next time.
Question: is there any tool that allows for partial updates, e.g. only remove 
white space prior to line end. That might make it easier to review.

3. JIRA JDO-812 "Move to JDK 11 as the lowest supported version" 
https://issues.apache.org/jira/browse/JDO-812

4. Other issues

Action Items from weeks past:

[Jun 15 2022] AI Craig verify that changing the headers now passes the RAT test 
without any other changes.
[Dec 09 2021] AI Craig: Try to contact all current/former participants in JDO 
development and see if and how they want to be recognized on the JDO and DB web 
sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert Group 
members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores" https://issues.apache.org/jira/browse/JDO-651

Craig L Russell
c...@apache.org

Re: Changes in SingleFieldIdentity

2022-08-10 Thread Tilmann


Hi,

I think it's fine.

I think it can break code where people have a sorted list of
SingleFieldIdentity. This is probably rare (?).


An alternative might be to parametrize SingefieldIdentity:

public abstract class SingleFieldIdentity>
implements Externalizable,Comparable

and each subclass:

public class CharIdentity extends SingleFieldIdentity

I think that this way the SingleFieldIdentity stays comparable.

This seems to compile but I haven't tested it.

Tilmann


On 09/08/2022 23:48, Craig Russell wrote:

Hi,

Making this change seems like the right thing to do. While it changes the 
formal signature of the SingleFieldIdentity API class, no one will notice it 
unless (SignatureTest) they go  looking for it.

We just need to be careful. If there are concerns, we might consider putting 
this into 3.3 without going into a possible 3.2.2 release.

But I don't see anything amiss in the approach Michael suggests.

Regards
Craig


On Aug 9, 2022, at 06:28, Michael Bouschen  wrote:

Hi,

as part of JDO-817 "Check Compiler warnings" I was looking into the warnings of the api 
submodule. I started with "raw use of parameterized class", so replacing the use of Set by 
something like Set.

There is one case where I need some feedback. In javax.jdo.identity there is a 
class SingleFieldIdentity which is the abstract base class for single field 
identity classes such as IntIdentity, LongIdentity, etc. Today the abstract 
base class implements Comparable without implementing method compareTo which is 
done in the subclasses. The implements clause is using the raw type Comparable.

I would like to fix this and move the implements clause to the concrete 
subclasses, e.g.:

public class IntIdentity extends SingleFieldIdentity implements 
Comparable
public class LongIdentity extends SingleFieldIdentity implements 
Comparable
This way we can use the concrete subclass as class parameter for Comparable.

Then the signature of the compare method takes an instance of the concrete 
subclass as an argument instead of Object, such that we do not need the 
instanceof check anymore:

public int compareTo(LongIdentity o) {

instead of

public int compareTo(Object o) {
if (oinstanceof LongIdentity) {

The TCK succeeds with this change, but we would need to change the 
SignatureTest (runonce.conf), because of the change of the implements clause of 
SingleFieldIdentity and its subclasses.

What do you think? Is this an API change that is OK?

Regards Michael

Craig L Russell
c...@apache.org

Re: JDO TCK Conference Call Thursday July 14 11 PDT 20 CEST

2022-07-14 Thread Tilmann Zäschke

@Michael Can you maybe leave and start it again? It just says "call
ended" on my side (from last week)

Til

On 14/07/2022 20:11, Bouschen, Michael wrote:

Hi,

no, I joinded the telecon and I'm still in.

Regards Michael

Hi,

has anyone else trouble joining the telecon?

Til

On 13/07/2022 20:39, Michael Bouschen wrote:
Hi,

We will have our regular meeting Thursday July 14 11:00 AM Pacific
Daylight Time (PDT) 20:00 Central European Summer Time (CEST) to
discuss JDO TCK issues and status.

We use the following dial-in for audio and video. You need a Skype
account to join.
https://mx.akquinet.de/link?id=BAgAAABUwTuQXAOm24EAAACNDz3zqISmHO20ogw45SRqmxBKHViOxbpGd0LItWooZKyl6bllk21NRXeW_uTxxWYNvHcHgg4pQUJyRjIcGVM0dJ2p67SHazUoRDgrB7fHBVQsY9NC-eEZE1vgxDL2ZJ0aVw4IxIht4NVvejRW_frKC8oOe5CsNP4f07KR6g77QSw1
Agenda:

1. JIRA JDO-817 "Check Compiler warnings"
https://issues.apache.org/jira/browse/JDO-817
see PR 54 "Update pom.xml to show compiler warnings"
https://github.com/apache/db-jdo/pull/54 and recent checkins into
branch tck-compiler-warnings

2. JIRA JDO-812 "Move to JDK 11 as the lowest supported version"
https://issues.apache.org/jira/browse/JDO-812
New comment from Andy about DataNucleus version v6.0 is supporting
Java11+.

3. Derby's removal of the security manager (see email from Tilmann)

4. Other issues

Action Items from weeks past:

[Jun 15 2022] AI Craig verify that changing the headers now passes the
RAT test without any other changes.
[Dec 09 2021] AI Craig: Try to contact all current/former participants
in JDO development and see if and how they want to be recognized on
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651

Regards Michael

--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel: +49 30 235520-33
Fax: +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de<mailto:michael.bousc...@akquinet.de>
Web: www.akquinet.de<http://www.akquinet.de/>

Geschäftsführung: Martin Weber, Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[Facebook]<http://www.facebook.com/akquinet>
[XING]<https://www.xing.com/companies/akquinetag>
[LinkedIn]<https://www.linkedin.com/company/akquinet-ag>
[Twitter]<https://twitter.com/akquinet>

Re: JDO TCK Conference Call Thursday July 14 11 PDT 20 CEST

2022-07-14 Thread Tilmann Zäschke


When I try to start it it just does nothing.


On 14/07/2022 20:08, Craig Russell wrote:

I have not seen it start yet...


On Jul 14, 2022, at 11:07, Tilmann Zäschke  wrote:

Hi,

has anyone else trouble joining the telecon?

Til


On 13/07/2022 20:39, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday July 14 11:00 AM Pacific
Daylight Time (PDT) 20:00 Central European Summer Time (CEST) to
discuss JDO TCK issues and status.

We use the following dial-in for audio and video. You need a Skype
account to join.
https://join.skype.com/lKWOxZDu2O5U

Agenda:

1. JIRA JDO-817 "Check Compiler warnings"
https://issues.apache.org/jira/browse/JDO-817
see PR 54 "Update pom.xml to show compiler warnings"
https://github.com/apache/db-jdo/pull/54 and recent checkins into
branch tck-compiler-warnings

2. JIRA JDO-812 "Move to JDK 11 as the lowest supported version"
https://issues.apache.org/jira/browse/JDO-812
New comment from Andy about DataNucleus version v6.0 is supporting
Java11+.

3. Derby's removal of the security manager (see email from Tilmann)

4. Other issues

Action Items from weeks past:

[Jun 15 2022] AI Craig verify that changing the headers now passes the
RAT test without any other changes.
[Dec 09 2021] AI Craig: Try to contact all current/former participants
in JDO development and see if and how they want to be recognized on
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651


Regards Michael


Craig L Russell
c...@apache.org

Re: JDO TCK Conference Call Thursday July 14 11 PDT 20 CEST

2022-07-14 Thread Tilmann Zäschke


Hi,

has anyone else trouble joining the telecon?

Til


On 13/07/2022 20:39, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday July 14 11:00 AM Pacific
Daylight Time (PDT) 20:00 Central European Summer Time (CEST) to
discuss JDO TCK issues and status.

We use the following dial-in for audio and video. You need a Skype
account to join.
https://join.skype.com/lKWOxZDu2O5U

Agenda:

1. JIRA JDO-817 "Check Compiler warnings"
https://issues.apache.org/jira/browse/JDO-817
see PR 54 "Update pom.xml to show compiler warnings"
https://github.com/apache/db-jdo/pull/54 and recent checkins into
branch tck-compiler-warnings

2. JIRA JDO-812 "Move to JDK 11 as the lowest supported version"
https://issues.apache.org/jira/browse/JDO-812
New comment from Andy about DataNucleus version v6.0 is supporting
Java11+.

3. Derby's removal of the security manager (see email from Tilmann)

4. Other issues

Action Items from weeks past:

[Jun 15 2022] AI Craig verify that changing the headers now passes the
RAT test without any other changes.
[Dec 09 2021] AI Craig: Try to contact all current/former participants
in JDO development and see if and how they want to be recognized on
the JDO and DB web sites.https://db.apache.org/whoweare.html
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert
Group members asking if they wish to continue.
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr
accounts
[Oct 17 2014] AI Matthew any updates for "Modify specification to
address NoSQL datastores" https://issues.apache.org/jira/browse/JDO-651


Regards Michael

[ANNOUNCE] Apache JDO 3.2.1 released

2022-06-02 Thread Tilmann Zäschke


The Apache JDO project is pleased to announce a new release 3.2.1.

Java Data Objects (JDO) is a standard way to access persistent data in 
databases, using plain old Java objects (POJO) to represent persistent 
data.


JDO 3.2.1 can be obtained from the JDO download site:

http://db.apache.org/jdo/downloads.html.

JDO 3.2.1 is a bug fix release, notably :

* Compatibility with deprecated/removed SecurityManager in Java 18/19
* Schema descriptors have been moved to an Apache URL
* Removed compilation warnings when using Java 9

See the Release Notes of JDO 3.2.1 for details:
JDO 3.2.1: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351329=Html=10630 



Please try out this new release.

[VOTE] [RESULTS] JDO 3.2.1 release

2022-05-25 Thread Tilmann Zäschke


Dear all,

JDO 3.2.1 (based on 3.2.1 RC2) has been approved as an official Apache 
JDO release. Thanks to

all who worked on the release and who voted.

+1
Craig Russell (pmc)
Michael Bouschen (pmc)
Tilmann Zäschke (pmc)
Tobias Bouschen (Committer)

There were no other votes.

Kind regards,
Til

Re: [VOTE] Please vote on JDO 3.2.1 release

2022-05-25 Thread Tilmann Zäschke

Can you verify your Java version with "java -version" and check 
JAVA_HOME and PATH / LD_LIBRARY_PATH (whatever it is on Mac)?


Also, is it expected to run "Internet Plug-Ins/JavaAppletPlugin.plugin"?

Til


On 25/05/2022 19:47, JDO Spec wrote:

Small problem with running the tests.

[ERROR] Failed to execute goal on project jdo-api: Could not resolve dependencies 
for project javax.jdo:jdo-api:jar:3.2.1-RC2: Could not find artifact 
com.sun:tools:jar:1.8.0 at specified path /Library/Internet 
Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/../lib/tools.jar -> [Help 1]
[ERROR]


Any ideas? I get the same thing with the main branch, so it's probably 
something in my local envt.

Thanks,
Craig


On May 22, 2022, at 07:28, Tilmann Zäschke  wrote:

Hi,

please vote on the JDO 3.2.1 release (based on RC2). Voting will be open until 
Wednesday,
May 25th, 14:30 UTC.

You may download the JDO 3.2.1 release artifacts from the staging repository:
https://repository.apache.org/content/repositories/orgapachejdo-1008/


The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/javax/jdo/jdo-api/3.2.1-RC2/

The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/org/apache/jdo/3.2.1-RC2/


For reference, changes since RC1 are:
- Cleaned up generation of LICENSE/NOTICE files (mbouschen)

Regards,
Til

Re: [VOTE] Please vote on JDO 3.2.1 release

2022-05-22 Thread Tilmann Zäschke


+1

Regards,
Tilmann

On 22/05/2022 16:28, Tilmann Zäschke wrote:

Hi,

please vote on the JDO 3.2.1 release (based on RC2). Voting will be 
open until Wednesday,

May 25th, 14:30 UTC.

You may download the JDO 3.2.1 release artifacts from the staging 
repository:

https://repository.apache.org/content/repositories/orgapachejdo-1008/


The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/javax/jdo/jdo-api/3.2.1-RC2/ 



The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/org/apache/jdo/3.2.1-RC2/ 




For reference, changes since RC1 are:
- Cleaned up generation of LICENSE/NOTICE files (mbouschen)

Regards,
Til

[VOTE] Please vote on JDO 3.2.1 release

2022-05-22 Thread Tilmann Zäschke


Hi,

please vote on the JDO 3.2.1 release (based on RC2). Voting will be open 
until Wednesday,

May 25th, 14:30 UTC.

You may download the JDO 3.2.1 release artifacts from the staging 
repository:

https://repository.apache.org/content/repositories/orgapachejdo-1008/


The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/javax/jdo/jdo-api/3.2.1-RC2/

The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1008/org/apache/jdo/3.2.1-RC2/ 




For reference, changes since RC1 are:
- Cleaned up generation of LICENSE/NOTICE files (mbouschen)

Regards,
Til

Re: Minutes: JDO TCK Conference Call Thursday May 19 11 PM PDT 20 CEST

2022-05-21 Thread Tilmann

Once I merged this, any objections to me directly sending out a VOTE
request? Or should I do another test round first?

Regards,
Til

On 20/05/2022 22:20, Bouschen, Michael wrote:

Hi,

I agree renaming is the best option. I tried it and it seems to work.

* Renamed LICENSE.txt to LICENSE and NOTICE.txt to NOTICE.
* I also changed the NOTICE file to include the correct year 2022.
* For the api artifacts the two files LICENSE and NOTICE are generated by
the maven-remote-resources-plugin. You find them in the META-INF subdirectory.
* The plugin uses some values from the pom.xml files, so I added some
comments to api/pom.xml and parent-pom/pom.xml.

Here is the JIRA to cover this: "Avoid duplicated license and notice files in
distribution artifact" https://issues.apache.org/jira/browse/JDO-813

You find the changes in the branch JDO-813. Please feed free to merge the
change in the 3.2.1 branch. Then I will resolve the JIRA.

Regards Michael

Yes. If there is a LICENSE and NOTICE in the root, and the plugin does not
overwrite them, I think we are good renaming our xxx.txt to xxx and be done
with it.

Craig

On May 20, 2022, at 5:03 AM, TIlmann
<mailto:tilmann_...@gmx.de> wrote:

I looked at some other repositories, they appear to have LICENSE and
NOTICE in their repository root.

https://github.com/apache/spark

https://github.com/apache/derby

https://github.com/apache/kafka

Didn't you mention something like that the plugin may not overwrite
files that already exist? In that case we could solve the problem by
just renaming the current files by removing the .txt ending...?

Til.

On 5/20/22 13:15, Bouschen, Michael wrote:

Hi Tilmann,

no, the files LICENCE and NOTICE are generated by 'mvn install'. So if we need
a LICENSE file in the source repository, we haven an issue here.

Regards Michael

So I propose to remove the files LICENSE.txt and NOTICE.txt and use

the files as generated by the maven-remote-resources-plugin

Just for my understanding, we would still have LICENSE/NOTICE files in
the repository, right? I think at least the LICENSE(.txt) file is pretty
much mandatory in the repository.

Otherwise that change sounds good, please go ahead and I will merge it
into the RC.

Til

On 5/19/22 23:22, Craig Russell wrote:
Hi Michael,

I'd agree that removing LICENSE.txt and NOTICE.txt from the root and changing the
in the root pom makes sense.

But let's also make it easier on ourselves by documenting the behavior. Maybe adding
a paragraph to the README.md that describes that the files are automatically created
when the top level project is built? And adding a comment to the pom that the
is used to generate the README and LICENSE files?

Then the question you raise whether we should create a JIRA and add it to
3.2.1. I'm ok either way. It's not a critical fix but still would be useful to
include in 3.2.1.

Craig

On May 19, 2022, at 2:10 PM, Michael Bouschen
<mailto:m...@apache.org><mailto:m...@apache.org><mailto:m...@apache.org>
wrote:

Hi,
Looked at the unzipped directory for source-release that becomes jdo-3.2.1-RC1.
The NOTICE seems a bit off. It refers to the JDO pom with a copyright.
But the NOTICE.txt is fine, except for the Copyright date which should be
2005-2022.
Craig pushed a change to main.

I don't think we need LICENSE since we have LICENSE.txt which is fine.

AI Michael: try to figure out where the LICENSE and NOTICE are coming from.
Perhaps the mvn-notice-plugin?
We added some feature for the Apache Felix bundle plug-in...
I figured out the files LICENSE and NOTICE are generated by the
maven-remote-resources-plugin which is defined in the Apache parent pom.
The plugin definition contains the following comment for the
maven-remote-resources-plugin:
It refers to org.apache:apache-jar-resource-bundle:1.4 as resource bundle. If
you are interested you find it in your local maven repository. Go to
~/.m2/repository/org/apache/apache-jar-resource-bundle/1.4 and take a look at
apache-jar-resource-bundle-1.4.jar. The maven-remote-resources-plugin uses
these files as templates when the plugin is executed.

According to "Assembling LICENSE and NOTICE files" see
https://infra.apache.org/licensing-howto.html the files should be called LICENSE and
NOTICE, so without the .txt suffix.

So I propose to remove the files LICENSE.txt and NOTICE.txt and use the files as generated by the
maven-remote-resources-plugin. In order to get a better name into the generated NOTICE file I propose to rename the
JDO root pom from "JDO Root POM" to "Apache Java Data Objects (JDO)". That means setting the
element in the JDO root pom: Apache Java Data Objects (JDO)

What do you think? If you agree I would check in the change into the 3.2.1
branch.

Regards Michael

Craig L Russell
c...@apache.org<mailto:c...@apache.org><mailto:c...@apache.org><mailto:c...@apache.org>

Re: Minutes: JDO TCK Conference Call Thursday May 19 11 PM PDT 20 CEST

2022-05-20 Thread TIlmann

I looked at some other repositories, they appear to have LICENSE and
NOTICE in their repository root.

https://github.com/apache/spark

https://github.com/apache/derby

https://github.com/apache/kafka

Til.

On 5/20/22 13:15, Bouschen, Michael wrote:

Hi Tilmann,

no, the files LICENCE and NOTICE are generated by 'mvn install'. So if we need
a LICENSE file in the source repository, we haven an issue here.

Regards Michael

So I propose to remove the files LICENSE.txt and NOTICE.txt and use

the files as generated by the maven-remote-resources-plugin

Just for my understanding, we would still have LICENSE/NOTICE files in
the repository, right? I think at least the LICENSE(.txt) file is pretty
much mandatory in the repository.

Otherwise that change sounds good, please go ahead and I will merge it
into the RC.

Til

On 5/19/22 23:22, Craig Russell wrote:
Hi Michael,

I'd agree that removing LICENSE.txt and NOTICE.txt from the root and changing the
in the root pom makes sense.

Then the question you raise whether we should create a JIRA and add it to
3.2.1. I'm ok either way. It's not a critical fix but still would be useful to
include in 3.2.1.

Craig

On May 19, 2022, at 2:10 PM, Michael Bouschen
<mailto:m...@apache.org> wrote:

I don't think we need LICENSE since we have LICENSE.txt which is fine.

According to "Assembling LICENSE and NOTICE files" see
https://infra.apache.org/licensing-howto.html the files should be called LICENSE and
NOTICE, so without the .txt suffix.

What do you think? If you agree I would check in the change into the 3.2.1
branch.

Regards Michael

Craig L Russell
c...@apache.org<mailto:c...@apache.org>

--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel: +49 30 235520-33
Fax: +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de<mailto:michael.bousc...@akquinet.de>
Web: www.akquinet.de<http://www.akquinet.de/>

Geschäftsführung: Martin Weber, Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[Facebook]<http://www.facebook.com/akquinet>
[XING]<https://www.xing.com/companies/akquinetag>
[LinkedIn]<https://www.linkedin.com/company/akquinet-ag>
[Twitter]<https://twitter.com/akquinet>

Re: Minutes: JDO TCK Conference Call Thursday May 19 11 PM PDT 20 CEST

2022-05-20 Thread TIlmann

> So I propose to remove the files LICENSE.txt and NOTICE.txt and use
the files as generated by the maven-remote-resources-plugin

Just for my understanding, we would still have LICENSE/NOTICE files in
the repository, right? I think at least the LICENSE(.txt) file is pretty
much mandatory in the repository.

Otherwise that change sounds good, please go ahead and I will merge it
into the RC.

Til

On 5/19/22 23:22, Craig Russell wrote:

Hi Michael,

I'd agree that removing LICENSE.txt and NOTICE.txt from the root and changing the
in the root pom makes sense.

Then the question you raise whether we should create a JIRA and add it to
3.2.1. I'm ok either way. It's not a critical fix but still would be useful to
include in 3.2.1.

Craig

On May 19, 2022, at 2:10 PM, Michael Bouschen wrote:

Hi,

Looked at the unzipped directory for source-release that becomes jdo-3.2.1-RC1.
The NOTICE seems a bit off. It refers to the JDO pom with a copyright.
But the NOTICE.txt is fine, except for the Copyright date which should be
2005-2022.
Craig pushed a change to main.

I don't think we need LICENSE since we have LICENSE.txt which is fine.

AI Michael: try to figure out where the LICENSE and NOTICE are coming from.
Perhaps the mvn-notice-plugin?
We added some feature for the Apache Felix bundle plug-in...

I figured out the files LICENSE and NOTICE are generated by the
maven-remote-resources-plugin which is defined in the Apache parent pom.
The plugin definition contains the following comment for the
maven-remote-resources-plugin:
It refers to org.apache:apache-jar-resource-bundle:1.4 as resource bundle. If
you are interested you find it in your local maven repository. Go to
~/.m2/repository/org/apache/apache-jar-resource-bundle/1.4 and take a look at
apache-jar-resource-bundle-1.4.jar. The maven-remote-resources-plugin uses
these files as templates when the plugin is executed.

According to "Assembling LICENSE and NOTICE files" see
https://infra.apache.org/licensing-howto.html the files should be called LICENSE and
NOTICE, so without the .txt suffix.

What do you think? If you agree I would check in the change into the 3.2.1
branch.

Regards Michael

Craig L Russell
c...@apache.org

Derby's removal of the security manager

2022-05-13 Thread Tilmann


Item for next meeting:

Since this came up in one of our meetings not so long ago, here are
Derby's thoughts on removing the security manager:
https://issues.apache.org/jira/secure/attachment/13043591/releaseNote.html
from issue
https://issues.apache.org/jira/browse/DERBY-7138

There is a related issue that enforces use of Java 17+ for this version
of Derby:
https://issues.apache.org/jira/browse/DERBY-7137

Note that these changes have not been officially released yet.


One interesting point is the suggested mitigation "Run Derby from the
module path" to prevent access to internals.
- Does JDO work with --/module/-/path,/ do we need to do anything to
(better) support this, i.e. allow others using it?/
/- Should me modularize the JDO API?

Best,
Tilmann

Please test staged JDO 3.2.1 release (RC1)

2022-05-12 Thread Tilmann Zäschke


Dear all,

I just staged JDO 3.2.1 RC1. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1007/

Kind regards,
Tilmann

Re: New JDK 19 EA builds, and JCE Survey!

2022-04-28 Thread Tilmann


Hi David,

Just some positive feedback: I just ran our latest version (Apache JDO
3.2.1-SNAPSHOT, see https://db.apache.org/jdo/) with Java 19 and
everything appears to be in order. No problems. Everything green.

$ java -version
openjdk version "19-ea" 2022-09-20
OpenJDK Runtime Environment (build 19-ea+20-1369)
OpenJDK 64-Bit Server VM (build 19-ea+20-1369, mixed mode, sharing)

Best,
Tilmann


On 20/04/2022 04:10, David Delabassee wrote:

Greetings!

The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase
One’ set for June 9th and ‘General Availability’ set for September
20th. The next several weeks will be interesting to watch as the scope
of JDK 19 is revealed.

You also play an important roll during these phases, which is your
opportunity to share feedback . When developers such as yourself tell
us of issues faced in the latest OpenJDK early-access (EA) builds, we
then have a chance to fix them before that feature release reaches
general availability (GA).

We also enjoy when people tell us that all their tests are green! It
gives us confidence ;-) So regardless of the tests color (red or
green), please do not hesitate to send me a short mail as both types
of feedback are useful.

[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html


## Heads-Up: Java Cryptographic Extension Survey

The Java Cryptographic Extension (JCE) has been in Java SE for a long
time and has made incremental changes over the years. The OpenJDK
Security Team is conducting a survey [2] to know more about how
projects are using JCE and what changes, features, and API
enhancements would be useful going forward.

The survey is clossing on April 29 so if you have written or maintain
code that uses the JCE API, please make sure to fill this short survey
[2] as soon as possible.

[2] https://www.questionpro.com/t/AUzP7ZrFWv


## Heads-Up: New macOS Rendering Pipeline on macOS

JEP 382 [3] introduced in JDK 17 support for the new macOS Metal
graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is
switching the default to be the new macOS Metal rendering pipeline
instead of the old Apple OpenGL API. For more details please see
JDK-8284378 [4].

Java applications running on macOS (10.14 or later) will not need to
take any action, as they will automatically benefit from faster
graphics with lower power consumption, and the use of a more modern
stable graphics API which will be able to work better on current and
future Apple systems.

[3] https://openjdk.java.net/jeps/382
[4] https://bugs.openjdk.java.net/browse/JDK-8284378


## JDK 19 Early-Access builds

JDK 19 Early-Access builds 18 are now available [5], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The Release Notes are available here [6].

[5] https://jdk.java.net/19/
[6] https://jdk.java.net/19/release-notes

### JEPs targeted to JDK 19, so far:
- JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422

### Recent changes that maybe of interest:

Build 18:
- JDK-8284378: Make Metal the default Java 2D rendering pipeline for
macOS
- JDK-8265315: Update CLDR to version 41
- JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over
projections [Reported by JaCoCo]
- JDK-8284361: Updating ASM to 9.3 for JDK 19
- JDK-8284330: jcmd may not be able to find processes in the container
- JDK-8284579: Improve VarHandle checks for interpreter

Build 17:
- JDK-8282819: Deprecate Locale class constructors
- JDK-8254935: Deprecate the PSSParameterSpec(int) constructor
- JDK-8283060: RawNativeLibraries should allow multiple clients to
load/unload the same library

Build 16:
- JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
default
- JDK-8264160: Regex \b is not consistent with \w without
UNICODE_CHARACTER_CLASS
- JDK-8163327: Remove 3DES from the default enabled cipher suites list
- JDK-8267319: Use larger default key sizes and algorithms based on CNSA
- JDK-8283350: (tz) Update Timezone Data to 2022a


## Project Loom Updates

The first Loom related JEP is now in Candidate phase, i.e. JEP: 425:
Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose
to target' any particular feature release.

[7] https://openjdk.java.net/jeps/425

In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4)
are now available [8] with related Javadoc [9].

These builds are based on JDK 19 and are provided under the GNU
General Public License, version 2, with the Classpath Exception and
are produced for the purpose of gathering feedback. Use for any other
purpose is at your own risk. Proper feedback should be sent to the
`loom-dev` mailing list [10].

[8] https://jdk.java.net/loom/
[9] https://download.java.net/java/early_access/loom/docs/api/
[10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev


## Topics of Interest:

* New candidate JEP: 426: Vector API (4th Incubator)
https://openjdk.java.net/jeps/426

* Virtual Thread Deep Dive - Inside Java Newscast

Re: [db-jdo-site] branch publish updated: Auto-deploy site for commit 54d547e22c

2022-04-12 Thread Tilmann Zäschke


Hi,

thanks for the update. Should we add some explanations what the columns
mean (DFG, PK, Persistent)?

Best,
Til



On 4/11/22 17:33, github-...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

github-bot pushed a commit to branch publish
in repository https://gitbox.apache.org/repos/asf/db-jdo-site.git


The following commit(s) were added to refs/heads/publish by this push:
  new c5e13f8  Auto-deploy site for commit 54d547e22c
c5e13f8 is described below

commit c5e13f8abb245348ebe609291e28f6c76e44ab09
Author: andyjefferson 
AuthorDate: Mon Apr 11 15:33:40 2022 +

 Auto-deploy site for commit 54d547e22c
---
  content/field_types.html | 366 ++-
  1 file changed, 267 insertions(+), 99 deletions(-)

diff --git a/content/field_types.html b/content/field_types.html
index e3878b1..4c0f4e0 100644
--- a/content/field_types.html
+++ b/content/field_types.html
@@ -353,12 +353,17 @@ field of that type), whether the field is persisted by 
default (if it is
  to the field for it to be persisted by JDO), and whether the java type
  can be used as part of the primary key.
  
+
+Simple Types
+
+The following "simple" types are supported by default by the JDO spec.
+
  
  
+
+
  
-
-
-
+
  
  
  
@@ -418,362 +423,525 @@ can be used as part of the primary key.
  
  
  
-boolean[]
-
+java.lang.Boolean
+
+
+
+
+
+java.lang.Byte
+
+
+
+
+
+java.lang.Character
+
+
+
+
+
+java.lang.Double
+
  
  
  
  
-byte[]
+java.lang.Float
+
+
  
+
+
+java.lang.Integer
+
+
+
+
+
+java.lang.Long
+
+
+
+
+
+java.lang.Short
+
+
+
+
+
+java.lang.Number
+
  
  
  
  
-char[]
+java.lang.Object
+
  
-
  
  
  
-double[]
+java.lang.String
+
+
+
+
+
+java.math.BigDecimal
+
+
  
+
+
+java.math.BigInteger
+
+
  
+
+
+java.util.Currency
  
+
+
  
  
-float[]
+java.util.Locale
  
  
+
+
+
+java.lang.Enum
+
+
+
+
+
+java.lang.Optional
+
+
  
  
  
-int[]
+java.io.Serializable
+
  
-
  
  
  
-long[]
+javax.jdo.spi.PersistenceCapable
  
  
+
+
+
+
+
+
+Temporal Types
+
+The following temporal types are supported by default by the JDO spec.
+
+
+
+
+
+
+
+
+
+
+Java Type
+DFG?
+Persistent?
+PK?
+
+
+
+
+java.sql.Date
  
+
+
  
  
-short[]
+java.sql.Time
+
  
  
+
+
+java.sql.Timestamp
  
+
+
  
  
-java.lang.Boolean
+java.util.Date
  
  
  
  
  
-java.lang.Byte
+java.time.LocalDateTime
  
  
  
  
  
-java.lang.Character
+java.time.LocalTime
  
  
  
  
  
-java.lang.Double
+java.time.LocalDate
+
  
  
-
  
  
-java.lang.Float
+java.time.OffsetDateTime
+
  
  
-
  
  
-java.lang.Integer
+java.time.OffsetTime
  
  
  
  
  
-java.lang.Long
+java.time.MonthDay
  
  
  
  
  
-java.lang.Short
+java.time.YearMonth
  
  
  
  
  
-java.lang.Boolean[]
-
+java.time.Year
+
+
  
-
  
  
-java.lang.Byte[]
-
+java.time.Period
+
+
  
-
  
  
-java.lang.Character[]
-
+java.time.Instant
+
+
  
-
  
  
-java.lang.Double[]
-
+java.time.Duration
+
+
  
-
  
  
-java.lang.Float[]
-
+java.time.ZoneId
+
+
  
-
  
  
-java.lang.Integer[]
-
+java.time.ZoneOffset
+
+
  
-
  
  
-java.lang.Long[]
-
+java.time.ZonedDateTime
+
+
  
-
  
+
+
+
+
+Collection/Map Types
+
+The following "container" types are supported by default by the JDO spec, subject 
to the JDO implementation supporting that feature.
+
+
+
+
+
+
+
+
+
  
-java.lang.Short[]
+Java Type
+DFG?
+Persistent?
+PK?
+
+
+
+
+java.util.ArrayList
  
  
  
  
  
-java.lang.Number
-
+java.util.Collection
+
  
  
  
  
-java.lang.Object
-
+java.util.HashMap
  
+
  
  
  
-java.lang.String
-
-
+java.util.HashSet
+
  
+
  
  
-java.lang.String[]
+java.util.Hashtable
  
  
  
  
  
-java.math.BigDecimal
-
+java.util.LinkedHashMap
+
  
  
  
  
-java.math.BigInteger
-
-
+java.util.LinkedHashSet
+
  
+
  
  
-java.math.BigDecimal[]
+java.util.LinkedList
  
  
  
  
  
-java.math.BigInteger[]
+java.util.List
  
  
  
  
  
-java.sql.Date
-
+java.util.Map
  
  
+
  
  
-java.sql.Time
-
+java.util.Set
  
  
+
  
  
-java.sql.Timestamp
-
+java.util.TreeMap
  
  
+
  
  
-java.util.ArrayList
+java.util.TreeSet
  
  
  
  
  
-java.util.Collection
+java.util.Vector
  
  
  
  
+
+
+
+
+Array Types
+
+The vast majority of the "simple" SCO types can also be persisted as arrays of 
that type as well.
+
+
+
+
+
+
+
+
+
  
-java.util.Currency
+Java Type
+DFG?
+Persistent?
+PK?
+
+
+
+
+boolean[]
  
  
-
+
  
  
-java.util.Date
-
-
+byte[]
+
  
+
  
  
-java.util.Date[]
+char[]
  
  
  
  
  
-java.util.HashMap
+double[]
  
  
  
  
  
-java.util.HashSet
+float[]
  
  
  
  
  
-java.util.Hashtable
+int[]
  
  
  
  
  
-java.util.LinkedHashMap
+long[]
  
  
  
  
  
-java.util.LinkedHashSet
+short[]
  
  
  
  
  
-java.util.LinkedList
+java.lang.Boolean[]
  
  
  
  
  
-java.util.List
+java.lang.Byte[]
  
  
  
  
  
-java.util.Locale
+java.lang.Character[]
  
  
-
+
  
  
-java.util.Locale[]
+java.lang.Double[]
  
  
  
  
  
-java.util.Map
+java.lang.Float[]
  
  
  
  
  
-java.util.Set
+java.lang.Integer[]
  
  
  
  
  
-java.util.TreeMap

Re: Help getting xsd and dtd files into db.apache.org/jdo site

2022-03-23 Thread Tilmann


Probably just a glitch...?

I recomitted the README and now it built fine.

The error message sounded like there was something wrong with the
email/username during the build, I have no idea how that could have
happened.


Side note: I wonder whether the files should be in

src/main/xmlns instead of a subfolder of asciidoc?

Best,
Til



On 23/03/2022 15:34, Craig Russell wrote:

Anyone can help here?


Begin forwarded message:

From: Craig Russell 
Subject: Fwd: [apache/db-jdo-site] Run failed: Build & Deploy Site - main 
(ceb4812)
Date: March 19, 2022 at 2:41:22 PM PDT
To: JDO Project 

https://issues.apache.org/jira/browse/JDO-806 


I created https://github.com/apache/db-jdo-site/tree/main/xmlns/README.md 
 and that 
seemed to work but did not get published.

I created 
https://github.com/apache/db-jdo-site/tree/main/src/main/asciidoc/xmlns/README.md 

 and that tried to publish but I got this error.

I suppose there is something needed to the asf.yaml to publish this new 
directory. Anyone know how to do this?

Thanks,
Craig


Begin forwarded message:

From: Craig L Russell mailto:notificati...@github.com>>
Subject: [apache/db-jdo-site] Run failed: Build & Deploy Site - main (ceb4812)
Date: March 19, 2022 at 2:33:38 PM PDT
To: apache/db-jdo-site mailto:db-jdo-s...@noreply.github.com>>
Cc: Ci activity mailto:ci_activ...@noreply.github.com>>
Reply-To: apache/db-jdo-site mailto:nore...@github.com>>



[apache/db-jdo-site] Build & Deploy Site workflow run



Build & Deploy Site: All jobs have failed

View workflow run 



Build & Deploy Site / Build & Deploy Site
Failed in 28 seconds
   1 



—
You are receiving this because this workflow ran on your branch.
Manage your GitHub Actions notifications 


GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107


Craig L Russell
c...@apache.org 


Craig L Russell
c...@apache.org

[clr-apache/jdo-specification] 28a585: Add files via upload

2022-03-03 Thread Tilmann

  Branch: refs/heads/main
  Home:   https://github.com/clr-apache/jdo-specification
  Commit: 28a585f1bf94b995d4f218e03f0d2cbcd1be890b
  
https://github.com/clr-apache/jdo-specification/commit/28a585f1bf94b995d4f218e03f0d2cbcd1be890b
  Author: Tilmann 
  Date:   2022-03-03 (Thu, 03 Mar 2022)

  Changed paths:
A releases/JDO-3.1.pdf
A releases/JDO_3_1-rc1.pdf

  Log Message:
  ---
  Add files via upload

[clr-apache/jdo-specification] 114c5d: Update README.md

2022-02-24 Thread Tilmann

  Branch: refs/heads/main
  Home:   https://github.com/clr-apache/jdo-specification
  Commit: 114c5d7d0397a8ca1731a01999e9b0dc6e1b3901
  
https://github.com/clr-apache/jdo-specification/commit/114c5d7d0397a8ca1731a01999e9b0dc6e1b3901
  Author: Tilmann 
  Date:   2022-02-24 (Thu, 24 Feb 2022)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

[clr-apache/jdo-specification] 85879c: Update README.md

2022-02-24 Thread Tilmann

  Branch: refs/heads/main
  Home:   https://github.com/clr-apache/jdo-specification
  Commit: 85879cc5534d5d09295ccadc12c535acca7141fe
  
https://github.com/clr-apache/jdo-specification/commit/85879cc5534d5d09295ccadc12c535acca7141fe
  Author: Tilmann 
  Date:   2022-02-24 (Thu, 24 Feb 2022)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Re: Reproducible JDO Build

2022-02-14 Thread Tilmann


Hi Craig,

yes, I think generally (e.g. C++) reproducible builds are good and can
be quite useful. With Java, it's a bit more limited, I assume the main
problems are the JDK version, dependencies (e.g. .pom with version
ranges) and the build platform (Windows line breaks, JNI dependencies,
...); after all, in Java we deliver a .jar file, not a binary.
--> I am all in favor of having reproducible builds.

What I do not understand at the moment is the benefit of:

|mvn clean install mvn clean package artifact:compare|

It compares a local build with another local build, so it's avoiding all
the things that could possibly fail (JDK, dependencies, platform), at
least as far as I can tell. How can this ever fail? In what way does
this check for build reproducibility?

I'm sure I a missing something here...

Regards,
Til


a nice to have.

On 12/02/2022 02:17, Craig Russell wrote:

Hi Til,

I had a brief look at the internets and found some interesting commentary on 
the subject.https://reproducible-builds.org/docs/deterministic-build-systems/

I didn't spend much time, but there are a few things that I took away from 
that. I think that Java makes it easier because given any machine supporting 
Java (specific version) will produce reproducible results if some rules are 
followed. This is not the case for other compilers that actually might produce 
different results on different machines.

Anyway, I still think it's good to verify reproducible results in our project.

Regards,
Craig


On Feb 11, 2022, at 5:15 AM, Tilmann  wrote:


The plugin compare the artifacts in the maven repository with the

ones in the target directory by creating buildinfos for the artifacts
and comparing them.

So the process compares two builds that have been built locally on the
same machine. I don't think I understand how this is meant to work (I
had a look at
https://maven.apache.org/plugins/maven-artifact-plugin/index.html  but no
luck):
- If I build both version locally, why they would ever differ?
- Is there a way to use this process to detect any problems caused by
building on different machines/environment (because it is always run on
the same machine)? It seems like one has to copy builds from another
machine or at least set-up a private repository that can be accessed by
multiple machines...?

Til



On 10/02/2022 22:33, Michael Bouschen wrote:

Hi,

our JDO build is now reproducible, I just have to follow the
instructions given by hboutemy.

First I call 'mvn clean install' which builds all the artifacts and
stores them in the local maven repository.
Then I call 'mvn clean package artifact:compare' which build the
artifacts again, but only in the target directory.
The plugin compare the artifacts in the maven repository with the ones
in the target directory by creating buildinfos for the artifacts and
comparing them.

This process also works for SNAPSHOT versions.

Regards Michael


Craig L Russell
c...@apache.org

Re: Reproducible JDO Build

2022-02-11 Thread Tilmann


> The plugin compare the artifacts in the maven repository with the
ones in the target directory by creating buildinfos for the artifacts
and comparing them.

So the process compares two builds that have been built locally on the
same machine. I don't think I understand how this is meant to work (I
had a look at
https://maven.apache.org/plugins/maven-artifact-plugin/index.html but no
luck):
- If I build both version locally, why they would ever differ?
- Is there a way to use this process to detect any problems caused by
building on different machines/environment (because it is always run on
the same machine)? It seems like one has to copy builds from another
machine or at least set-up a private repository that can be accessed by
multiple machines...?

Til



On 10/02/2022 22:33, Michael Bouschen wrote:

Hi,

our JDO build is now reproducible, I just have to follow the
instructions given by hboutemy.

First I call 'mvn clean install' which builds all the artifacts and
stores them in the local maven repository.
Then I call 'mvn clean package artifact:compare' which build the
artifacts again, but only in the target directory.
The plugin compare the artifacts in the maven repository with the ones
in the target directory by creating buildinfos for the artifacts and
comparing them.

This process also works for SNAPSHOT versions.

Regards Michael

[ANNOUNCE] Apache JDO 3.2 released

2022-02-10 Thread Tilmann Zäschke


The Apache JDO project is pleased to announce a new release 3.2.

Java Data Objects (JDO) is a standard way to access persistent data in 
databases, using plain old Java objects (POJO) to represent persistent data.


JDO 3.2 can be obtained from the JDO download site:

http://db.apache.org/jdo/downloads.html.

JDO 3.2 has several new features, notably :

* New typesafe query API with generics
* Fluent query API allows chaining of query construction setters
* Support for Java "Time" and "Optional" fields in persistent classes 
and in queries
* Additional operations in query language with support for bit 
operations and additional Math operations.

* PersistenceManager and Query support AutoCloseable
* Baseline JDK is now JDK 1.8

In addition, JDO 3.2 contains many bug and documentation fixes and 
improvements.


See the Release Notes of JDO 3.2 for details:
JDO 3.2: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12316653=Html=10630 



Please try out this new release.

Announcement template

2022-02-07 Thread Tilmann


Do we have an example of an earlier announcement that I could use as
template?
I won't send it now, but maybe I can prepare it for Thursday.

Til

Re: Update to release instructions for download pages

2022-02-07 Thread Tilmann


The download release pages appear to contain a lot of duplicated
information. Maybe we can consolidate them to a single download page
instead?

E.g. with:
- Introduction with repo-link
- a single Maven example for the latest version
- a table with one row per version with release notes|API
link|signatures; maybe a separate table for TCK downloads
- instructions for verification
- About JDO Releases

Til


On 06/02/2022 19:18, Craig Russell wrote:

Hi,

We should update the release instructions 
https://github.com/apache/db-jdo/blob/3.2/HowToReleaseJDO.md to include adding 
a downloads page for public consumption. The downloads page needs to be linked 
from the announce email.

How should we handle e.g. 3.2.1? Should we create another downloads page for 
3.2.1? We could add the release to the 3.2 download page. We could replace the 
3.2 download artifacts with the 3.2.1 artifacts.

Whichever we decide, creating/updating the downloads page should be part of the 
release instructions.

WDYT?
Craig

Craig L Russell
c...@apache.org

Re: svn commit: r52353 - /release/db/jdo/3.2/

2022-02-02 Thread Tilmann


I have already prepared a 3.2 branch for the website but it is not ready
yet: https://github.com/apache/db-jdo-site/pull/44

There are several points we should discuss in the next meeting:

* The website currently expects the JDO spec for 3.1, 31.rc1 and 3.2 to
be in the db-jdo repository but they have been removed or need to be
generated

* I gave some initial text for the "news" section, but it needs some work.


Also, the ReleaseHowto needs some more work:

- site update instructions: no need to update RunRules

- site update instructions: Where to get the javadoc from (it is not in
the release, which I think is ok, I got it from locally cached build
artifacts)

- site update instructions: Update index.adoc / add "Update News" to
site-update

- general release instructions: how to send an email from an apache.org
account for [Announce]

Best,
Til



On 02/02/2022 01:06, Craig Russell wrote:

Great. The release is now distributed. You can see it here:
https://www.apache.org/dyn/closer.lua/db/jdo/3.2/jdo-3.2-source-release.tar.gz

Now we move on to the downloads page...

Once downloads page is updated to refer to the new 3.2 page, the 3.1 release 
can be removed from the release/db/jdo directory and it will still be available 
via the 3.1 downloads page via dyn/closer link.

We should probably have a brief review here of the 3.2 download page before 
making the official release announcement on annou...@apache.org.

Congratulations,
Craig


On Feb 1, 2022, at 10:42 AM, tilma...@apache.org wrote:

Author: tilmannz
Date: Tue Feb  1 18:42:51 2022
New Revision: 52353

Log:
JDO 3.2 release

Added:
release/db/jdo/3.2/
release/db/jdo/3.2/jdo-3.2-source-release.tar.gz   (with props)
release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.asc
release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.sha512
release/db/jdo/3.2/jdo-3.2-source-release.zip   (with props)
release/db/jdo/3.2/jdo-3.2-source-release.zip.asc
release/db/jdo/3.2/jdo-3.2-source-release.zip.sha512
release/db/jdo/3.2/jdo-3.2.pom.asc

Added: release/db/jdo/3.2/jdo-3.2-source-release.tar.gz
==
Binary file - no diff available.

Propchange: release/db/jdo/3.2/jdo-3.2-source-release.tar.gz
--
svn:mime-type = application/octet-stream

Added: release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.asc
==
--- release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.asc (added)
+++ release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.asc Tue Feb  1 18:42:51 
2022
@@ -0,0 +1,16 @@
+-BEGIN PGP SIGNATURE-
+
+iQIzBAABCgAdFiEEoFpG7EE5ER8eEz2Tncaze1QlQn0FAmHwZGYACgkQncaze1Ql
+Qn2nHRAAjozbfkNQ+PGSfwCzCTyvfikYZt2mmxS9Ewh4VfxIp0xNdjF20uE9kYIr
+CJJ46vUVi+Y/ZcOHw/V7xFGaIw8gPlcIj5lAvB2wKF8TBblEbI8KjgnCrmW8PM0m
+pnG26TxHS53HCI+WaO/2sYzMnnHvCGw6w8qYh5UwJIbe3l2IQOTQFXgOn50hyWav
+OD5bJRDkIua3lVVGTP95xTGHp2eoBwyYZGXLR1xSvLQPfc96EmcfCbsqBwbwj8+L
+2MmO+dLfTYO6ezEpXdeZ+HevfWLaum2DPFmkhmDhf3YQ+Sr/5b4o6yu6JaujSqWL
+5H6aO/nETozvAi71rZ5NYeeRIB9OU4RO36w3r3BoFDjMJWgIepCp9fIe51SqG4yP
+/mWFq+t0zNmrHt4E/1XUP4hcLSHLS60tR5oN3jHrzdyxEcjuYTpny70/irfe/ACj
+CN8UBc/5YeHpdd0LH6QXWixHk7I9BvD+3bVUmyB3HCt+gS/sEjx3aNYoHgIRBkyv
+9vjtNMIBH93MDzkKIOcstKP0HodphA5rbwyL4gYuihBA4Fm26weNdVMv1nMNF0do
+EzZd+COhOROfmLVEtoV869xK2VhWXVir041J60zkr2LrCjfz27C9EFX/AEnULbqE
+tfYMdAk+3EvS2RupqOwSE1bRY4CnzwuDmsuoUuAzu2IfwWjha90=
+=PPQz
+-END PGP SIGNATURE-

Added: release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.sha512
==
--- release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.sha512 (added)
+++ release/db/jdo/3.2/jdo-3.2-source-release.tar.gz.sha512 Tue Feb  1 18:42:51 
2022
@@ -0,0 +1 @@
+d2200874250b0e55d8ed399f8a249fe68f0be138332d178714c8e272646f970d0cbb156ff7adfce23815863592070738c1f0d881505d40952fd68288116bb1e7
\ No newline at end of file

Added: release/db/jdo/3.2/jdo-3.2-source-release.zip
==
Binary file - no diff available.

Propchange: release/db/jdo/3.2/jdo-3.2-source-release.zip
--
svn:mime-type = application/octet-stream

Added: release/db/jdo/3.2/jdo-3.2-source-release.zip.asc
==
--- release/db/jdo/3.2/jdo-3.2-source-release.zip.asc (added)
+++ release/db/jdo/3.2/jdo-3.2-source-release.zip.asc Tue Feb  1 18:42:51 2022
@@ -0,0 +1,16 @@
+-BEGIN PGP SIGNATURE-
+
+iQIzBAABCgAdFiEEoFpG7EE5ER8eEz2Tncaze1QlQn0FAmHwZGUACgkQncaze1Ql
+Qn00XxAA3iQyTU8Of9Lg5rbhzRO3K4y4T0gohJD886qhhGAQmpkFVs96XvSzSNHx
+y5dWbEkf2wSvZ+q73Z4TXE2eU9aFU23iEa0YIVt+EZzu5xgw1Kz6c2Q+YO8B4goz
+v9EEePUHa3cBRae7j6VWeEoQ9lXo8NbejZ9GAskjJLL03LpkVsqwr5RzX6ypkH3r

[VOTE] [RESULTS] JDO 3.2 release

2022-02-01 Thread Tilmann


Dear all,

JDO 3.2 has been approved as an official Apache JDO release. Thanks to
all who worked on the release and who voted.

+1
Craig Russell (pmc)
Michael Bouschen (pmc)
Tilmann Zäschke (pmc)
Tobias Bouschen (Committer)

There were no other votes.


Context:
The previous (successful) vote from 2021-12-09 had been repeated to
account for updated log4j dependencies.


Kind regards,
Til

Re: [VOTE] Please vote on JDO 3.2 release

2022-01-31 Thread Tilmann


+1 from me as well

Regards,
Tilmann


On 27/01/2022 17:36, Tilmann Zäschke wrote:

Dear all,

I prepared the final release for JDO 3.2.

Please vote on the release. Voting will be open until Monday, January
31st.


You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1006/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1006/javax/jdo/jdo-api/3.2/



The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1006/org/apache/jdo/3.2/


For reference, changes since the last vote are:
- Updated log4j from 2.13.3 to 2.17.1

Regards,
Til


On 02/12/2021 20:25, Tilmann wrote:

Hi,

after the cancelled vote for RC4 here is new request to vote:

Please vote on the JDO 3.2 release (based on RC5). Voting will be open
until Monday,
October 6th.

You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1005/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/javax/jdo/jdo-api/3.2-RC5/




The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/org/apache/jdo/3.2-RC5/




For reference, changes since RC4 are:
- Updated dependencies to latest 5.* versions of datanucleus modules
- Removed spec PDFs
- ReleaseHowTo.md updated


Regards,
Til

Derby, JDO, Torque websites missing

2022-01-31 Thread Tilmann Zäschke


Hi,

Updating the DB website succeeded, but the subproject websites
disappeared. I reported this here:
https://issues.apache.org/jira/browse/INFRA-22822

https://db.apache.org/

Any help is appreciated.

Best,
Til

[VOTE] Please vote on JDO 3.2 release

2022-01-27 Thread Tilmann Zäschke


Dear all,

I prepared the final release for JDO 3.2.

Please vote on the release. Voting will be open until Monday, January 31st.


You may download the JDO 3.2 release artifacts from the staging repository:
https://repository.apache.org/content/repositories/orgapachejdo-1006/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1006/javax/jdo/jdo-api/3.2/


The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1006/org/apache/jdo/3.2/

For reference, changes since the last vote are:
- Updated log4j from 2.13.3 to 2.17.1

Regards,
Til


On 02/12/2021 20:25, Tilmann wrote:

Hi,

after the cancelled vote for RC4 here is new request to vote:

Please vote on the JDO 3.2 release (based on RC5). Voting will be open
until Monday,
October 6th.

You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1005/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/javax/jdo/jdo-api/3.2-RC5/



The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/org/apache/jdo/3.2-RC5/



For reference, changes since RC4 are:
- Updated dependencies to latest 5.* versions of datanucleus modules
- Removed spec PDFs
- ReleaseHowTo.md updated


Regards,
Til

Question on 3.2 release process

2022-01-25 Thread Tilmann


I just prepared the final 3.2 release:
https://repository.apache.org/content/repositories/orgapachejdo-1006/

Following the release instructions, the next step would be to properly
release it (step 19):
https://github.com/apache/db-jdo/blob/main/HowToReleaseJDO.md

However, from the last meeting I seem to remember that there was mention
of another VOTE.

Is it correct to proceed with step 19?
Or do we need another round of test/vote?

Best,
Til

Fwd: [jira] [Comment Edited] (INFRA-22540) Change "Apache Rules" in Nexus to check for sha256/512 instead of sha1/md5

2021-12-19 Thread Tilmann Zäschke


Hi,

the INFRA ticket just got updated.

Could someone have a look whether I am describing the process/issue
correctly?

https://issues.apache.org/jira/browse/INFRA-22540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461830#comment-17461830

Thanks,
Til



 Forwarded Message 
Subject:[jira] [Comment Edited] (INFRA-22540) Change "Apache Rules" in
Nexus to check for sha256/512 instead of sha1/md5
Date:   Sat, 18 Dec 2021 10:26:00 + (UTC)
From:   Herve Boutemy (Jira) 
To: tilma...@apache.org




[
https://issues.apache.org/jira/browse/INFRA-22540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461830#comment-17461830
]
Herve Boutemy edited comment on INFRA-22540 at 12/18/21, 10:25 AM:
---

we had such discussion at Maven level: there is in general a confusion
between
1. Apache rules on source release to dist, which mandate sha256/sha512
2. Central rules on every artifacts (jar, pom, anything not related to
Apache source release), which still asks for sha1/md5 for checksums and
PGP signature for more serious checks

in Apache parent POM release 24 MPOM-244, we added a configuration to
generate sha512 for source-release artifacts when publishing to
Nexus/Central to help projects: see documentation
https://maven.apache.org/pom/asf/#The_apache-release_Profile

but not every project uses Apache parent POM, or did not upgrade to 24,
or do not even use Maven to build, so I don't know what's the best
solution for [~tilmannz]

at least, please consider the difference in policy of Apache source
release archive vs any other artifact published to Central if you change
something


was (Author: hboutemy):
we had such discussion at Maven level: there is in general a confusion
between
1. Apache rules on source release to dist, which mandate sha256/sha512
2. Central rules on every artifacts (jar, pom, anything not related to
Apache source release), which still asks for sha1/md5 for checksums and
PGP signature for more serious checks

in Apache parent POM release 24 MPOM-244, we added a configuration to
generate sha512 for source-release artifacts when publishing to
Nexus/Central to help projects: see documentation
https://maven.apache.org/pom/asf/#The_apache-release_Profile

but not every project uses Apache parent POM, or did not upgrade to 24,
or do not even use Maven to build, so I don't know what's the best
solution for [~tilmannz]

at least, please consider the difference in policy of Apache release
source release vs any artifact published to Central if you change something


Change "Apache Rules" in Nexus to check for sha256/512 instead of sha1/md5
--

Key: INFRA-22540
URL: https://issues.apache.org/jira/browse/INFRA-22540
Project: Infrastructure
Issue Type: Improvement
Components: Nexus
Reporter: Tilmann Zäschke
Priority: Major

The Release Distribution Policy
(https://infra.apache.org/release-distribution) states:
"PMCs must supply SHA-256 and/or SHA-512 and should not supply MD5 or
SHA-1.".
However, currently, the Apache Rules in Nexus appear to enforce that
all files (including .zip and .tar.gz) to have .sha1 and .md5
pendants. For our project "closing" a release candidate fails with:
Event: Failed: Checksum Validation
typeId checksum-staging
failureMessage Required SHA-1:
'/org/apache/jdo/3.2-RC3/jdo-3.2-RC3-source-release.zip.sha1'
failureMessage Required MD5:
'/org/apache/jdo/3.2-RC3/jdo-3.2-RC3-source-release.zip.md5'
failureMessage Required SHA-1:
'/org/apache/jdo/3.2-RC3/jdo-3.2-RC3-source-release.tar.gz.sha1'
failureMessage Required MD5:
'/org/apache/jdo/3.2-RC3/jdo-3.2-RC3-source-release.tar.gz.md5' Can
the Apache Rules in Nexus be adapted to allow or even enforce that
files (other than .jar/.pom) to be signed with sha256/sha512 instead
of sha1/md5?




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[RESULT][VOTE] JDO 3.2 release

2021-12-09 Thread Tilmann


Dear all,

JDO 3.2 has been approved as an official Apache JDO release. Thanks to
all who worked on the release and who voted.

+1
Andy Jefferson (pmc)
Craig Russell (pmc)
Michael Bouschen (pmc)
Tilmann Zäschke (pmc)
Tobias Bouschen (Committer)

There were no other votes.

Kind regards,
Til

Re: [VOTE] Please vote on JDO 3.2 release

2021-12-03 Thread Tilmann


+1

Regards,
Tilmann

On 03/12/2021 11:56, Michael Bouschen wrote:

+1

Regards Michael


Hi,

after the cancelled vote for RC4 here is new request to vote:

Please vote on the JDO 3.2 release (based on RC5). Voting will be open
until Monday,
October 6th.

You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1005/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/javax/jdo/jdo-api/3.2-RC5/



The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/org/apache/jdo/3.2-RC5/



For reference, changes since RC4 are:
- Updated dependencies to latest 5.* versions of datanucleus modules
- Removed spec PDFs
- ReleaseHowTo.md updated


Regards,
Til

[VOTE] Please vote on JDO 3.2 release

2021-12-02 Thread Tilmann


Hi,

after the cancelled vote for RC4 here is new request to vote:

Please vote on the JDO 3.2 release (based on RC5). Voting will be open
until Monday,
October 6th.

You may download the JDO 3.2 release artifacts from the staging repository:
https://repository.apache.org/content/repositories/orgapachejdo-1005/

The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/javax/jdo/jdo-api/3.2-RC5/


The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1005/org/apache/jdo/3.2-RC5/


For reference, changes since RC4 are:
- Updated dependencies to latest 5.* versions of datanucleus modules
- Removed spec PDFs
- ReleaseHowTo.md updated


Regards,
Til

Re: [VOTE] Please vote on JDO 3.2 release CANCELLED

2021-12-02 Thread Tilmann Zäschke


Dear all,

we have a new release candidate so this vote on RC4 is cancelled.

I will send out another email with a new vote for RC5.

Kind regards,
Til


On 25/11/2021 22:52, Tilmann wrote:

Hi,

Please vote on the JDO 3.2 release. Voting will be open until Monday,
November 29.

You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1004/


The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1004/javax/jdo/jdo-api/3.2-RC4/


The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1004/org/apache/jdo/3.2-RC4/


Regards,
Til

Please test staged JDO 3.2 release (RC5)

2021-11-27 Thread Tilmann


Dear all,

I just staged JDO 3.2 RC5. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1005/

Changes:
- Updated dependencies to latest 5.* versions of datanucleus modules
- Removed spec PDFs
- ReleaseHowTo.md updated

Note:
In this release all files are still delivered with a .sha1 and .md5
file. This is due to a technical problem which is tracked here:
https://issues.apache.org/jira/browse/INFRA-22540
This is also the reason why RC3 failed and was no put up for a vote.

Best,
Tilmann




On 21/11/2021 18:35, Tilmann wrote:

Dear all,

I just staged JDO 3.2 RC4. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1004/

Changes:
- the "source-release" archives are now signed with SHA512 in addition
to md5/sha1
- ReleaseHowTo.md updated

Note:
In this release all files are still delivered with a .sha1 and .md5
file. This is due to a technical problem which is tracked here:
https://issues.apache.org/jira/browse/INFRA-22540
This is also the reason why RC3 failed and was no put up for a vote.

Best,
Tilmann


On 08/11/2021 23:20, Tilmann Zäschke wrote:

Dear all,

I just staged JDO 3.2 RC2. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1002

Changes:
- archives are now available as .zip and as  .tar.gz
- the "source-release" archives are now signed with SHA512
- The pom now has the "timestamp" property
- Some updates on the release instructions

Note:
- The API is still signed with sha1 only. I believe this is in line with
the
  requirement of Nexus which does not seem to support SHA256 or SHA512.
- The parent .pom has its  section removed. It gets removed by the
  release plugin, not sure whether this is a feature or how it can be
avoided.
  I will add the section again after the release.

Kind regards,
Tilmann

Re: Minutes: JDO TCK Conference Call Thursday November 25 11 AM PST 20 CET

2021-11-27 Thread Tilmann


Hi,

since we want to support JRE 1.8+ I should probably create a new RC5
with the dependencies that Andy provided.

If nobody objects I will set up a new RC tomorrow.

Best,
Til


On 27/11/2021 17:05, Craig Russell wrote:

Hi Andy,

Thanks for helping us get the best possible list of DataNucleus dependencies 
for the release.

Thanks for clarifying the purpose of the api-jdo jar. I had a misunderstanding 
of what the datanucleus-api-jdo was, having never actually looked at it. I 
should have asked the question instead of suggesting that it be removed. My bad.

It will help greatly if you could also look at the release artifacts that 
Tilmann sent a link to.

Warm regards,
Craig


On Nov 27, 2021, at 5:53 AM, Andy Jefferson  wrote:


1. JDO 3.2 release RC4
The release includes DataNucleus reference in the pom: core 5.2.7;
rdbms 5.2.7; api-jdo 5.2.7; jdo-query 5.0.9; api-jpa 5.2.6.
Are these the right DataNucleus versions for the 3.2 release?
We probably should remove the datanucleus api-jdo and instead use the official

3.2 api.

If you intend JDO 3.2 to be for JRE 1.8+ then you need the LATEST in the v5.x
series
datanucleus-core 5.2.9
datanucleus-api-jdo 5.2.7
datanucleus-api-jpa 5.2.8
datanucleus-rdbms 5.2.9
datanucleus-jdo-query 5.0.9

Removing datanucleus-api-jdo will make your life much harder since then you
will be testing DataNucleus with NO SUPPORT for the JDO API. That is the DN
API-support jar, not the API interfaces. Just like the associated datanucleus-
api-jpa jar provides SUPPORT for the JPA API.



Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org   Twitter: @datanucleus)



Craig L Russell
c...@apache.org

[VOTE] Please vote on JDO 3.2 release

2021-11-25 Thread Tilmann


Hi,

Please vote on the JDO 3.2 release. Voting will be open until Monday,
November 29.

You may download the JDO 3.2 release artifacts from the staging
repository:
https://repository.apache.org/content/repositories/orgapachejdo-1004/


The JDO API release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1004/javax/jdo/jdo-api/3.2-RC4/

The JDO TCK release artifacts are in
https://repository.apache.org/content/repositories/orgapachejdo-1004/org/apache/jdo/3.2-RC4/

Regards,
Til

Please test staged JDO 3.2 release (RC4)

2021-11-21 Thread Tilmann


Dear all,

I just staged JDO 3.2 RC4. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1004/

Changes:
- the "source-release" archives are now signed with SHA512 in addition
to md5/sha1
- ReleaseHowTo.md updated

Note:
In this release all files are still delivered with a .sha1 and .md5
file. This is due to a technical problem which is tracked here:
https://issues.apache.org/jira/browse/INFRA-22540
This is also the reason why RC3 failed and was no put up for a vote.

Best,
Tilmann


On 08/11/2021 23:20, Tilmann Zäschke wrote:

Dear all,

I just staged JDO 3.2 RC2. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1002

Changes:
- archives are now available as .zip and as  .tar.gz
- the "source-release" archives are now signed with SHA512
- The pom now has the "timestamp" property
- Some updates on the release instructions

Note:
- The API is still signed with sha1 only. I believe this is in line with
the
  requirement of Nexus which does not seem to support SHA256 or SHA512.
- The parent .pom has its  section removed. It gets removed by the
  release plugin, not sure whether this is a feature or how it can be
avoided.
  I will add the section again after the release.

Kind regards,
Tilmann

Re: JDO TCK Conference Call Thursday November 18 10:15 PST 19:15 CET

2021-11-18 Thread Tilmann Zäschke

Hi Craig,

apparently we missed each other by a few minutes only, we stuck around
until 20:07...

We discussed the INFRA issue.
One alternative would be to wait a few days, and if it doesn't look like
its going to be solved in the next week, we could just release RC4
anyway (RC3 is burnt), with sha512 where possible but without removing
any of the old md5/sha1. Anyone who wants can then use sha512, but we
could get the release out.

Or we wait for the ticket to be resolved as you suggested.
What do you think?

Til

On 18/11/2021 20:18, Craig Russell wrote:

Sorry gang,

I had the time wrong on my personal calendar so I missed the meeting.

I noticed the JIRA for Nexus.

Once the issue has been fixed and the RC3 closed, I have all I need to file the
Maintenance Review with the JCP.

Craig

On Nov 17, 2021, at 12:11 PM, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday November 18 10:15 Pacific Standard
Time (PST) 19:15 Central Europe to discuss JDO TCK issues and status.

We use the following dial-in for audio and video. You need a Skype account to
join.
https://join.skype.com/lKWOxZDu2O5U

Agenda:
1. JDO 3.2 release RC3
2. JDO-795 "Publishing the 3.2
specification"https://issues.apache.org/jira/projects/JDO/issues/JDO-795
3. JSR-243 Maintenance Release
4. PR #34 "Revert "Pre 3.2 release fixes"
https://github.com/apache/db-jdo/pull/34
5. PR #32 "3.2" https://github.com/apache/db-jdo/pull/32
6. Issues with Fix Version JDO-3.2
https://issues.apache.org/jira/issues/?jql=project%20%3D%20JDO%20AND%20fixVersion%20%3D%20%22JDO%203.2%22
7. Other issues

Action Items from weeks
[Nov 11 2021] AI Craig: send 3.2-RC3 artifacts to JCP for review.
[Oct 07 2021] AI Craig send a private message to all JSR-243 Expert Group
members asking if they wish to continue.
[Sep 09 2021] AI Tobias pick a sample chapter to get an idea how much work it
is to migrate specification to LaTeX
[Aug 05 2021] AI Craig contact JCP governance mavens
[Mar 25 2021] AI Craig: investigate "merging" papajdo and apache.clr accounts
[Jan 07 2021] AI Craig update to add workflow for contributions and preview of
changes.
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL
datastores":https://issues.apache.org/jira/browse/JDO-651?
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about
JDOHelper methods.

Regards Michael

Craig L Russell
c...@apache.org

Please test staged JDO 3.2 release (RC2)

2021-11-08 Thread Tilmann Zäschke


Dear all,

I just staged JDO 3.2 RC2. Please have a look and report any problems:
https://repository.apache.org/content/repositories/orgapachejdo-1002

Changes:
- archives are now available as .zip and as  .tar.gz
- the "source-release" archives are now signed with SHA512
- The pom now has the "timestamp" property
- Some updates on the release instructions

Note:
- The API is still signed with sha1 only. I believe this is in line with
the
  requirement of Nexus which does not seem to support SHA256 or SHA512.
- The parent .pom has its  section removed. It gets removed by the
  release plugin, not sure whether this is a feature or how it can be
avoided.
  I will add the section again after the release.

Kind regards,
Tilmann

Re: Naming of release candidates

2021-11-07 Thread Tilmann

Hi,

I have some more questions before putting out a RC2.

I played around with SHA512 signing and found the following happening
consistently:

- the "sources-release" gets signed with SHA512. However, all files
(including the .sha512 file!) are signed again with sha1. I don't know
where this happens, the mvn output log only shows signing and uploading
of the SHA512 signed files.
- the "src" files are only ever signed with SHA1.

See:
https://repository.apache.org/content/repositories/snapshots/org/apache/jdo/3.2-RC2-SNAPSHOT/
https://repository.apache.org/content/repositories/snapshots/javax/jdo/jdo-api/3.2-RC2-SNAPSHOT/

However, there are some interesting statements in the Apache doc
(https://infra.apache.org/publishing-maven-artifacts.html), specifically
section 3:

a) "Don't try to publish |.sha256| or |.sha512| files; Nexus doesn't
handle them.".
a.1) Does this mean that it is alright/intended that everything is
(also) signed with sha1, i.e. because Nexus will only accept sha1?
a.2) Is it okay to sign only the "sources-release" with sha512?
The example in https://maven.apache.org/pom/asf/ refers only
to signing the "source-release" file.

b) "Remove |.md5|s in |dist.apache.org/repos/dist/release/| manually."
b.1) Does this it is okay to have more files than necessary uploaded
because we can/should remove them afterwards?
For example, we could also manually remove the signed
signature files, such as
jdo-3.2-RC2-20211107.210811-3-source-release.zip.sha512.sha1

Best,
Til

Please test staged JDO 3.2 release

2021-11-02 Thread Tilmann


Dear all,

We are nearing the final stages of releasing JDO.3.2.

I just staged the maven artifacts for JDO 3.2 RC1. Please have a look
and report any problem.
They are available here:
https://repository.apache.org/content/repositories/orgapachejdo-1001/

Side note:
As per the instructions, the artifacts have not been released, i.e. they
are not available on the public repositories (maven central etc). I
looks like this had been handled differently for 3.1-RC1, which was
apparently released to those repositories.

Kind regards,
Til

Release preparation pull request

2021-10-17 Thread Tilmann


Hi,

I created a PR with some fixes for getting RC1 out:

https://github.com/apache/db-jdo/pull/33

It contains mostly doc updates, a RAT update  and an added timestamp for
the parent .pom.
Could I get 1-2 people to confirm that these changes are fine?

Thanks,
Tilmann

Re: Meet an hour early tomorrow?

2021-09-08 Thread Tilmann


I may be a bit late, i.e. 19:15ish (=10:15?).

Regards,
Til

On 08/09/2021 21:12, Michael Bouschen wrote:

Hi Craig,

works for me.

Regards Michael


Hi,

I have a conflict at 11:00. Could we meet at 10:00 instead?

Thanks
Craig

Craig L Russell
c...@apache.org

spec review questions & Thursday

2021-08-31 Thread Tilmann


Dear all,

I went through some more chapters (see JIRA) and I have two more questions:
- Section 16.1.3 has three "TODOs" (text in red color), I don't think
they are recent, do we know anything about these?
- Chapter 17 has a number of assertion A17.*, but I couldn't find any
JUnit tests for those. Is that known/okay/expected?

Unfortunately I cannot make in on Thursday. I should be available next
week as usual.

Cheers,
Til

Assertions in spec

2021-08-21 Thread Tilmann


Hi,

sorry but I have to ask again:

- Assertions are created by setting the style of  e.g. "A6.4.3-18[" and
the following "]" to "Assertion", correct?
  (As described in the README.odt)

- Technically this is only a "Style", so there is no way to confirm that
I did it right except that the created PDF should look "fine"?

Thanks,
Tilmann

Re: Converted classes behavior

2021-05-09 Thread Tilmann


Hi Craig,

I wonder whether this is really 100% correct. I wasn't there when this
was written but maybe it was meant to mean something slightly different?
Some thoughts:

*Alternative interpretations:*

1) I think it possible that it just means "[The system should behave as
if] Second class objects of mutable classes ". I am not sure why we
require these classes to be enhanced, it feels like it should be
sufficient in this case if JDO specifies _how_ the system should behave,
not how it is implemented.

2) As it has been suggested earlier , it may also just mean that a JDO
implementation is allowed to provide an own implementation of system
classes, that would avoid having to enhance system classes.

*Potential Issues:*

3) System classes may be used all over the place (including by the JDO
implementation itself). Enhancing these classes can easily have
undesirable side effects, from performance issues, to memory issues
(requiring more space), to correctness issues (if the application
somewhere else serializes system classes it may fail if these classes
have additional state (even if it is marked as 'transient').

4) Forward compatibility and missing bug fixes. If we
compile-time-enhance system classes (and generally 3rd party classes), a
JDO application that is delivered to a customer will contain system
classes. The problem here is that these classes may be incompatible with
native system classes if the user uses a later JVM version (potentially
containing API changes: remember when streams were added to
collections); even if it works, the user will not benefit from
bug/security fixes that are delivered in new JVM versions (but not in
the compile-time enhanced classes).
Of course this could be alleviated by disallowing compile-time
enhancement and allowing only runtime-enhancement for system classes,
but that would also be a bit 'inconsistent'.

*Proposal**:*

5) I propose to rephrase this to "allow" JDO implementations to enhance
system classes when they want to, but not require it. Instead it should
be sufficient if an owning object tracks access and updates where possible.

*Assumed impact of spec change:*

6) For JDO implementations that have implemented this, I assume that
such a change would have little to no impact. It is backwards compatible
because implementations do not need to change anything unless they want to.

7) For users it is a bit more complex. Personally I always assumed that
a direct change of a SCO would not be tracked, so there would be no
change (in my personal case). What I did assume is that the owning
object of an embedded class would keep track of updates to the embedded
class. In my experience this would usually work because it would only
break if an owning object returns its embedded object for others to
modify it, which I think has a bit of a code smell to it (again my
personal opinion).
This logic is similar to other internal fields, if an owning objects
returns mutable internal state (or makes its fields public) then it
basically gives up any control and anything can happen.

*Final words:*

8) I understand that enhanced system classes would be required to ensure
100% tracking of dirty embedded objects. However, since this comes with
its own problems, see 3) and 4). I think requiring the owning object to
track changes is usually sufficient and probably also easier to implement.

Sorry for the rant :-)
Cheers,
Til



On 06/05/2021 23:58, Craig Russell wrote:

While researching Second Class Object behaviors, I found this in the 
specification 6.3:

Second Class Objects of mutable system classes and persistence-capable classes 
track changes made to them, and notify their owning FCO that they have changed.

Since converted classes most resemble persistence-capable classes, I proposed 
this change to 6.3:

Second Class Objects of mutable system classes, converted classes, and 
persistence-capable classes track changes made to them, and notify their owning 
FCO that they have changed.

But this implies that we enhance converted classes. So:

1. What does JPA do about converted classes? Does it enhance them so they track 
changes made to mutable instances?

2. What are the requirements for converted classes in JDO? Just follow whatever 
JPA does?

If we really want to require enhancing converted classes, we should be specific 
about it. And add a test case or three to the TCK.

To test this, we will need a mutable converted class, perhaps by adding a 
mutator method for the x value. Then, modify the x value and see if the 
instance is marked as dirty.

Craig L Russell
c...@apache.org

Re: [DISCUSS] Rename main branch?

2021-04-21 Thread Tilmann


I also do not feel strongly about either name, especially (as mentioned
before) because it derives from the master record analogy.

If I may add something: I asked a good friend of mine (an Afro-American
woman with relevant ancestry for this topic). She said that she
"wouldn't bother" renaming anything in this context. She would in no way
feel put off by the term 'master' or even associate it with anything
bad, not least because it has many (often positive) meanings outside the
historic context (e.g. master degree).

TL;DR
I am slightly in favor of leaving it as is, but wouldn't object if
anyone wants to change it.

Cheers,
Til

On 21/04/2021 21:36, Tobias Bouschen wrote:

I don't think there is any way of making everybody happy here. No
matter what we do, somebody will most likely complain. From reading
the discussions you linked to, Craig, the arguments seem to go around
in circles. Either it matters or doesn't matter what the etymological
origin/usage/context of the usage in git is depending on the point the
different sides want to make and which quotes from different prominent
git developers they are referring to. Furthermore, the discussion has
devolved more into a discussion about "social justice warriors" and
"political correctness" than the actual topic at hand.

I, personally, don't see an issue with the usage of the word "master"
in this context (or at least not enough of an issue to warrant the
time investment of changing the infrastructure). Even if the word were
to have come from the "master/slave" terminology in BitKeeper (which
is a conjecture at best), it does not really make sense in this
context. The usage in the context of "master record" is a clear and
fitting analogy for the concept at hand in my opinion. Reading the
discussion hasn't really changed my mind in this regard. But if there
are more constructive discussions/opinions on the topic that could
change my view, I am definitely open to it. Links are welcome. :)

So my suggestion is still the same: wait and see if there is an
official stance of the Apache organization regarding the topic (which
is probably unlikely) or anybody involved with the project feels
strongly enough about it to warrant the change. Waiting for an Apache
ruling has the added bonus of avoiding the entire discussion as we can
simply defer it pointing to the "external" decision made by the Apache
organization.

But, if anybody else in the team feels more strongly about this topic
and would like the name to change, I am not opposed to it. I just
don't see any gain in doing it right now just to get ahead of the
discussion (as this will only lead to complaints coming from the other
side, as you have already seen).

Best regards,
Tobias

On 4/20/21 7:44 PM, Michael Bouschen wrote:

Hi Craig,

I'm fine with renaming master to main and have main the default branch
of our repositories. This follows what github is doing for new projects.

If we do rename I see the following steps:
- Rename master to main in both repositories gitbox and github. Most
probably this involves infra.
- Adapt some scripts and our documentation (WebSite, READMEs, ...)
- Change our workspaces as described in
https://issues.apache.org/jira/browse/JDO-793

Regards Michael


Hi,

I'd like to have all of us come to the same understanding of
renaming the main branch of our repos.

Here is some background reading to inform our decision.
https://github.com/pmmmwh/react-refresh-webpack-plugin/issues/113

Let's have a discussion now and vote later.

Regards,
Craig

Craig L Russell
c...@apache.org

Re: [db-jdo-site] branch master updated (dddc5e4 -> 64e90c7)

2021-02-05 Thread Tilmann


Same here.

I reran the job, it is not obvious to me why it fails:

https://github.com/apache/db-jdo-site/runs/1841121479?check_suite_focus=true

Til


On 05/02/2021 19:45, Bouschen, Michael wrote:

HI Craig,

same here. I do not see the latest changes of get-involved on the live site. 
But the changes are in the content directory of the publish branch, so the 
github action was triggered.

Regards Michael



I'm still not seeing the changes to get-involved.

Anyone else seeing the new content?

Craig



On Feb 4, 2021, at 2:42 PM, Craig Russell 
 wrote:

I still have not seen these changes to get-involved published to the live site.

Are we still suffering from "JDO Site Failed To Deploy"?

Craig



On Feb 4, 2021, at 12:06 PM, tilma...@apache.org 
wrote:

This is an automated email from the ASF dual-hosted git repository.

tilmannz pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/db-jdo-site.git.


   from dddc5e4  Remove 'docs/' and 'content'
add 64e90c7  Update get-involved.adoc (#22)

No new revisions were added by this update.

Summary of changes:
src/main/asciidoc/get-involved.adoc | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)




Craig L Russell
c...@apache.org




Craig L Russell
c...@apache.org




--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel:   +49 30 235520-33
Fax:  +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de
Web:   www.akquinet.de

Geschäftsführung: Martin Weber, Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[Facebook]  
[XING]  
[LinkedIn]  
[Twitter]

Re: Is it worth establishing a separate mailing list for the GitHub message traffic?

2021-02-04 Thread Tilmann


Maybe it is possible to reduce the volume a bit?

For example currently many messages are sent twice, once from GitHub and
again from GitBox. Maybe than can be avoided?

Tilmann



On 04/02/2021 23:21, JDO Spec wrote:

Personally, I have no problem with the number of messages on the jdo-dev list 
that come from github/gitbox/contributors.

If we push it off to another list it's just one more list I will need to 
subscribe to in order to pay attention.

It's all important. In the near future when we are mostly done with the web 
site, it won't matter.

Craig



On Feb 4, 2021, at 1:04 PM, Bouschen, Michael 
 wrote:

Hi Tilmann,

yes, I'll put it one the agenda.

Regards Michael

yes it does, we merged 4 (or 5?) PRs today, but I agree it is a bit noisy.

@Michael, should we put this on the agenda for next time?

tilmann



On 04/02/2021 21:29, Bryan Pendleton wrote:
Seems like the new website machinery generates a lot of messages?

bryan

-- Forwarded message -
From: GitBox mailto:g...@apache.org>><mailto:g...@apache.org 
<mailto:g...@apache.org>>
Date: Thu, Feb 4, 2021 at 11:20 AM
Subject: [GitHub] [db-jdo-site] tzaeschke merged pull request #19:
Update pom.xml
To: mailto:jdo-dev@db.apache.org>><mailto:jdo-dev@db.apache.org 
<mailto:jdo-dev@db.apache.org>>



tzaeschke merged pull request #19:
URL: https://github.com/apache/db-jdo-site/pull/19 
<https://github.com/apache/db-jdo-site/pull/19>






This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org <mailto:us...@infra.apache.org><mailto:us...@infra.apache.org 
<mailto:us...@infra.apache.org>>


--
Michael Bouschen
akquinet tech@spree GmbH
Bülowstraße 66 • D-10783 Berlin
Tel:   +49 30 235520-33
Fax:  +49 30 217520-12

E-Mail: michael.bousc...@akquinet.de 
<mailto:michael.bousc...@akquinet.de><mailto:michael.bousc...@akquinet.de 
<mailto:michael.bousc...@akquinet.de>>
Web:   www.akquinet.de <http://www.akquinet.de/><http://www.akquinet.de/ 
<http://www.akquinet.de/>>

Geschäftsführung: Martin Weber, Dr. Torsten Fink, Heinz Wilming
Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680

[Facebook]<http://www.facebook.com/akquinet <http://www.facebook.com/akquinet>>  
[XING]<https://www.xing.com/companies/akquinetag <https://www.xing.com/companies/akquinetag>>  
[LinkedIn]<https://www.linkedin.com/company/akquinet-ag <https://www.linkedin.com/company/akquinet-ag>>  
[Twitter]<https://twitter.com/akquinet <https://twitter.com/akquinet>>

I created an Infra ticket to disable GitHub Pages.

2021-02-04 Thread Tilmann


https://issues.apache.org/jira/browse/INFRA-21384

tilmann

Re: Is it worth establishing a separate mailing list for the GitHub message traffic?

2021-02-04 Thread Tilmann Zäschke


yes it does, we merged 4 (or 5?) PRs today, but I agree it is a bit noisy.

@Michael, should we put this on the agenda for next time?

tilmann



On 04/02/2021 21:29, Bryan Pendleton wrote:

Seems like the new website machinery generates a lot of messages?

bryan

-- Forwarded message -
From: GitBox 
Date: Thu, Feb 4, 2021 at 11:20 AM
Subject: [GitHub] [db-jdo-site] tzaeschke merged pull request #19:
Update pom.xml
To: 



tzaeschke merged pull request #19:
URL: https://github.com/apache/db-jdo-site/pull/19






This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: DB web site migration from CMS

2021-02-04 Thread Tilmann


Just to ive a few more details: We also had .xdoc files in JDO. The path
we took is generate .html from them and then generate .adoc (asciidoc)
from these .html files.

I wrote some ad-hoc tooling for the .html->.adoc conversion:
https://github.com/apache/db-jdo-site/tree/master/src/main/java

We now edit the adoc files manually when needed (can be done directly in
the GitHub website) and use a "maven compile" to turn them into html
(maven is done automatically via GitHub Actions, but this part is still
work in progress).

Cheers,
Tilmann


On 04/02/2021 20:12, Rick Hillegas wrote:

Thanks, Craig. I have logged
https://issues.apache.org/jira/browse/INFRA-21381 to request more
information.

On 2/4/21 10:52 AM, Craig Russell wrote:

What the JDO team did was to open an INFRA JIRA asking for help in
migration.

That worked well. There are lots of choices for web sites that do not
use CMS.

Infra can point you to the relevant pages on the wiki (I do not know
them right offhand).

Regards,
Craig


On Feb 4, 2021, at 10:11 AM, Rick Hillegas 
wrote:

Could someone please post pointers to the CMS migration effort so
that I can educate myself about what it entails? Once I know more, I
can start a Derby community discussion about what, if anything, can
be done before this deadline.

Thanks,
-Rick

On 2/2/21 11:26 AM, Craig Russell wrote:

Hi,

priv...@db.apache.org in bcc...

The JDO project is almost complete migrating the db.apache.org/jdo
site from the soon-to-be-retired CMS system to a new github site
repo using GitHub Actions and .asf.yaml to publish the site.

Infra wants to know what the plans are for the main site, Derby,
and Torque to migrate.

Craig

Craig L Russell
c...@apache.org


Craig L Russell
c...@apache.org

JDO-785 collaborative document

2020-11-08 Thread Tilmann Zäschke

Dear all,

Regarding JDO-785: I copied the file's content to a web-document so we may view
and edit collaboratively next time (just a proposition, if you find that
useful?):

https://docs.google.com/document/d/1rFZ_e4OZ4D8h208397iU9eQZaMjzlG1xWswojBW-2p4/edit?usp=sharing

I already made one change near the top.

Cheers,
Til

On 05/11/2020 20:33, Craig Russell wrote:

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: Thursday November 12 10:30 AM PST

Agenda:

1. JDO-785 "Update release instructions for new website and release process"
https://issues.apache.org/jira/browse/JDO-785

AI All review the "how to release" page. Question: should we put this into the
web site or leave it in the main repository? It's only useful for developers.

2. JDO-744 "XSD/DTD not published for JDO 3.1"
https://issues.apache.org/jira/browse/JDO-744

3. JDO-709 "Standardize field/property converters"
https://issues.apache.org/jira/browse/JDO-709

4. Issues with Fix Version JDO-3.2
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20JDO%20AND%20fixVersion%20%3D%20%22JDO%203.2%22%20ORDER%20BY%20status%20ASC>
5. Release Policy Updates
6. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to
prepare JCP Change Log
7. Other issues

AI Craig update the web page for implementations to refer to DataNucleus 5.2
and remove references to JDO 2.0 and 3.0.

Action Items from weeks past:
[Apr 22 2020] AI Andy fix page
https://github.com/apache/db-jdo-site/blob/master/src/main/asciidoc/impls.adoc
with latest DataNucleus implementations
[Feb 25 2020] AI Everyone review HowToReleaseJDO.md document: change svn to
git; review all generated distribution files.
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about
JDOHelper methods.

Craig L Russell
c...@apache.org

JUnit 5.7.0 vintage

2020-10-15 Thread Tilmann Zäschke


Hi Michael,

so the following worked mostly:


  org.junit.vintage
  junit-vintage-engine
  5.7.0


but if properly failed in the end with:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean (default-clean)
on project jdo: Failed to clean project: Failed to delete
C:\work\github\db-jdo\tck.txt -> [Help 1]

I usually get that as a warning, not as an error. But it may also
something wrong with my set-up.


Cheers,
Til

Shared simple document to draft new JDO website layout

2020-04-16 Thread Tilmann Zäschke


Dear all,

please have a look here:
https://docs.google.com/presentation/d/19RoED9sc2oAA1TrbENYNUwNPSnOU3P6Cd3DwvD4HqDY/edit?usp=sharing

I hope this is useful for drafting a new website layout.

Cheers,
Til

Re: JDO TCK Conference Call Thursday November 21 10 AM Pacific Standard Time (PST)

2019-11-21 Thread Tilmann

Hi Michael,

the link to the temporary website is https://apache.github.io/db-jdo-site/

Regards,
Til

On 21.11.2019 20:52, Michael Bouschen wrote:

Hi Tilman,

Gavin just added the settings as you requested. I see a link "Apache DB
JDO web site https://db.apache.org/;. Is this the link you were talking
about?

Regards Michael

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: Monday December 2 10:00 AM PST

Agenda:

1. JDO-779 "Migrate JDO Homepage / Online Documentation"
https://issues.apache.org/jira/browse/JDO-779
https://issues.apache.org/jira/browse/INFRA-17979
https://tzaeschke.github.io/test-jdo-asciidoc/

Initial port from svn to git has been done by Tilmann. Now working on cleaning
up the github repository.
Add README.md with instructions how to publish the generated site
Request infra to add settings to allow viewing the repo as a web site

2. JDO-712 "Require using the PMF schema definition with sequence names"
https://issues.apache.org/jira/browse/JDO-712

Need to update specification, modify TCK test and patch DataNucleus to cater
for the new spec. Volunteer needed.

3. JDO-652 "Provision of a typesafe refactor-friendly query capability for
JDOQL" https://issues.apache.org/jira/browse/JDO-652
4. JDO-778 "Adding overloaded methods to JDOQLTypedQuery to create a correlated
subquery" https://issues.apache.org/jira/browse/JDO-778

Michael wrote a test case which failed. AI Michael update the JIRA with the
failing lines of code. The non-typed query works but the typed query fails. The
proposed API change might also need to be modified.

5. Issues with Fix Version JDO-3.2
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20JDO%20AND%20fixVersion%20%3D%20%22JDO%203.2%22%20ORDER%20BY%20status%20ASC>
6. Release Policy Updates
7. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to
prepare JCP Change Log
8. Other issues

Action Items from weeks past:
[Aug 22 2019] AI Craig post some updates from email to the JIRA.
[May 6 2019] AI All: Look at other projects in Apache that use Jekyll or
github pages for generating pages. Also need to set up the directory and file
structure.
[Apr 25 2019] AI All: find a project to model
https://github.com/apache/incubator-skywalking http://skywalking.apache.org
https://lists.apache.org/list.html?bui...@apache.org:lte=7M:
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about
JDOHelper methods. In process.

Craig L Russell
c...@apache.org

JDO-779 website migration alpha

2019-11-17 Thread Tilmann


Hi,

I had a go at migrating the website to Asciidoc:

https://tzaeschke.github.io/test-jdo-asciidoc/

All pages are migrated with a somewhat lengthy script, the
header/menu/footer got some manual hacking.
It's pretty raw and I haven't fully populated the menu, but it may be
worth having a look.

Feedback (and PRs) is welcome.

Cheers,
Til


On 14.11.2019 19:38, Craig Russell wrote:

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: Thursday November 21 10:00 AM PST

Agenda:

1. JDO-712 "Require using the PMF schema definition with sequence names" 
https://issues.apache.org/jira/browse/JDO-712

We need to consider cases where: sequences can be per-schema and the user wants 
a sequence to be global; and sequences cannot be per-schema but there is a 
schema declared in the metadata.

2. JDO-779 "Migrate JDO Homepage / Online Documentation" 
https://issues.apache.org/jira/browse/JDO-779 
https://issues.apache.org/jira/browse/INFRA-17979

Investigate using a tool (pandoc?) to convert from current xdoc (or html) to 
asciidoc. Then use a tool to generate the site. Volunteer needed.

3. JDO-652 "Provision of a typesafe refactor-friendly query capability for 
JDOQL" https://issues.apache.org/jira/browse/JDO-652
4. JDO-778 "Adding overloaded methods to JDOQLTypedQuery to create a correlated 
subquery" https://issues.apache.org/jira/browse/JDO-778
5. Issues with Fix Version JDO-3.2 
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20JDO%20AND%20fixVersion%20%3D%20%22JDO%203.2%22%20ORDER%20BY%20status%20ASC>
6. Release Policy Updates
7. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
8. Other issues

Action Items from weeks past:
[Aug 22 2019] AI Craig post some updates from email to the JIRA.
[May  6 2019] AI All: Look at other projects in Apache that use Jekyll or 
github pages for generating pages. Also need to set up the directory and file 
structure.
[Apr 25 2019] AI All: find a project to model 
https://github.com/apache/incubator-skywalking http://skywalking.apache.org 
https://lists.apache.org/list.html?bui...@apache.org:lte=7M:
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Craig L Russell
c...@apache.org

JDO-712 - SEQUENCE/SCHEMA default names

2019-11-13 Thread Tilmann Zäschke


Hi,

After the last telecon (that I attended) I had a look at various DBMS
for their handing of SEQUENCEs and schema
spaces.

If I remember correctly, the question in the telecon was to see which
DBMS support schema names for sequences.
I am a bit unclear now how this relates to the ticket, anyway, here is
what I found:

Postgres, Oracle and SQL Server allow creating sequences with optional
schema name: [schema_name.]sequence_name
MariaDB and DB2 do not appear to support schema names for sequences.
MySQL ans SQLite do not appear to support named sequences.

Some Object DBMS (such as ObjectDB) support named sequences via JPA
(@GeneratedValue/@SequenceGenerator).
As I understand, there is no way to create/use sequences without
attaching them to a Java field (=column in a table), so they are
implicitly bound to a table/schema.

No-SQL databases such as MongoDB, CouchDB or Cassandra do not really
support sequences as such, ie they clearly discourage their use even if
suported.

Also, DataNucleus:
http://www.datanucleus.org/products/datanucleus/jdo/mapping.html#valuegen_sequence


There seems to be no standard naming convention, except that the schema
name, if present, is separated by a '.' from from the sequence name.

Ticket: https://issues.apache.org/jira/browse/JDO-712

Kind regards,

Til

Re: JDO SVN repository

2017-11-15 Thread Tilmann Zäschke

Thanks, it appears to be working again, must have been something 
temporary... (?). Like last the last time.


Thanks,

Til


On 14.11.2017 08:07, Michael Bouschen wrote:

Hi,

it is working for me. the web-view
(https://svn.apache.org/viewvc/db/jdo) is also working. Network or
firewall issue?

2 trunk > svn up
Updating '.':
At revision 1815188.
3 trunk > svn info
Path: .
Working Copy Root Path: /Users/mbouschen/Projects/JDO/workspace/jdo
URL: https://svn.apache.org/repos/asf/db/jdo/trunk
Relative URL: ^/db/jdo/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1815188
Node Kind: directory
Schedule: normal
Last Changed Author: mbo
Last Changed Rev: 1814610
Last Changed Date: 2017-11-08 19:01:38 +0100 (Mi, 08 Nov 2017)

Regards Michael

svn up
Updating '.':
U
tck/src/java/org/apache/jdo/tck/query/jdoql/operators/BitwiseBinaryOperators.java
Updated to revision 1815145.
[MacBook-Pro-9:~/apache/jdo/trunk] clr% date
Mon Nov 13 14:35:47 PST 2017
[MacBook-Pro-9:~/apache/jdo/trunk] clr% svn info
Path: .
Working Copy Root Path: /Users/clr/apache/jdo
URL: https://svn.apache.org/repos/asf/db/jdo/trunk
Relative URL: ^/db/jdo/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1815145
Node Kind: directory
Schedule: normal
Last Changed Author: mbo
Last Changed Rev: 1814610
Last Changed Date: 2017-11-08 10:01:38 -0800 (Wed, 08 Nov 2017)



On Nov 13, 2017, at 12:28 PM, Tilmann Zäschke <tilmann_...@gmx.de> wrote:

Hi,

is anyone else having trouble accessing the JDO SVN repo?

Neither SVN checkout on console nor the web-view (https://svn.apache.org/viewvc/db/jdo) 
appears to work, they just hang: "The server at svn.apache.org is taking too long to 
respond."

I first tried yesterday, but it is still not working for me...

Does it work for everybody else?

Cheers,
Tilmann


On 07.11.2017 19:30, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday, November 8 at 9:30 AM Pacific Time 
(PST) to discuss JDO TCK issues and status.

We use the new dial-in for audio and video. You need a Skype account to join.
https://join.skype.com/euV54RJwJBcf

Agenda:

1. New JIRA JDO-765 "TCK should fail if tests fail" 
https://issues.apache.org/jira/browse/JDO-765
2. JDO-764 "Allow JDO annotations to be used in meta-annotations" 
https://issues.apache.org/jira/browse/JDO-764
3. JDO-745 "Support bitwise operations in JDOQL" 
https://issues.apache.org/jira/browse/JDO-745
4. Remark from Andy about having the TCK runnable on other RDBMS.
5. TCK lifecycle tests fail.
6. Need to resolve specification lead issue now that Craig is no longer working 
for Oracle.
6. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
8. Other issues

Action Items from weeks past:

[Nov 2  2017] AI Andy were the tck tests run after changes to DataNucleus?
[Oct 5  2017] AI Craig file a new JIRA about having the TCK runnable on other 
RDBMS
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael


Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

JDO SVN repository

2017-11-13 Thread Tilmann Zäschke


Hi,

is anyone else having trouble accessing the JDO SVN repo?

Neither SVN checkout on console nor the web-view 
(https://svn.apache.org/viewvc/db/jdo) appears to work, they just hang: 
"The server at svn.apache.org is taking too long to respond."


I first tried yesterday, but it is still not working for me...

Does it work for everybody else?

Cheers,
Tilmann


On 07.11.2017 19:30, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday, November 8 at 9:30 AM Pacific Time 
(PST) to discuss JDO TCK issues and status.

We use the new dial-in for audio and video. You need a Skype account to join.
https://join.skype.com/euV54RJwJBcf

Agenda:

1. New JIRA JDO-765 "TCK should fail if tests fail" 
https://issues.apache.org/jira/browse/JDO-765
2. JDO-764 "Allow JDO annotations to be used in meta-annotations" 
https://issues.apache.org/jira/browse/JDO-764
3. JDO-745 "Support bitwise operations in JDOQL" 
https://issues.apache.org/jira/browse/JDO-745
4. Remark from Andy about having the TCK runnable on other RDBMS.
5. TCK lifecycle tests fail.
6. Need to resolve specification lead issue now that Craig is no longer working 
for Oracle.
6. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
8. Other issues

Action Items from weeks past:

[Nov 2  2017] AI Andy were the tck tests run after changes to DataNucleus?
[Oct 5  2017] AI Craig file a new JIRA about having the TCK runnable on other 
RDBMS
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael

Re: JDO TCK Conference Call Thursday April 12, 9 AM Pacific Daylight Time (PDT)

2017-04-11 Thread Tilmann


Du meinst Wednesday, oder?

LG,
Til


On 11.04.2017 21:09, Michael Bouschen wrote:

Hi,

We will have our regular meeting Thursday, April 12 at 9 AM Pacific Daylight 
Time (PDT) to discuss JDO TCK issues and status.

We use the new dial-in for audio and video. You need a Skype account to join.
https://join.skype.com/euV54RJwJBcf

Agenda:

1. Mail from Craig: setParameters, setNamedParameters

2. JDO-759 "Spec update to clarify whether methods that are documented to be hints 
must not throw exceptions" https://issues.apache.org/jira/browse/JDO-759: Anything 
left?

3. New JIRA JDO-761 "Add TCK test running sample queries from the spec" 
https://issues.apache.org/jira/browse/JDO-761

4. JIRA JDO-760 "Spec update regarding whether Query.execute() returns List or 
Collection" https://issues.apache.org/jira/browse/JDO-760

5. Is anything still unresolved with JDO-749 "Support for java.time types, and 
querying using associated methods" https://issues.apache.org/jira/browse/JDO-749

6. Is anything still unresolved with JDO-745 "Support bitwise operations in 
JDOQL" https://issues.apache.org/jira/browse/JDO-745

7. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log

8. Other issues

Action Items from weeks past:

[Mar 23 2017] AI all: review the test case for JDO-761.
[Mar 23 2017] AI Craig: file a JIRA about query methods setParameters, 
setNamedParameters and write a test case to see how RI handles this case.
[Feb 24 2017] AI Michael: are there any TCK tests for the new methods JDO-749?
[Feb 24 2017] AI Michael: are there any TCK tests for the new methods? Any 
additional spec updates JDO-745?
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Query compilation etc

2017-02-26 Thread Tilmann Zäschke


Hi,

a quick recap of the discussion we had in the last telecon. This was 
sparked by the discussion whether Query.compile() may need database 
access, i.e. whether it should fail when called outside transaction 
borders.


(TL;DR): See conclusion below.

Querying usually requires the following steps: query compilation 
(building an abstract syntax tree, query optimization and query execution.


Query compilation is rather simple, all it needs is knowledge of the 
database data model in order to verify compliance with the database schema.


Query optimization is usually more complicated, it can use static 
heuristics that are known on each client (table sizes, min/max values of 
indexes) but may also use information that is only available in the 
database. Information that is only available in the database included, 
for example, how many object does an index have in a given range. If one 
index has 4 objects and the other has 500, then using the first index 
may be the better choice.


JDO supports two separate steps: compilation and execution. The idea (as 
I understand) is to reuse queries efficiently by executing the 
compilation only once, while allowing to change parameters on compiled 
queries.


It seems that some query optimization can be done during the compilation 
step (such as removing redundant terms or choosing indexes based on 
static information, for example if there is only one index). Others, 
like choosing between different index, may depend on the actual 
parameters given and on the actual value distribution in a given index, 
as noted above.


It appears that query optimization could, and maybe should, be split 
into two parts. The first part is based on static information and can be 
performed during the compile() step. The second part may require 
database access, but may depends on the actual query parameters, so it 
will often be impossible to do this in the compilation step where the 
parameters may not be known. The second part can in many cases only be 
done during query execution.


Conclusion: At least for the optimizations that we considered, the 
current API works perfectly fine. Static optimization can be done during 
compile(), dynamic optimization can be done during execute(). This mean 
that compile() should work fine outside transactions boundaries.



Cheers,

Tilmann

Re: JDO-751 "Support for Java8 Optional" with subqueries - request for feedback

2016-09-24 Thread Tilmann


Another questions and my findings on using optional in subqueries:

1) Using Optional inside subqueries works just fine, as expected.

String singleStringJDOQL1 =
"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +
"(select  max(a.id) from " + 
OptionalSample.class.getName() + " a " +

"where a.optionalPC.isPresent() ) == id";

String singleStringJDOQL2 =
"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +
"(select  max(a.id) from " + 
OptionalSample.class.getName() + " a " +

"where a.optionalPC.get() != null) == id";

 I will upload a modified test harness that checks this functionality.


2) Another question.
According to 
https://docs.oracle.com/cd/E13189_01/kodo/docs324/ref_guide_subqueries.html 
(last example), subqueries can return collections. I tried to to call 
".isEmpty()" and ".get(0)" on them and I get (I hope I didn't screw up 
my tests again):


"Cannot perform operation ".isEmpty" on 
org.datanucleus.store.rdbms.sql.expression.SubqueryExpression"


"Cannot perform operation ".get" on 
org.datanucleus.store.rdbms.sql.expression.SubqueryExpression"


Query example:

String singleStringJDOQL1 =
"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +

"(select from " + OptionalSample.class.getName() + " a " +
"where a.optionalPC != null).isEmpty()";

String singleStringJDOQL4 =
"SELECT FROM " + OptionalSample.class.getName() + " WHERE " +
"(select from " + OptionalSample.class.getName() + " a " +
"where a.optionalPC != null).get(0).optionalPC.isPresent()";

In the spec I couldn't find a definition of what subqueries should 
return (examples in 14.10.18 and 14.10.19 return aggregates). So I 
suppose they should be able to return collections?
It seems that the TCK tests for subqueries use exclusively aggregates, 
so I'm not sure whether this is an omission or whether it is nor 
supposed to be possible.


Below is a code snippet that can be simply plugged in into the 
SupportedOptionalMethods.java test.


Cheers,
Tilmann

/**
 * This methods tests that subqueries as collections.
 */
public void testSubqueriesNoOptional() {
//TODO
//this gives:
//Cannot perform operation ".isEmpty" on 
org.datanucleus.store.rdbms.sql.expression.SubqueryExpression

//However, it should be possible according to:
//https://docs.oracle.com/cd/E13189_01/kodo/docs324/ref_guide_subqueries.html
String singleStringJDOQL1 =
"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +

"(select from " + OptionalSample.class.getName() + " a " +
"where a.optionalPC != null).isEmpty()";
Object[] expectedResult1 = new Object[]{oidReferencedPC1};
checkSingleStringQuery(singleStringJDOQL1, expectedResult1);

//TODO
//This gives:
//Cannot perform operation ".get" on 
org.datanucleus.store.rdbms.sql.expression.SubqueryExpression

String singleStringJDOQL4 =
"SELECT FROM " + OptionalSample.class.getName() + " WHERE " +
"(select from " + OptionalSample.class.getName() + " a " +
"where a.optionalPC != null).get(0).optionalPC.isPresent()";
Object[] expectedResult4 = new Object[]{oidReferencedPC1};
checkSingleStringQuery(singleStringJDOQL4, expectedResult4);
}



On 24.09.2016 18:59, Tilmann wrote:

Thanks!

Looks like I made a mistake during results checks, it works now, sorry 
for that.


Tilmann


On 24.09.2016 18:32, Craig Russell wrote:

The subselect would return 88 and then the outer select would become

"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +

“(88) == id”;

Seems to me this should select the object whose id is 88.

Craig


On Sep 24, 2016, at 9:22 AM, Tilmann <zaesc...@gmx.de> wrote:

Hi,

could I get some feedback?

I tried the following subquery:

"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +
"(select  max(a.id) from " + 
OptionalSample.class.getName() + " a " +

"where a.optionalPC != null) == id";

This returns '88' (an integer) instead of the object with id==88. Is 
this expected to return an integer?


Full code (can be used in SupportedOptionalMethods.java):
   String singleStringJDOQL2 =

Re: JDO-751 "Support for Java8 Optional" with subqueries - request for feedback

2016-09-24 Thread Tilmann


Thanks!

Looks like I made a mistake during results checks, it works now, sorry 
for that.


Tilmann


On 24.09.2016 18:32, Craig Russell wrote:

The subselect would return 88 and then the outer select would become

"SELECT FROM " + OptionalSample.class.getName() + " WHERE " +
“(88) == id”;

Seems to me this should select the object whose id is 88.

Craig


On Sep 24, 2016, at 9:22 AM, Tilmann <zaesc...@gmx.de> wrote:

Hi,

could I get some feedback?

I tried the following subquery:

"SELECT FROM " + OptionalSample.class.getName() + " WHERE " +
"(select  max(a.id) from " + OptionalSample.class.getName() + " a 
" +
"where a.optionalPC != null) == id";

This returns '88' (an integer) instead of the object with id==88. Is this 
expected to return an integer?

Full code (can be used in SupportedOptionalMethods.java):
   String singleStringJDOQL2 =
"SELECT FROM " + OptionalSample.class.getName() + " WHERE " +
"(select  max(a.id) from " + OptionalSample.class.getName() + " a 
" +
"where a.optionalPC != null) == id";
Object[] expectedResult2 = new Object[]{oidReferencedPC1};
// single String JDOQL
Query singleStringQuery2 = pm.newQuery(singleStringJDOQL2);
executeJDOQuery(ASSERTION_FAILED, singleStringQuery2, 
singleStringJDOQL2,
false, null, expectedResult2, true);


Kind regards,
Tilmann


On 22.09.2016 22:33, Michael Bouschen wrote:

Hi,

We will have our regular meeting Friday, September 23 at 9 AM Pacific Daylight 
Time (PDT) to discuss JDO TCK issues and status.

We use the new dial-in for audio and video. You need a Skype account to join.
https://join.skype.com/euV54RJwJBcf

Agenda:
1. JIRA JDO-756 "Enhance PK to avoid LongIdentity/StringIdentity dependencies" 
https://issues.apache.org/jira/browse/JDO-756
2. Spec changes for  JDO-751 "Support for Java8 Optional" 
https://issues.apache.org/jira/browse/JDO-751
3. JDO-735 "Make PersistenceManager and Query support AutoCloseable (JDK1.7+)" 
https://issues.apache.org/jira/browse/JDO-735
4. JDO-747 "Behavior of delete() with multiple concurrent Transactions" 
https://issues.apache.org/jira/browse/JDO-747
5. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
6. Other issues

Action Items from weeks past:
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[May 15 2015] AI Craig Spec change for roll back an active transaction when 
closing a persistence manager (JDO-735)
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael



Craig L Russell
Architect
craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!

JDO-751 "Support for Java8 Optional" with subqueries - request for feedback

2016-09-24 Thread Tilmann


Hi,

could I get some feedback?

I tried the following subquery:

"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +
"(select  max(a.id) from " + 
OptionalSample.class.getName() + " a " +

"where a.optionalPC != null) == id";

This returns '88' (an integer) instead of the object with id==88. Is 
this expected to return an integer?


Full code (can be used in SupportedOptionalMethods.java):
   String singleStringJDOQL2 =
"SELECT FROM " + OptionalSample.class.getName() + " 
WHERE " +
"(select  max(a.id) from " + 
OptionalSample.class.getName() + " a " +

"where a.optionalPC != null) == id";
Object[] expectedResult2 = new Object[]{oidReferencedPC1};
// single String JDOQL
Query singleStringQuery2 = pm.newQuery(singleStringJDOQL2);
executeJDOQuery(ASSERTION_FAILED, singleStringQuery2, 
singleStringJDOQL2,

false, null, expectedResult2, true);


Kind regards,
Tilmann


On 22.09.2016 22:33, Michael Bouschen wrote:

Hi,

We will have our regular meeting Friday, September 23 at 9 AM Pacific Daylight 
Time (PDT) to discuss JDO TCK issues and status.

We use the new dial-in for audio and video. You need a Skype account to join.
https://join.skype.com/euV54RJwJBcf

Agenda:
1. JIRA JDO-756 "Enhance PK to avoid LongIdentity/StringIdentity dependencies" 
https://issues.apache.org/jira/browse/JDO-756
2. Spec changes for  JDO-751 "Support for Java8 Optional" 
https://issues.apache.org/jira/browse/JDO-751
3. JDO-735 "Make PersistenceManager and Query support AutoCloseable (JDK1.7+)" 
https://issues.apache.org/jira/browse/JDO-735
4. JDO-747 "Behavior of delete() with multiple concurrent Transactions" 
https://issues.apache.org/jira/browse/JDO-747
5. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
6. Other issues

Action Items from weeks past:
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[May 15 2015] AI Craig Spec change for roll back an active transaction when 
closing a persistence manager (JDO-735)
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael

Re: Change to JDO specification with regard to jdoql null handling

2016-09-09 Thread Tilmann


+1

But maybe we could add some clarifications:

"... Comparison of fields with null return null [except when compared to 
'null']"


and for the operands:

!(null) = true (?)

Cheers,
Tilmann

On 08.09.2016 21:07, Michael Bouschen wrote:

Hi,

+1 changing the spec as proposed.

Regards Michael


We have discussed changing the JDO specification in a small but significant way 
and I’d like to get feedback on it.

The current specification:
Navigation through a null-valued field, which would throw NullPointerException, 
is treated as if the subexpression returned false. Similarly, a failed cast 
operation, which would throw ClassCastException, is treated as if the 
subexpression returned false. Other subexpressions or [other values for 
variables might still qualify the candidate instance for inclusion in the 
result set.]

Proposed specification:
Navigation through a null-valued field, which would throw NullPointerException, 
is treated as if the subexpression returned null. Similarly, a failed cast 
operation, which would throw ClassCastException, is treated as if the 
subexpression returned null. Comparison of fields with null return null. 
Arithmetic expressions with null parameters return null. Optional.get() may 
return null. Optional.isPresent() is treated as !=null.
Boolean expressions with null operands:
true & null -> null
false & null -> false
true | null -> true
false | null -> null

This change aligns JDO with SQL NULL semantics and makes reasoning about JDOQL 
expressions more rational.


Craig L Russell
c...@apache.org

Adding 'j...@apache.org' to lists.apache.org

2016-08-12 Thread Tilmann Zäschke


Hi,

I believe the 'j...@apache.org' list is missing from lists.apache.org . 
Could you please add it? I think it is meant to be public.


Cheers,
Tilmann (tilma...@apache.org)

JIRA 747

2016-07-08 Thread Tilmann Zäschke


Hi Andy,

(sorry for double posting, I sent this to an...@apache.org before)

I started looking into adapting datanucleus for JDO JIRA 747: 
https://issues.apache.org/jira/browse/JDO-747


Some time ago you offered to give some initial pointers, could you tell 
me where to start?


My first goal: Update datanuclues so that a PERSISTENT_NEW object 
transitions to PERSISTENT_CLEAN when they are refreshed _and_ if there 
is an object with the same ID in the database.


I tried to find the state transition checks and triggers. I first looked 
into datanucleus' Transaction.commit(), but it seems to forward 
everything to an implementation of XAResource.commit, probably either 
one of the LocalXAResource or the EmulatedXAResource classes. These 
forward the call to a 'Connection', but I can't immediately see which 
implementation is used.


Could you give me some pointers?

Thanks,
Tilmann

Re: EmbeddedPCMapping cannot be cast to PersistableMapping

2016-06-13 Thread Tilmann Zäschke


Hi,
I improved the TCK-test for Optional.

With the latest datanucleus (5.0.0-release-SNAPSHOT) there is are some 
problems remaining:


1) "SELECT FROM org.apache.jdo.tck.pc.query.OptionalSample WHERE 
!(optionalPC.optionalPC.isPresent())"


I think this should only return an object A if A references an object B 
where B does not reference anything else.
However, it also returns objects A where A do not reference anything 
else (reference is not present).



2) All the orElse() tests still fail. I fixed a number of errors in the 
tests, but I believe the tests are now correct.


I'll upload the latest version in a minute.

Best regards,
Tilmann


On 04-Jun-16 15:30, Andy Jefferson wrote:

Hi,


a) SQLSyntaxErrorException : Encountered "NOT" at line 1, column 185

Just seen your SQL generated. "WHERE NOT NOT (A0.OPTIONAL_PC IS NULL)"
That is valid on some RDBMS but maybe Derby is throwing its toys out of the 
pram due to it? Current DN code will put brackets in there. i.e NOT (NOT (...))



b) optionalPC.get().id

Released DN code only supports "optionalPC.get()" and not the access of fields 
of the dereferenced object (i.e it didn't do a join to the related table holding the 
object). Current DN code does however support that.
As I mentioned previously, if having problems use nightly builds.



c) Optional.orElse is currently not supported

Yes it is, and has been since DataNucleus v5.0.0-m4. You must be using an old 
version.

Regarding a use-case for orElse, the test I use is putting the orElse in the 
SELECT clause

Query q = pm.newQuery("SELECT id, stringField.orElse('NotPresent') FROM 
mydomain.MyClass");

so I get back the value that is stored when it is set, or some other value if 
not set (much like could be achieved with a CASE statement with other 
datatypes).



Regards

Re: EmbeddedPCMapping cannot be cast to PersistableMapping

2016-05-31 Thread Tilmann Zäschke


Hi,


More likely the problem is down to having a field as Optional


The test doesn't actually have Optional, but it does have:

Optional optionalAny;
Optional optionalNoGenerics;

I suppose these would not be allowed either (because they are mostly 
equivalent to Optional)?


Regards,
Tilmann

On 31-May-16 11:53, Andy Jefferson wrote:

Hi,

thanks. Indeed it seems that the error is triggered by declaring a field
as 'Optional'.

That I doubt, due to established tests
https://github.com/datanucleus/tests/blob/master/jdo/general/src/test/org/datanucleus/tests/types/OptionalTest.java


More likely the problem is down to having a field as Optional, which is 
a minority interest use-case IMHO (which can often be symptomatic of a problem in a 
model, with lack of use of inheritance etc). Perhaps try nightly builds of jars if 
having problems.


Next step is likely to update the implementation.

DataNucleus has supported Optional since 5.0.0-m1, and tested on Optional<{basic}>, 
Optional (see link). It hasn't been tested on Optional where Object 
refers to potentially multiple types of PC.



Regards

Re: EmbeddedPCMapping cannot be cast to PersistableMapping

2016-05-31 Thread Tilmann Zäschke


Hi Craig,
thanks. Indeed it seems that the error is triggered by declaring a field 
as 'Optional'.
I thought I had seen an update note that 'Optional' would be supported 
by the latest milestone of DataNucleus, but I can't find it anymore.


I uploaded the patch to JIRA.
Next step is likely to update the implementation.

Cheers,
Tilmann

On 30-May-16 21:31, Craig Russell wrote:

Hi Tilmann,


On May 30, 2016, at 6:10 AM, Tilmann Zäschke <zaesc...@gmx.de> wrote:

Dear all,

I'm trying to implement the schema for the new Optional test, but I keep 
running into a ClassCastException:

javax.jdo.JDOFatalInternalException: Failed to generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.OptionalMapping, exception : Failed to 
generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.ObjectMapping, exception : 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be cast to 
org.datanucleus.store.rdbms.mapping.java.PersistableMapping
java.lang.ClassCastException: 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be cast to 
org.datanucleus.store.rdbms.mapping.java.PersistableMapping
at 
org.datanucleus.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:253)
at 
org.datanucleus.store.rdbms.mapping.java.ReferenceMapping.createPerImplementationColumnsForReferenceField(ReferenceMapping.java:487)


I'm not mentioning 'embedded' anywhere, so I'm not sure where this assumption 
of 'embedding' comes from.

I think that Optional itself is treated as embedded. I’d investigate which field is causing 
the problem by trying, one at a time, Optional, Optional, 
etc. and see whether any of these is ok.

But is Optional even claimed to be supported by datanucleus? I haven’t seen any 
mail on the subject…

Craig



I do have Fields of type 'Object', but other tests also don't seem to require 
embedded=false or similar to handle field of type Object that reference PCs.

I'm also not even sure (or how I can find out) which of my mapping files are 
wrong. The error is the same for application-identity and datastore-identity. 
It occurs wile calling makePersistent().
I'm using the latest 'trunk' of the JDO TCK.

I also also consistently get the following error, but it seems to be a 
different issue:

Error copying implementation log file: Source 
'C:\Users\ztilmann\Desktop\projects\workspace-jdo\JDO\tck\datanucleus.txt' does 
not exist


Could anyone have a look and tell me what I'm doing wrong? I can also provide 
if the mistake is not obvious. Code snippets are below.

Cheers,
Tilmann


Code snippet (error occurs in last line in makePersistent):

@Override
protected void localSetUp() {
addTearDownClass(OptionalSample.class);
insertOptionalSample(getPM());
}

private void insertOptionalSample(PersistenceManager pm) {
Transaction tx = pm.currentTransaction();
try {
tx.begin();

//create a dummy object as target
OptionalSample dummyPC = new OptionalSample();
dummyPC.setId(DUMMY_ID);
pm.makePersistent(dummyPC);
...
}
}



Here are the schemas:

public class OptionalSample {
long id;

Optional optionalPC;
Optional optionalAny;
@SuppressWarnings("rawtypes")
Optional optionalNoGenerics;
Object any;

Optional optionalDate;
Optional optionalInteger;
Optional optionalString;

...
}


package.jdo
==


  
  
  
  
  
  
  
  
  
  
  



package-standard.orm:
=

   
  
  


  
  

  
  

  
  

  
  

  
  

  
  

  



schema.sql
==

CREATE TABLE OptionalSample (
ID INTEGER NOT NULL,
OPTIONAL_PC INTEGER REFERENCES SIMPLE_CLASS,
OPTIONAL_DATE DATE,
OPTIONAL_LONG BIGINT,
OPTIONAL_STRING VARCHAR(255),
OPTIONAL_ANY INTEGER REFERENCES SIMPLE_CLASS,
OPTIONAL_NO_GENERICS INTEGER REFERENCES SIMPLE_CLASS,
OBJECT_ANY INTEGER REFERENCES SIMPLE_CLASS,
CONSTRAINT OPTIONALSAMPLE_PK PRIMARY KEY (ID)
);


Full exception:
=

1) 
testParameterOptionalWithEmptyFields(org.apache.jdo.tck.query.jdoql.methods.SupportedOptionalMethods)javax.jdo.JDOFatalInternalException:
 Failed to generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.OptionalMapping, exception : Failed to 
generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.ObjectMapping, exception : 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be cast to 
org.datanucleus.store.rdbms.mapping.java.PersistableMapping
java.lang.ClassCastException: 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be cast to 
org.datanucleus.store.rdbms.mapping.java.Pe

EmbeddedPCMapping cannot be cast to PersistableMapping

2016-05-30 Thread Tilmann Zäschke


Dear all,

I'm trying to implement the schema for the new Optional test, but I keep 
running into a ClassCastException:


javax.jdo.JDOFatalInternalException: Failed to generate new Mapping of 
type org.datanucleus.store.rdbms.mapping.java.OptionalMapping, exception 
: Failed to generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.ObjectMapping, exception : 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be 
cast to org.datanucleus.store.rdbms.mapping.java.PersistableMapping
java.lang.ClassCastException: 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be 
cast to org.datanucleus.store.rdbms.mapping.java.PersistableMapping
at 
org.datanucleus.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:253)
at 
org.datanucleus.store.rdbms.mapping.java.ReferenceMapping.createPerImplementationColumnsForReferenceField(ReferenceMapping.java:487)



I'm not mentioning 'embedded' anywhere, so I'm not sure where this 
assumption of 'embedding' comes from. I do have Fields of type 'Object', 
but other tests also don't seem to require embedded=false or similar to 
handle field of type Object that reference PCs.


I'm also not even sure (or how I can find out) which of my mapping files 
are wrong. The error is the same for application-identity and 
datastore-identity. It occurs wile calling makePersistent().

I'm using the latest 'trunk' of the JDO TCK.

I also also consistently get the following error, but it seems to be a 
different issue:
>> Error copying implementation log file: Source 
'C:\Users\ztilmann\Desktop\projects\workspace-jdo\JDO\tck\datanucleus.txt' 
does not exist



Could anyone have a look and tell me what I'm doing wrong? I can also 
provide if the mistake is not obvious. Code snippets are below.


Cheers,
Tilmann


Code snippet (error occurs in last line in makePersistent):

@Override
protected void localSetUp() {
addTearDownClass(OptionalSample.class);
insertOptionalSample(getPM());
}

private void insertOptionalSample(PersistenceManager pm) {
Transaction tx = pm.currentTransaction();
try {
tx.begin();

//create a dummy object as target
OptionalSample dummyPC = new OptionalSample();
dummyPC.setId(DUMMY_ID);
pm.makePersistent(dummyPC);
...
}
}



Here are the schemas:

public class OptionalSample {
long id;

Optional optionalPC;
Optional optionalAny;
@SuppressWarnings("rawtypes")
Optional optionalNoGenerics;
Object any;

Optional optionalDate;
Optional optionalInteger;
Optional optionalString;

...
}


package.jdo
==


  
  
  
  
  
  embedded="false"

field-type="org.apache.jdo.tck.pc.query.OptionalSample">
  
  persistence-modifier="persistent" embedded="false"

field-type="org.apache.jdo.tck.pc.query.OptionalSample">
  
  
  



package-standard.orm:
=

   
  
  


  
  

  
  

  
  

  
  

  
  

  
  

  



schema.sql
==

CREATE TABLE OptionalSample (
ID INTEGER NOT NULL,
OPTIONAL_PC INTEGER REFERENCES SIMPLE_CLASS,
OPTIONAL_DATE DATE,
OPTIONAL_LONG BIGINT,
OPTIONAL_STRING VARCHAR(255),
OPTIONAL_ANY INTEGER REFERENCES SIMPLE_CLASS,
OPTIONAL_NO_GENERICS INTEGER REFERENCES SIMPLE_CLASS,
OBJECT_ANY INTEGER REFERENCES SIMPLE_CLASS,
CONSTRAINT OPTIONALSAMPLE_PK PRIMARY KEY (ID)
);


Full exception:
=

1) 
testParameterOptionalWithEmptyFields(org.apache.jdo.tck.query.jdoql.methods.SupportedOptionalMethods)javax.jdo.JDOFatalInternalException: 
Failed to generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.OptionalMapping, exception : 
Failed to generate new Mapping of type 
org.datanucleus.store.rdbms.mapping.java.ObjectMapping, exception : 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be 
cast to org.datanucleus.store.rdbms.mapping.java.PersistableMapping
java.lang.ClassCastException: 
org.datanucleus.store.rdbms.mapping.java.EmbeddedPCMapping cannot be 
cast to org.datanucleus.store.rdbms.mapping.java.PersistableMapping
at 
org.datanucleus.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:253)
at 
org.datanucleus.store.rdbms.mapping.java.ReferenceMapping.createPerImplementationColumnsForReferenceField(ReferenceMapping.java:487)
at 
org.datanucleus.store.rdbms.mapping.java.ReferenceMapping.prepareDatastoreMapping(ReferenceMapping.java:229)
at 
org.datanucleus.store.rdbms.mapping.java.ReferenceMapping.initialize(ReferenceMapping.java:104)
at 
org.datanucleus.store.r

Re: A new general method to update object databases / Should it be included in Java Data Objects, JDO ?

2016-05-27 Thread Tilmann

Hi Heikki,

I found something in the old ODMG 3.0 standard:

6.3.1.2 Object Deletion
In the Smalltalk binding, as in Smalltalk, there is no notion of
explicit deletion of objects. An object is removed from the database
during garbage collection if that object is not referenced by any other
persistent object. The delete() operation from interface 'Object' is not
supported.

-> So it seems that some kind of Garbage Collection was envisaged by the
standard, if only for Smalltalk. However, as I said before, I'm not
aware that this was ever implemented outside the SmallTalk community,
and I don't know SmallTalk well enough to tell how much GC might differ
from Java GC.

So while the term 'GC in databases' doesn't seem to be entirely new,
your approach may bring new ideas to the table, including a solid
theoretical foundation. Maybe it would even explain why it hasn't been
implemented in any major DBMS.

For example, POET Navajo supports ODMG 3 but apparently chose _not_ to
support GC (first page, last paragraph):
http://www.odbms.org/wp-content/uploads/2013/11/038.01-Jordan-An-Object-Database-for-Embedded-Environments-April-2000.pdf

Regards,
Tilmann

On 20.05.2016 19:55, Hei Virk wrote:

Hi everybody:

I will comment later more.

-I am just going to keep a presentation about the topic in my university
here in Finland for theorists and I am making those slides at a moment..

One social observation:
In my understanding the situation has been that people (me too) have not
been understood that that a modified object structure can always be
returned back into the database in a deterministic and meaningful way. - I
mean that the well defined result exists always for an operation. This is
because the modifications in Run-Time memory can be so arbitrary.

For this reason no one has been able to think the problem? Therefore the
method can not have been in any db standard either.

Regards,
Heikki

On Fri, May 20, 2016 at 7:49 PM, Tilmann Zäschke <zaesc...@gmx.de> wrote:

Hello Hei,
sorry, I posted my answer first only to the dev list, I'm not sure you are
on it.
So here it is again, with some updates:

Hi,

I haven't read the whole post in detail, but I understand the main idea is
garbage collection in databases. This reminds me of similar concepts in
osome object databases, such as GemStone/Smalltalk (
https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-ReleaseNotes-3.3/GS64-ReleaseNotes-3.3.htm).
However, I'm not aware of any major Java-ODBMS that supports it.

Some comments:

- As Andy describes, it could be supported via a property of the PM.
However, there may be scenarios when 'embed' and 'makePersistent' are
regularily use in the same transaction, so if the feature would be widely
used, it may make sense to have a dedicated 'embed' method.

- as far as I am aware, the JVM has moved away from reference counting.
The situation in an DBMS may be different to an in-memory JVM, but if an
ODBMS implements GC, it may be worth checking out other garbage collection
techniques. One problem are reference cycles, I haven't read the full
blogpost how this is solved.

- It seams that enabling garbage collection via reference counting will
have quite some impact on performance, because objects get bigger (little
impact) and because it requires updating of additional objects in the
database to update the reference counters (the counters also need updating
when _adding_ references). I would therefore argue that support for garbage
collection should be determined at database creation time, or as a flag
when defining database schema. This would allow avoiding the GC overhead
when GC is not required.

- We would need to be able to identify root objects which should not be
garbage collected. This could also be done via a flag on the schema, i.e.
every object of a class that has no reference counters is automatically a
root object.

Cheers,
Tilmann

On 13.05.2016 15:49, Andy Jefferson wrote:

Hi,

-I have invented a new declarative method to update object databases and

I
would like to introduce that method you.

My question is:
Should the functionality of this method included in some future
versions of
JDO (and perhaps some other definitions/systems under Apache)?
Also I am interested about your comments/critique on the method.

The name of the method is "embed" and it resembles the command
pm.makePersistent(s);
used in JDO-enabled applications. The embed method is called in
equivalent
way,
db.embed(s);
but it has a larger functionality than the current makePersistent
method.

My opinion/comments, others may have other thoughts :

For something to be part of JDO, it needs to be widely applicable across
other datastores, not just for one "type" of datastore. If it is only
implementable on 1 type of datastore then standardising it would be
"premature"; that isn't to say that it isn't applicable to others.

From what I read of your method i

Re: A new general method to update object databases / Should it be included in Java Data Objects, JDO ?

2016-05-20 Thread Tilmann Zäschke

Hello Hei,
sorry, I posted my answer first only to the dev list, I'm not sure you
are on it.

So here it is again, with some updates:

Hi,

I haven't read the whole post in detail, but I understand the main idea
is garbage collection in databases. This reminds me of similar concepts
in osome object databases, such as GemStone/Smalltalk
(https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-ReleaseNotes-3.3/GS64-ReleaseNotes-3.3.htm).
However, I'm not aware of any major Java-ODBMS that supports it.

Some comments:

- As Andy describes, it could be supported via a property of the PM.
However, there may be scenarios when 'embed' and 'makePersistent' are
regularily use in the same transaction, so if the feature would be
widely used, it may make sense to have a dedicated 'embed' method.

- as far as I am aware, the JVM has moved away from reference counting.
The situation in an DBMS may be different to an in-memory JVM, but if an
ODBMS implements GC, it may be worth checking out other garbage
collection techniques. One problem are reference cycles, I haven't read
the full blogpost how this is solved.

- It seams that enabling garbage collection via reference counting will
have quite some impact on performance, because objects get bigger
(little impact) and because it requires updating of additional objects
in the database to update the reference counters (the counters also need
updating when _adding_ references). I would therefore argue that support
for garbage collection should be determined at database creation time,
or as a flag when defining database schema. This would allow avoiding
the GC overhead when GC is not required.

- We would need to be able to identify root objects which should not be
garbage collected. This could also be done via a flag on the schema,
i.e. every object of a class that has no reference counters is
automatically a root object.

Cheers,
Tilmann

On 13.05.2016 15:49, Andy Jefferson wrote:

Hi,

-I have invented a new declarative method to update object databases
and I

would like to introduce that method you.

My question is:
Should the functionality of this method included in some future
versions of

JDO (and perhaps some other definitions/systems under Apache)?
Also I am interested about your comments/critique on the method.

The name of the method is "embed" and it resembles the command
pm.makePersistent(s);
used in JDO-enabled applications. The embed method is called in
equivalent

way,
db.embed(s);
but it has a larger functionality than the current makePersistent
method.

My opinion/comments, others may have other thoughts :

For something to be part of JDO, it needs to be widely applicable
across other datastores, not just for one "type" of datastore. If it
is only implementable on 1 type of datastore then standardising it
would be "premature"; that isn't to say that it isn't applicable to
others.

From what I read of your method it is basically a makePersistent
(attach) but with "deleteOrphans" enabled; i.e it addresses the
object graph defined by the input object, and additionally deletes
orphaned objects. Firstly it is entirely reasonable to be able to do
that right now in terms of API (**assuming the JDO implementation
provided the internals**) since the user can call pm.makePersistent
and can have set properties on the PersistenceManager just before
that call (pm.setProperty(...), so can set some "deleteOrphans"
flag). From that I can conclude that I don't think there would be any
change to the API needed to provide your mode of operation.

Deleting orphans may vary dependent on the precise relation, hence
why JDO allows metadata on each field, so some orphans can be deleted
and others not.

Clearly a JDO implementation would need to provide a "deleteOrphans"
mode internally to support this.

Detail of how your method works in an object database, whilst
interesting, is not of relevance to the JDO spec question, since the
spec doesn't define HOW an implementation implements features

Regards

Re: A new general method to update object databases / Should it be included in Java Data Objects, JDO ?

2016-05-14 Thread Tilmann

Hi,

As far as I can tell garbage collection is an established concept in
object databases, I think the oldest one that support it is
GemStone/Smalltalk
(https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-ReleaseNotes-3.3/GS64-ReleaseNotes-3.3.htm).
However, I'm not aware of any major Java-ODBMS that supports it.

Some comments:

- As Andy describes, it could be supported via a property of the PM.
However, there may be scenarios when 'embed' and 'makePersistent' are
regularily use in the same transaction, so if the feature would be
widely used, it may make sense to have a dedicated 'embed' method.

- It seams that enabling garbage collection via reference counting will
have quite some impact on performance, because objects get bigger
(little impact) and because it requires updating of additional objects
in the database to update the reference counters (the counters also need
updating when _adding_ references). I would therefore argue that support
for garbage collection should be determined at database creation time,
or as a flag when defining database schema. This would allow avoiding
the GC overhead when GC is not required.

Cheers,

Tilmann

On 13.05.2016 15:49, Andy Jefferson wrote:

Hi,

-I have invented a new declarative method to update object databases and I
would like to introduce that method you.

My question is:
Should the functionality of this method included in some future versions of
JDO (and perhaps some other definitions/systems under Apache)?
Also I am interested about your comments/critique on the method.

The name of the method is "embed" and it resembles the command
pm.makePersistent(s);
used in JDO-enabled applications. The embed method is called in equivalent
way,
db.embed(s);
but it has a larger functionality than the current makePersistent method.

My opinion/comments, others may have other thoughts :

For something to be part of JDO, it needs to be widely applicable across other datastores, not just
for one "type" of datastore. If it is only implementable on 1 type of datastore then
standardising it would be "premature"; that isn't to say that it isn't applicable to
others.

From what I read of your method it is basically a makePersistent (attach) but with
"deleteOrphans" enabled; i.e it addresses the object graph defined by the input object,
and additionally deletes orphaned objects. Firstly it is entirely reasonable to be able to do that
right now in terms of API (**assuming the JDO implementation provided the internals**) since the
user can call pm.makePersistent and can have set properties on the PersistenceManager just before
that call (pm.setProperty(...), so can set some "deleteOrphans" flag). From that I can
conclude that I don't think there would be any change to the API needed to provide your mode of
operation.

Deleting orphans may vary dependent on the precise relation, hence why JDO
allows metadata on each field, so some orphans can be deleted and others not.

Clearly a JDO implementation would need to provide a "deleteOrphans" mode
internally to support this.

Detail of how your method works in an object database, whilst interesting, is
not of relevance to the JDO spec question, since the spec doesn't define HOW an
implementation implements features

Regards

ViewVC problem

2016-01-29 Thread Tilmann


Hi,

I realised that using Chrome instead of Firefox works, even though it 
hangs ~30 seconds before showing anything.
Also, the original issue (https://issues.apache.org/jira/browse/JDO-748) 
explains that the problem with ViewCVS occurred even with an http-link, 
because Firefox automatically changed that to https if the server 
supports it.

I suppose changing the link to http would probably not help.

My guess is that the issue may have to do with the security-certificates 
that Firefox is using, or with the certificate authorities it is trying 
to contact when browsing from Switzerland.


Considering that the problem appears to be limited to Switzerland and 
Firefox browsers, and that there is a good chance that changing to https 
won't help, I won't raise in issue just yet.


Let me know if you think the issue should still be raised. In that case 
it may make sense to vote on my commit rights, as suggested by Craig, so 
I could fix and verify the solution myself.


Cheers,
Tilmann

===
Tilmann Zaeschke
http://www.zoodb.org

ViewVC problem

2016-01-29 Thread Tilmann


Hi,

I realised that using Chrome instead of Firefox works, even though it 
hangs ~30 seconds before showing anything.
Also, the original issue (https://issues.apache.org/jira/browse/JDO-748) 
explains that the problem with ViewCVS occurred even with an http-link, 
because Firefox automatically changed that to https if the server 
supports it.

I suppose changing the link to http would probably not help.

My guess is that the issue may have to do with the security-certificates 
that Firefox is using, or with the certificate authorities it is trying 
to contact when browsing from Switzerland.


Considering that the problem appears to be limited to Switzerland and 
Firefox browsers, and that there is a good chance that changing to https 
won't help, I won't raise in issue just yet.


Let me know if you think the issue should still be raised. In that case 
it may make sense to vote on my commit rights, as suggested by Craig, so 
I could fix and verify the solution myself.


Cheers,
Tilmann

===
Tilmann Zaeschke
http://www.zoodb.org

99 matches

Mail list logo