Modified: websites/production/db/content/jdo/releases/release-3.0.1.html ============================================================================== --- websites/production/db/content/jdo/releases/release-3.0.1.html (original) +++ websites/production/db/content/jdo/releases/release-3.0.1.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,147 +210,147 @@
- - -

JDO 3.0.1 Distributions

-

- Use the links below to download Apache JDO from one of our mirrors. - For more information about the projects see Downloads. - For information on running the TCK, see TCK. -

-

- It is good practice to verify the integrity - of the distribution files. -

-

- You are currently using [preferred]. - If you encounter a problem with this mirror, then please select another. - If all mirrors are failing, there are backup mirrors at the end of the list. - See status of mirrors. -

-
- Other mirrors: - -
-
- - -

API

-

- The api project contains source to build jdo-api.jar, - which defines the JDO API. - The jar file is the only artifact needed for users who wish to compile - their programs using the JDO API. - It can be downloaded automatically by maven and placed into the local - maven repository if you include the - proper dependency in your maven project definition. - Use groupId javax.jdo, artifactId jdo-api, version 3.0 - and define your remote repository as - http://www.ibiblio.org/maven. - Alternatively, it can be downloaded manually and put into a location - of your choice. -

-

- jdo-api-3.0.1.jar - [PGP] - [MD5] -

-

- jdo-api-3.0.1.pom - [PGP] - [MD5] -

-

- jdo-api-3.0.1-src.zip - [PGP] - [MD5] -

-

- jdo-api-3.0.1-src.tar.gz - [PGP] - [MD5] -

-
- -

TCK

-

- This is a download for all implementors of JDO, and for those who want to check - how well an implementation is compliant with the JDO specification. - The tck2 project contains the JDO 2 Technology Compatibility Kit. - The source distribution is the only artifact needed to be downloaded - by the user. The dependencies (including the model20 jar, - util20 jar, enhancer20 jar, api2 jar, and JPOX) - are automatically downloaded by maven as needed to run the TCK. - -

-

- jdo-tck-3.0.1-src.zip - [PGP] - [MD5] -

-

- jdo-tck-3.0.1-src.tar.gz - [PGP] - [MD5] -

-
- -
- -

Verifying Releases

- -

It is essential that you verify the integrity of the downloaded -files using the PGP signature and/or the MD5 checksum. The -checksum is not as strong an indicator as the PGP signature is.

-

The PGP signatures can be verified using PGP or GPG. -First download the KEYS -as well as the asc signature file for the particular -distribution. -Make sure you get these files from the -main distribution -directory, rather than from a mirror. Then verify the signatures using -

-

-% pgpk -a KEYS
-% pgpv release_name.tar.gz.asc
-
-or
- -% pgp -ka KEYS
-% pgp release_name.tar.gz.asc
-
-or
- -% gpg --import KEYS
-% gpg --verify release_name.tar.gz.asc -

-

Alternatively, you can verify the checksums on the files. Unix -programs called md5/sha1 or -md5sum/sha1sum are included in many unix -distributions. *sum is also available as part of -GNU Textutils. -Windows users can get binary md5 programs from http://www.fourmilab.ch/md5 and -hhttp://www.pc-tools.net/win32/freeware/console. -Windows SlavaSoft fsum supports MD5 and -SHA1.

-

We highly recommend verifying the PGP signature, though.

-
- + + +

JDO 3.0.1 Distributions

+

+ Use the links below to download Apache JDO from one of our mirrors. + For more information about the projects see Downloads. + For information on running the TCK, see TCK. +

+

+ It is good practice to verify the integrity + of the distribution files. +

+

+ You are currently using [preferred]. + If you encounter a problem with this mirror, then please select another. + If all mirrors are failing, there are backup mirrors at the end of the list. + See status of mirrors. +

+
+ Other mirrors: + +
+
+ + +

API

+

+ The api project contains source to build jdo-api.jar, + which defines the JDO API. + The jar file is the only artifact needed for users who wish to compile + their programs using the JDO API. + It can be downloaded automatically by maven and placed into the local + maven repository if you include the + proper dependency in your maven project definition. + Use groupId javax.jdo, artifactId jdo-api, version 3.0 + and define your remote repository as + http://www.ibiblio.org/maven. + Alternatively, it can be downloaded manually and put into a location + of your choice. +

+

+ jdo-api-3.0.1.jar + [PGP] + [MD5] +

+

+ jdo-api-3.0.1.pom + [PGP] + [MD5] +

+

+ jdo-api-3.0.1-src.zip + [PGP] + [MD5] +

+

+ jdo-api-3.0.1-src.tar.gz + [PGP] + [MD5] +

+
+ +

TCK

+

+ This is a download for all implementors of JDO, and for those who want to check + how well an implementation is compliant with the JDO specification. + The tck2 project contains the JDO 2 Technology Compatibility Kit. + The source distribution is the only artifact needed to be downloaded + by the user. The dependencies (including the model20 jar, + util20 jar, enhancer20 jar, api2 jar, and JPOX) + are automatically downloaded by maven as needed to run the TCK. + +

+

+ jdo-tck-3.0.1-src.zip + [PGP] + [MD5] +

+

+ jdo-tck-3.0.1-src.tar.gz + [PGP] + [MD5] +

+
+ +
+ +

Verifying Releases

+ +

It is essential that you verify the integrity of the downloaded +files using the PGP signature and/or the MD5 checksum. The +checksum is not as strong an indicator as the PGP signature is.

+

The PGP signatures can be verified using PGP or GPG. +First download the KEYS +as well as the asc signature file for the particular +distribution. +Make sure you get these files from the +main distribution +directory, rather than from a mirror. Then verify the signatures using +

+

+% pgpk -a KEYS
+% pgpv release_name.tar.gz.asc
+
+or
+ +% pgp -ka KEYS
+% pgp release_name.tar.gz.asc
+
+or
+ +% gpg --import KEYS
+% gpg --verify release_name.tar.gz.asc +

+

Alternatively, you can verify the checksums on the files. Unix +programs called md5/sha1 or +md5sum/sha1sum are included in many unix +distributions. *sum is also available as part of +GNU Textutils. +Windows users can get binary md5 programs from http://www.fourmilab.ch/md5 and +hhttp://www.pc-tools.net/win32/freeware/console. +Windows SlavaSoft fsum supports MD5 and +SHA1.

+

We highly recommend verifying the PGP signature, though.

+
+
Modified: websites/production/db/content/jdo/releases/release-3.0.html ============================================================================== --- websites/production/db/content/jdo/releases/release-3.0.html (original) +++ websites/production/db/content/jdo/releases/release-3.0.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,147 +210,147 @@
- - -

JDO 3.0 Distributions

-

- Use the links below to download Apache JDO from one of our mirrors. - For more information about the projects see Downloads. - For information on running the TCK, see TCK. -

-

- It is good practice to verify the integrity - of the distribution files. -

-

- You are currently using [preferred]. - If you encounter a problem with this mirror, then please select another. - If all mirrors are failing, there are backup mirrors at the end of the list. - See status of mirrors. -

-
- Other mirrors: - -
-
- -

Release Notes

-

- - View release notes for JDO 3.0 -

-
-

API

-

- The api project contains source to build jdo-api.jar, - which defines the JDO API. - The jar file is the only artifact needed for users who wish to compile - their programs using the JDO API. - It can be downloaded automatically by maven and placed into the local - maven repository if you include the - proper dependency in your maven project definition. - Use groupId javax.jdo, artifactId jdo-api, version 3.0 - and define your remote repository as - http://www.ibiblio.org/maven. - Alternatively, it can be downloaded manually and put into a location - of your choice. -

-

- jdo-api-3.0.jar - [PGP] - [MD5] -

-

- jdo-api-3.0.pom - [PGP] - [MD5] -

-

- jdo-api-3.0-src.zip - [PGP] - [MD5] -

-

- jdo-api-3.0-src.tar.gz - [PGP] - [MD5] -

-
- -

TCK

-

- This is a download for all implementors of JDO, and for those who want to check - how well an implementation is compliant with the JDO specification. - The tck2 project contains the JDO 2 Technology Compatibility Kit. - The source distribution is the only artifact needed to be downloaded - by the user. The dependencies (including the model20 jar, - util20 jar, enhancer20 jar, api2 jar, and JPOX) - are automatically downloaded by maven as needed to run the TCK. - -

-

- jdo-tck-3.0-src.zip - [PGP] - [MD5] -

-

- jdo-tck-3.0-src.tar.gz - [PGP] - [MD5] -

-
- -
- -

Verifying Releases

- -

It is essential that you verify the integrity of the downloaded -files using the PGP signature and/or the MD5 checksum. The -checksum is not as strong an indicator as the PGP signature is.

-

The PGP signatures can be verified using PGP or GPG. -First download the KEYS -as well as the asc signature file for the particular -distribution. -Make sure you get these files from the -main distribution -directory, rather than from a mirror. Then verify the signatures using -

-

-% pgpk -a KEYS
-% pgpv release_name.tar.gz.asc
-
-or
- -% pgp -ka KEYS
-% pgp release_name.tar.gz.asc
-
-or
- -% gpg --import KEYS
-% gpg --verify release_name.tar.gz.asc -

-

Alternatively, you can verify the checksums on the files. Unix -programs called md5/sha1 or -md5sum/sha1sum are included in many unix -distributions. *sum is also available as part of -GNU Textutils. -Windows users can get binary md5 programs from http://www.fourmilab.ch/md5 and -hhttp://www.pc-tools.net/win32/freeware/console. -Windows SlavaSoft fsum supports MD5 and -SHA1.

-

We highly recommend verifying the PGP signature, though.

-
- + + +

JDO 3.0 Distributions

+

+ Use the links below to download Apache JDO from one of our mirrors. + For more information about the projects see Downloads. + For information on running the TCK, see TCK. +

+

+ It is good practice to verify the integrity + of the distribution files. +

+

+ You are currently using [preferred]. + If you encounter a problem with this mirror, then please select another. + If all mirrors are failing, there are backup mirrors at the end of the list. + See status of mirrors. +

+
+ Other mirrors: + +
+
+ +

Release Notes

+

+ + View release notes for JDO 3.0 +

+
+

API

+

+ The api project contains source to build jdo-api.jar, + which defines the JDO API. + The jar file is the only artifact needed for users who wish to compile + their programs using the JDO API. + It can be downloaded automatically by maven and placed into the local + maven repository if you include the + proper dependency in your maven project definition. + Use groupId javax.jdo, artifactId jdo-api, version 3.0 + and define your remote repository as + http://www.ibiblio.org/maven. + Alternatively, it can be downloaded manually and put into a location + of your choice. +

+

+ jdo-api-3.0.jar + [PGP] + [MD5] +

+

+ jdo-api-3.0.pom + [PGP] + [MD5] +

+

+ jdo-api-3.0-src.zip + [PGP] + [MD5] +

+

+ jdo-api-3.0-src.tar.gz + [PGP] + [MD5] +

+
+ +

TCK

+

+ This is a download for all implementors of JDO, and for those who want to check + how well an implementation is compliant with the JDO specification. + The tck2 project contains the JDO 2 Technology Compatibility Kit. + The source distribution is the only artifact needed to be downloaded + by the user. The dependencies (including the model20 jar, + util20 jar, enhancer20 jar, api2 jar, and JPOX) + are automatically downloaded by maven as needed to run the TCK. + +

+

+ jdo-tck-3.0-src.zip + [PGP] + [MD5] +

+

+ jdo-tck-3.0-src.tar.gz + [PGP] + [MD5] +

+
+ +
+ +

Verifying Releases

+ +

It is essential that you verify the integrity of the downloaded +files using the PGP signature and/or the MD5 checksum. The +checksum is not as strong an indicator as the PGP signature is.

+

The PGP signatures can be verified using PGP or GPG. +First download the KEYS +as well as the asc signature file for the particular +distribution. +Make sure you get these files from the +main distribution +directory, rather than from a mirror. Then verify the signatures using +

+

+% pgpk -a KEYS
+% pgpv release_name.tar.gz.asc
+
+or
+ +% pgp -ka KEYS
+% pgp release_name.tar.gz.asc
+
+or
+ +% gpg --import KEYS
+% gpg --verify release_name.tar.gz.asc +

+

Alternatively, you can verify the checksums on the files. Unix +programs called md5/sha1 or +md5sum/sha1sum are included in many unix +distributions. *sum is also available as part of +GNU Textutils. +Windows users can get binary md5 programs from http://www.fourmilab.ch/md5 and +hhttp://www.pc-tools.net/win32/freeware/console. +Windows SlavaSoft fsum supports MD5 and +SHA1.

+

We highly recommend verifying the PGP signature, though.

+
+
Modified: websites/production/db/content/jdo/roadmap.html ============================================================================== --- websites/production/db/content/jdo/roadmap.html (original) +++ websites/production/db/content/jdo/roadmap.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,36 +210,36 @@
- - - -

Roadmap and TODO

- -

- The Apache JDO project has maintenance releases as part of its development cycle. - See JIRA for details of the planned and completed work. -

- -

- Submit an Idea -

- -
- - + + + +

Roadmap and TODO

+ +

+ The Apache JDO project has maintenance releases as part of its development cycle. + See JIRA for details of the planned and completed work. +

+ +

+ Submit an Idea +

+ +
+ +
Modified: websites/production/db/content/jdo/specifications.html ============================================================================== --- websites/production/db/content/jdo/specifications.html (original) +++ websites/production/db/content/jdo/specifications.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,45 +210,45 @@
- - - -

JDO Draft Specifications

-

- The following specifications for JDO are snapshots of the current Maintenance - Release specification under development. The specification has not been released. - Additions and changes are underway. Send comments to - jdo-experts-ext@sun.com. -

-
    -
  • None at this time
  • -
-
- + + + +

JDO Draft Specifications

+

+ The following specifications for JDO are snapshots of the current Maintenance + Release specification under development. The specification has not been released. + Additions and changes are underway. Send comments to + jdo-experts-ext@sun.com. +

+
    +
  • None at this time
  • +
+
+
Modified: websites/production/db/content/jdo/state_transition.html ============================================================================== --- websites/production/db/content/jdo/state_transition.html (original) +++ websites/production/db/content/jdo/state_transition.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -11,7 +11,7 @@ @import url("./css/site.css"); - + @@ -209,183 +209,183 @@
- - -

JDO State Transition

-

- JDO manages the lifecycle of an object, from creation (Transient) through to persistence in the datastore (Hollow, Persistent Clean) and all of the various states between these. The transition between these states are achieved by using methods on the Persistence Manager such as makePersistent(), makeTransient(), deletePersistent(), and by commiting the changes made by these operations, or by rolling them back. -

-

- The various lifecycle states supported by JDO are shown below. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameDescription
TransientAny object created by the developer that do are not persisted. These don't have a JDO identity.
Persistent NewAny object that is newly persisted in the current transaction. A JDO identity has been assigned to these objects.
Persistent DirtyAny persistent object that has been changed in the current transaction.
HollowAny persistent object that represents data in the datastore, but whose values are not in the instance.
Persistent CleanAny persistent object that represents data in the datastore, and whose values have not been changed in the current transaction.
Persistent DeletedAny persistent object that represents data in the datastore, and that has been deleted in the current transaction.
Persistent New DeletedAny object that have been newly made persistent and then deleted in the same current transaction.
Persistent Non transactionalAny persistent object that represents data in the datastore, whose values are loaded but not transactionally consistent.
Persistent Non transactional DirtyAny persistent object that represents data in the datastore, whose values are loaded but not transactionally consistent, and that has been modified.
Transient CleanAny transient object that represents a transactional instance whose values have not been changed in the current transaction.
Transient DirtyAny transient object that represents a transactional instance whose values have been changed in the current transaction.
Detached CleanAny detached object that represents a persistent instance whose values have not been changed since detaching.
Detached DirtyAny detached object that represents a persistent instance whose values have been changed since detaching.
- -

Detecting Object State

-

- JDO provides a class JDOHelper that allows you to interrogate the object state via its attributes (isPersistent(), isDeleted(), etc). - In JDO 2.1 for JDKs 1.5+ JDOHelper is extended to also provide a method that gives the full object state. -

-
ObjectState state = JDOHelper.getObjectState(obj);
-
-
- -

Persisting an object

-

- The most basic thing you can do with JDO is persist an object. The following code is an example of how you can do this -

-
-Transaction tx=pm.currentTransaction();
-try
-{
-    tx.begin();
-    Product product = new Product("Plate", 9.99);
-    pm.makePersistent(product);
-    tx.commit();
-}
-finally
-{
-    if (tx.isActive())
-    {
-        tx.rollback();
-    }
-}
-                
-

- The Product object progresses from Transient (initial, unpersisted state), through to Persistent New, and then finally to Hollow when it reaches the data store (after the "commit"). If the persist failed, it would "rollback" and hence end up in the same state as when it started. The following diagram shows this graphically -

-
- -
-
- -

Updating an object

-

- When you have persisted objects you need to update them. The following code is an example of how you can do this -

-
-Transaction tx=pm.currentTransaction();
-try
-{
-    tx.begin();
-    String product_name = product.getName();
-    ...
-    product.setPrice(7.50);
-    tx.commit();
-}
-finally
-{
-    if (tx.isActive())
-    {
-        tx.rollback();
-    }
-}
-                
-

- The Product object starts off in Hollow state and progresses to Persistent Clean when the user requires to read from it. It then migrates to Persistent Dirty when the price is updated. Finally it returns to Hollow when the user commits/rolls back the transaction. The following diagram shows this graphically -

-
- -
-
- -

Deleting an object

-

- When you no longer need an object persisted, you can delete it. The following code is an example of how you can do this -

-
-Transaction tx=pm.currentTransaction();
-try
-{
-    tx.begin();
-    String product_name = product.getName();
-    ...
-    pm.deletePersistent(product);
-    tx.commit();
-}
-finally
-{
-    if (tx.isActive())
-    {
-        tx.rollback();
-    }
-}
-                
-

- The Product object starts off in Hollow state and progresses to Persistent Clean when the user requires to read from it. It then migrates to Persistent Deleted when the deletePersistent() called. Finally it either progresses to Transient when commit is called, or returns to Hollow if it is rolled back. The following diagram shows this graphically -

-
- -
-
- -

Possible state transitions

-

- The following diagram shows the state transitions possible with JDO. -

-
- JDO State Transition -
-
-
- - + + +

JDO State Transition

+

+ JDO manages the lifecycle of an object, from creation (Transient) through to persistence in the datastore (Hollow, Persistent Clean) and all of the various states between these. The transition between these states are achieved by using methods on the Persistence Manager such as makePersistent(), makeTransient(), deletePersistent(), and by commiting the changes made by these operations, or by rolling them back. +

+

+ The various lifecycle states supported by JDO are shown below. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDescription
TransientAny object created by the developer that do are not persisted. These don't have a JDO identity.
Persistent NewAny object that is newly persisted in the current transaction. A JDO identity has been assigned to these objects.
Persistent DirtyAny persistent object that has been changed in the current transaction.
HollowAny persistent object that represents data in the datastore, but whose values are not in the instance.
Persistent CleanAny persistent object that represents data in the datastore, and whose values have not been changed in the current transaction.
Persistent DeletedAny persistent object that represents data in the datastore, and that has been deleted in the current transaction.
Persistent New DeletedAny object that have been newly made persistent and then deleted in the same current transaction.
Persistent Non transactionalAny persistent object that represents data in the datastore, whose values are loaded but not transactionally consistent.
Persistent Non transactional DirtyAny persistent object that represents data in the datastore, whose values are loaded but not transactionally consistent, and that has been modified.
Transient CleanAny transient object that represents a transactional instance whose values have not been changed in the current transaction.
Transient DirtyAny transient object that represents a transactional instance whose values have been changed in the current transaction.
Detached CleanAny detached object that represents a persistent instance whose values have not been changed since detaching.
Detached DirtyAny detached object that represents a persistent instance whose values have been changed since detaching.
+ +

Detecting Object State

+

+ JDO provides a class JDOHelper that allows you to interrogate the object state via its attributes (isPersistent(), isDeleted(), etc). + In JDO 2.1 for JDKs 1.5+ JDOHelper is extended to also provide a method that gives the full object state. +

+
ObjectState state = JDOHelper.getObjectState(obj);
+
+
+ +

Persisting an object

+

+ The most basic thing you can do with JDO is persist an object. The following code is an example of how you can do this +

+
+Transaction tx=pm.currentTransaction();
+try
+{
+    tx.begin();
+    Product product = new Product("Plate", 9.99);
+    pm.makePersistent(product);
+    tx.commit();
+}
+finally
+{
+    if (tx.isActive())
+    {
+        tx.rollback();
+    }
+}
+                
+

+ The Product object progresses from Transient (initial, unpersisted state), through to Persistent New, and then finally to Hollow when it reaches the data store (after the "commit"). If the persist failed, it would "rollback" and hence end up in the same state as when it started. The following diagram shows this graphically +

+
+ +
+
+ +

Updating an object

+

+ When you have persisted objects you need to update them. The following code is an example of how you can do this +

+
+Transaction tx=pm.currentTransaction();
+try
+{
+    tx.begin();
+    String product_name = product.getName();
+    ...
+    product.setPrice(7.50);
+    tx.commit();
+}
+finally
+{
+    if (tx.isActive())
+    {
+        tx.rollback();
+    }
+}
+                
+

+ The Product object starts off in Hollow state and progresses to Persistent Clean when the user requires to read from it. It then migrates to Persistent Dirty when the price is updated. Finally it returns to Hollow when the user commits/rolls back the transaction. The following diagram shows this graphically +

+
+ +
+
+ +

Deleting an object

+

+ When you no longer need an object persisted, you can delete it. The following code is an example of how you can do this +

+
+Transaction tx=pm.currentTransaction();
+try
+{
+    tx.begin();
+    String product_name = product.getName();
+    ...
+    pm.deletePersistent(product);
+    tx.commit();
+}
+finally
+{
+    if (tx.isActive())
+    {
+        tx.rollback();
+    }
+}
+                
+

+ The Product object starts off in Hollow state and progresses to Persistent Clean when the user requires to read from it. It then migrates to Persistent Deleted when the deletePersistent() called. Finally it either progresses to Transient when commit is called, or returns to Hollow if it is rolled back. The following diagram shows this graphically +

+
+ +
+
+ +

Possible state transitions

+

+ The following diagram shows the state transitions possible with JDO. +

+
+ JDO State Transition +
+
+
+ +
Modified: websites/production/db/content/jdo/svn.html ============================================================================== --- websites/production/db/content/jdo/svn.html (original) +++ websites/production/db/content/jdo/svn.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,179 +210,179 @@
- - - - -

Source Code Version Control

- -

Apache JDO uses Subversion to manage its source code. -If you're new to Subversion, you can check out the -online book about Subversion. -Note that we are currently using Subversion 1.1.x (there are separate -versions of the book covering 1.0 and 1.1). -

-

-To receive notice of commits to the repository subscribe to jdo-commits@db.apache.org by sending email to jdo-commits-subscribe@db.apache.org.

- -
- -

Web Access to Subversion

- -

-If you just want to browse the source code, you can use the - -ViewCVS web interface to Subversion. This is current at all times. -

- -
- -

Checking Out Code Using Subversion

- -

Anyone can check code out of Subversion. You only need to specify a -username and password to update the Subversion repository, and only -JDO committers can do that. -If you are a committer, are working from behind a firewall, or are connected to the internet through a proxy server, please see the sections below for more information.

- -

Anonymous check out from Subversion

-

Use a command like:

-
% svn checkout http://svn.apache.org/repos/asf/db/jdo 
-

Once you have Apache JDO checked out you can update the source by executing the following command from within the jdo.

-
-% svn update
-
-
-

Access from behind a firewall

- -

For those users who are stuck behind a corporate firewall which is blocking http access to the Subversion repository, you can try to access it via HTTPS:

-
-% svn checkout https://svn.apache.org/repos/asf/db/jdo
-
- -
-

Access through a proxy

- -

The Subversion client can go through a proxy, if you configure it to do so. First, edit your "servers" configuration file to indicate which proxy to use. The files location depends on your operating system. On Linux or Unix it is located in the directory "~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden directory.)

-

There are comments in the file explaining what to do. If you don't have that file, get the latest Subversion client and run any command; this will cause the configuration directory and template files to be created.

-

Example : Edit the 'servers' file and add something like :

-
-[global]
-http-proxy-host = your.proxy.name
-http-proxy-port = 3128
-
-

Please use the regular http proxy settings in case you want to access the the repository from the Sun network (SWAN).

- -
- -

Committer access

- -

Everyone can access the Apache JDO Subversion repository via HTTPS, but Apache JDO Committers must checkout the Subversion repository via HTTPS.

-
-% svn checkout https://svn.apache.org/repos/asf/db/jdo
-
-
-

NetBeans CVS repository access

- -

The btree subproject checks out the NetBeans mdr btree implementation. This requires cvs being installed on your system. The official NetBeans cvs host might not work if you are behind a firewall that blocks the cvs port. Please consult the NetBeans sources page for more info.

-

If you do not have a cvs client installed on your system you can download the NetBeans mdr btree sources here. Unzip the file in the btree directory and comment out (or remove) the definition of the preGoal java:prepare-filesystem.

-
-
- -

Submitting Code Changes

-

Submitting a patch

- -

If you make changes to Apache JDO, and would like to contribute the to the project, you should create a patch and send it to the jdo-dev alias jdo-dev@db.apache.org. To create a patch, simply execute the following command:

-
-% svn diff > your-changes.patch
-
-
- -

Committing changes to subversion

-

-To commit changes to the Subversion repository, you must be an Apache JDO committer. See Get Involved for information on how to become a committer and how to set up your password once you become a committer. -

- -

-Once your password is set, you can use a command like this to commit: -

-
-$> svn commit --username your-username
-Authentication realm: <https://svn.apache.org:443> ASF Committers
-Password for 'your-username': your-password
-
-

You can also pass your password on the command line directly, but this is a security problem on multiuser unix computers (the command line arguments are available via the ps command). Here is the command if you are Windows or a single user unix computer:

-
-$> svn commit --username your-username --password your-password
-
-

Remember to replace 'your-username' and 'your-password' with your actual username and password on svn.apache.org.

- -
-
- -

Building JDO from Source

-

Refer to the Wiki -page for details. Note that the JDO project is subdivided into several -smaller projects, and each project is built separately.

- -
- -

Using Subversion on Windows with cygwin

- -

If you use Subversion on Windows under cygwin, you may find that the Subversion client automatically assigns the executable property to non-executable files. In that case, you would see this at the bottom of an svn diff of the file: -

-
-Property changes on: test/sql/derby/datastoreidentity/schema1.sql
-___________________________________________________________________
-Name: svn:executable
-   + *
-
-

This section explains the source of the problem and suggests some actions to avoid it.

- -

Background

- -

Subversion carries executable information in the built-in property called svn:executable. This property, unlike others, may be present or absent, but it has no value. You can add it or delete it, but but you cannot change its value.

-

In theory, Subversion ignores Windows file permissions and by default does not set svn:executable. However, cygwin svn acts like Unix svn and determines the svn:executable property based on file permissions.

-

If you create a file from the cygwin command line, by default it is executable only if the filename ends with .bat, .com or .exe, or if its content starts with #!. [This is what the doc says, but you may see -x for all files.] If you create a file using a Windows tool, by default its Windows permissions are executable by all. Cygwin interprets the Unix-style permissions this way as well. If the file is executable by all, cygwin svn sets the svn:executable property on the file when you invoke svn add.

-
-

Removing existing executable properties from the repository

- -

You can use svn propdel to remove the svn:executable property from your working copy. -

-
-    svn propdel -R svn:executable .
-
-

will recursively remove the svn:executable property from all of the files below the current directory. You can use this and commit the files to clean the repository if necessary.

- -
-

Preventing Subversion from adding unwanted executable properties

- -

Windows/cygwin users who don't want to have to think about using svn propdel or chmod on each added file can use a non-cygwin version of svn. The Subversion 1.2.3 Win32 binaries, downloadable from the link at the bottom of http://subversion.tigris.org/project_packages.html, appear to work well. After installation add the svn.exe location to your Windows PATH variable. If you are switching from cygwin svn to Win32 svn

-
    -
  1. Remove the subversion component from your cygwin installation because when svn is invoked from a cygwin window, the cygwin version is found even if your cygwin/bin directory is later on the path. (In the Select Packages window of the setup wizard, navigate to the subversion package in the Devel. category. Click on the status icon until Uninstall is displayed. Click next and continue through the wizard until installation is complete.)

    - -
  2. -
  3. Copy the servers file and the auth folder from the sygwin ~/.subversion directory to C:\Documents and Settings\<user>\Application Data\Subversion used by Win32 subversion.

    -
  4. -
-

Note that windows svn uses backslash as the path separator when displaying file names. You cannot just copy and paste this file name to another svn command when running from within a cygwin shell. You need to enclose the file name into double quotes.

-

Alternatively, Windows users can set file permissions in Windows Explorer. (Right-click on the top-level folder & select Properties. Select the Security tab. Click Advanced. Remove all instances of Read & Execute from the Permission Entries. Click "Reset permissions on all child objects and enable propogations of inheritable permissions". Click Apply. OK. OK.) You will have to do this again when you do a clean checkout to a new directory.

- -
-
- + + + + +

Source Code Version Control

+ +

Apache JDO uses Subversion to manage its source code. +If you're new to Subversion, you can check out the +online book about Subversion. +Note that we are currently using Subversion 1.1.x (there are separate +versions of the book covering 1.0 and 1.1). +

+

+To receive notice of commits to the repository subscribe to jdo-commits@db.apache.org by sending email to jdo-commits-subscribe@db.apache.org.

+ +
+ +

Web Access to Subversion

+ +

+If you just want to browse the source code, you can use the + +ViewCVS web interface to Subversion. This is current at all times. +

+ +
+ +

Checking Out Code Using Subversion

+ +

Anyone can check code out of Subversion. You only need to specify a +username and password to update the Subversion repository, and only +JDO committers can do that. +If you are a committer, are working from behind a firewall, or are connected to the internet through a proxy server, please see the sections below for more information.

+ +

Anonymous check out from Subversion

+

Use a command like:

+
% svn checkout http://svn.apache.org/repos/asf/db/jdo 
+

Once you have Apache JDO checked out you can update the source by executing the following command from within the jdo.

+
+% svn update
+
+
+

Access from behind a firewall

+ +

For those users who are stuck behind a corporate firewall which is blocking http access to the Subversion repository, you can try to access it via HTTPS:

+
+% svn checkout https://svn.apache.org/repos/asf/db/jdo
+
+ +
+

Access through a proxy

+ +

The Subversion client can go through a proxy, if you configure it to do so. First, edit your "servers" configuration file to indicate which proxy to use. The files location depends on your operating system. On Linux or Unix it is located in the directory "~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden directory.)

+

There are comments in the file explaining what to do. If you don't have that file, get the latest Subversion client and run any command; this will cause the configuration directory and template files to be created.

+

Example : Edit the 'servers' file and add something like :

+
+[global]
+http-proxy-host = your.proxy.name
+http-proxy-port = 3128
+
+

Please use the regular http proxy settings in case you want to access the the repository from the Sun network (SWAN).

+ +
+ +

Committer access

+ +

Everyone can access the Apache JDO Subversion repository via HTTPS, but Apache JDO Committers must checkout the Subversion repository via HTTPS.

+
+% svn checkout https://svn.apache.org/repos/asf/db/jdo
+
+
+

NetBeans CVS repository access

+ +

The btree subproject checks out the NetBeans mdr btree implementation. This requires cvs being installed on your system. The official NetBeans cvs host might not work if you are behind a firewall that blocks the cvs port. Please consult the NetBeans sources page for more info.

+

If you do not have a cvs client installed on your system you can download the NetBeans mdr btree sources here. Unzip the file in the btree directory and comment out (or remove) the definition of the preGoal java:prepare-filesystem.

+
+
+ +

Submitting Code Changes

+

Submitting a patch

+ +

If you make changes to Apache JDO, and would like to contribute the to the project, you should create a patch and send it to the jdo-dev alias jdo-dev@db.apache.org. To create a patch, simply execute the following command:

+
+% svn diff > your-changes.patch
+
+
+ +

Committing changes to subversion

+

+To commit changes to the Subversion repository, you must be an Apache JDO committer. See Get Involved for information on how to become a committer and how to set up your password once you become a committer. +

+ +

+Once your password is set, you can use a command like this to commit: +

+
+$> svn commit --username your-username
+Authentication realm: <https://svn.apache.org:443> ASF Committers
+Password for 'your-username': your-password
+
+

You can also pass your password on the command line directly, but this is a security problem on multiuser unix computers (the command line arguments are available via the ps command). Here is the command if you are Windows or a single user unix computer:

+
+$> svn commit --username your-username --password your-password
+
+

Remember to replace 'your-username' and 'your-password' with your actual username and password on svn.apache.org.

+ +
+
+ +

Building JDO from Source

+

Refer to the Wiki +page for details. Note that the JDO project is subdivided into several +smaller projects, and each project is built separately.

+ +
+ +

Using Subversion on Windows with cygwin

+ +

If you use Subversion on Windows under cygwin, you may find that the Subversion client automatically assigns the executable property to non-executable files. In that case, you would see this at the bottom of an svn diff of the file: +

+
+Property changes on: test/sql/derby/datastoreidentity/schema1.sql
+___________________________________________________________________
+Name: svn:executable
+   + *
+
+

This section explains the source of the problem and suggests some actions to avoid it.

+ +

Background

+ +

Subversion carries executable information in the built-in property called svn:executable. This property, unlike others, may be present or absent, but it has no value. You can add it or delete it, but but you cannot change its value.

+

In theory, Subversion ignores Windows file permissions and by default does not set svn:executable. However, cygwin svn acts like Unix svn and determines the svn:executable property based on file permissions.

+

If you create a file from the cygwin command line, by default it is executable only if the filename ends with .bat, .com or .exe, or if its content starts with #!. [This is what the doc says, but you may see -x for all files.] If you create a file using a Windows tool, by default its Windows permissions are executable by all. Cygwin interprets the Unix-style permissions this way as well. If the file is executable by all, cygwin svn sets the svn:executable property on the file when you invoke svn add.

+
+

Removing existing executable properties from the repository

+ +

You can use svn propdel to remove the svn:executable property from your working copy. +

+
+    svn propdel -R svn:executable .
+
+

will recursively remove the svn:executable property from all of the files below the current directory. You can use this and commit the files to clean the repository if necessary.

+ +
+

Preventing Subversion from adding unwanted executable properties

+ +

Windows/cygwin users who don't want to have to think about using svn propdel or chmod on each added file can use a non-cygwin version of svn. The Subversion 1.2.3 Win32 binaries, downloadable from the link at the bottom of http://subversion.tigris.org/project_packages.html, appear to work well. After installation add the svn.exe location to your Windows PATH variable. If you are switching from cygwin svn to Win32 svn

+
    +
  1. Remove the subversion component from your cygwin installation because when svn is invoked from a cygwin window, the cygwin version is found even if your cygwin/bin directory is later on the path. (In the Select Packages window of the setup wizard, navigate to the subversion package in the Devel. category. Click on the status icon until Uninstall is displayed. Click next and continue through the wizard until installation is complete.)

    + +
  2. +
  3. Copy the servers file and the auth folder from the sygwin ~/.subversion directory to C:\Documents and Settings\<user>\Application Data\Subversion used by Win32 subversion.

    +
  4. +
+

Note that windows svn uses backslash as the path separator when displaying file names. You cannot just copy and paste this file name to another svn command when running from within a cygwin shell. You need to enclose the file name into double quotes.

+

Alternatively, Windows users can set file permissions in Windows Explorer. (Right-click on the top-level folder & select Properties. Select the Security tab. Click Advanced. Remove all instances of Read & Execute from the Permission Entries. Click "Reset permissions on all child objects and enable propogations of inheritable permissions". Click Apply. OK. OK.) You will have to do this again when you do a clean checkout to a new directory.

+ +
+
+