Modified: websites/production/db/content/jdo/glossary.html ============================================================================== --- websites/production/db/content/jdo/glossary.html (original) +++ websites/production/db/content/jdo/glossary.html Tue Jan 15 06:29:01 2013 @@ -1,44 +1,362 @@ -Java Data Objects (JDO) - JDO Glossary

JDO Glossary

+ + + + + + Maven - + JDO Glossary + + + + + + + +

+ +
+ +
+
+
+ + +

JDO Glossary

+

JDO utilizes some terminology used elsewhere (e.g J2EE) but also introduces some terminology that may be new to people. Below is a glossary of some common terms that may be encountered. -

+ + + + + + + + + + + + + +
TermDefinition
application identityWhen the persistence of a class is defined in a MetaData file, the developer can decide that they want - to control the identity of objects of that class. This is called application identity because - the application has the control.
attach/detachWhen you have an object of a class that is associated with a PersistenceManager it is referred to as being - attached. If you want to stop persistence of that object you can detach the object. This has +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TermDefinition
application identityWhen the persistence of a class is defined in a MetaData file, the developer can decide that they want + to control the identity of objects of that class. This is called application identity because + the application has the control.
attach/detachWhen you have an object of a class that is associated with a PersistenceManager it is referred to as being + attached. If you want to stop persistence of that object you can detach the object. This has the effect that any changes to the object will not be persisted, and also that the object can be used - outside transactions.
datastore identityWhen the persistence of a class is defined in a MetaData file, the developer can decide that they want the - identity of objects of that class to be defined by the JDO implementation. This is called datastore - identity
default-fetch-group (DFG)When a persisted object is retrieved from the datastore its fields can be retrieved with it, or optionally - can be retrieved only when needed. If a field is in the default-fetch-group it will be retrieved when - the object is retrieved. Some field types default to being in the default-fetch-group (e.g primitives, - wrappers to primtives, java.util.Date) and others (e.g java.util.Set, java.util.List) don't.
embeddedA field can be defined as embedded if it will be stored as a column in the table of its containing object.
enhancerJDO 1.0.1 requires the use of a byte-code enhancer that takes the Java compiled classes and "enhances" them, - adding in information to permit their use in a JDO environment.
FCOJDO defines 2 main groups of Java objects. The first is those objects that have an identity. These are - termed "First Class Objects" or FCO for short.
Fetch GroupJDO allows a user to define groups of fields that should be retrieved (fetched) at the same time. These are called a "fetch group". - The principal "fetch group" is the "default fetch group", where JDO has rules for what fields are in this group. - A user can define their own group, and make this active so that when objects of their type are retrieved, they have control over the fetching process.
JDOQLJDO introduces its own Java-like query language as a datastore independent way of retrieving objects from - the datastore. This is known as JDOQL (JDO Query Language).
nondurable identityWhere the objects of a class should be unique in the JVM but not in the datastore (where an RDBMS table doesnt have a PK for example).
objectid classWhen an object of a class is persisted, it is assigned an object identity. When the developer has chosen to + outside transactions.
datastore identityWhen the persistence of a class is defined in a MetaData file, the developer can decide that they want the + identity of objects of that class to be defined by the JDO implementation. This is called datastore + identity
default-fetch-group (DFG)When a persisted object is retrieved from the datastore its fields can be retrieved with it, or optionally + can be retrieved only when needed. If a field is in the default-fetch-group it will be retrieved when + the object is retrieved. Some field types default to being in the default-fetch-group (e.g primitives, + wrappers to primtives, java.util.Date) and others (e.g java.util.Set, java.util.List) don't.
embeddedA field can be defined as embedded if it will be stored as a column in the table of its containing object.
enhancerJDO 1.0.1 requires the use of a byte-code enhancer that takes the Java compiled classes and "enhances" them, + adding in information to permit their use in a JDO environment.
FCOJDO defines 2 main groups of Java objects. The first is those objects that have an identity. These are + termed "First Class Objects" or FCO for short.
Fetch GroupJDO allows a user to define groups of fields that should be retrieved (fetched) at the same time. These are called a "fetch group". + The principal "fetch group" is the "default fetch group", where JDO has rules for what fields are in this group. + A user can define their own group, and make this active so that when objects of their type are retrieved, they have control over the fetching process.
JDOQLJDO introduces its own Java-like query language as a datastore independent way of retrieving objects from + the datastore. This is known as JDOQL (JDO Query Language).
nondurable identityWhere the objects of a class should be unique in the JVM but not in the datastore (where an RDBMS table doesnt have a PK for example).
objectid classWhen an object of a class is persisted, it is assigned an object identity. When the developer has chosen to use application identity they can assign a class to represent this - identity (as a primary key) - this is the object id class.
optimistic transactionWhen working with long duration transactions it is undesirable to have locking and so the assumption is made + identity (as a primary key) - this is the object id class.
optimistic transactionWhen working with long duration transactions it is undesirable to have locking and so the assumption is made that the data being updated by the transaction will not be modified by any other transaction during the course of the (optimistic) transaction. The data is checked just before commit to confirm integrity that no data has been changed. See also pessimistic transaction for the contrary type - which provides locking.
persistence-by-reachabilityWhen you call makePersistent() on an object, the object will be persisted and, in addition, any + which provides locking.
persistence-by-reachabilityWhen you call makePersistent() on an object, the object will be persisted and, in addition, any other objects reachable from that object (via relationships) will also be persisted. This is - known as persistence-by-reachability. This process is repeated at commit() time when - it checks whether these reachable objects are still reachable and, if not, removes them from persistence.
persistence-awareWhen an class needs to access fields of a persistence capable class directly, it should be enhanced, and is referred to as "Persistence Aware". If a class uses field accessor methods then it doesnt need to become "Persistence Aware".
persistence-capable (PC)When an class is byte-code enhanced, and has valid MetaData, it is referred to as "Persistence Capable". This - means that it can be persisted by a JDO implementation.
persistence-modifierWhen defining the persistence of a class, the developer can select particular fields to be persisted, and - others not depending on their importance in the scope of their application. The persistence-modifier + known as persistence-by-reachability. This process is repeated at commit() time when + it checks whether these reachable objects are still reachable and, if not, removes them from persistence.
persistence-awareWhen an class needs to access fields of a persistence capable class directly, it should be enhanced, and is referred to as "Persistence Aware". If a class uses field accessor methods then it doesnt need to become "Persistence Aware".
persistence-capable (PC)When an class is byte-code enhanced, and has valid MetaData, it is referred to as "Persistence Capable". This + means that it can be persisted by a JDO implementation.
persistence-modifierWhen defining the persistence of a class, the developer can select particular fields to be persisted, and + others not depending on their importance in the scope of their application. The persistence-modifier defines whether a field is persistent. If this tag is not specified JDO will assign defaults based on the field type (primitives, primitive wrappers, java.util.Data, persistence capable fields, etc are by default - persistent).
persistentThis is an object state where the object is persistent in a datastore.
pessimistic transactionThis is the default transaction type in JDO, and is suitable for shortlived operations where there is no + persistent).
persistentThis is an object state where the object is persistent in a datastore.
pessimistic transactionThis is the default transaction type in JDO, and is suitable for shortlived operations where there is no other blocking activity during the transaction. When data is accessed other transactions are locked out from accessing it until the transaction is complete. See also optimistic - transaction for the contrary type which reduces locking.
Requires ExtentWhen the persistent of a class is defined, the developer decides if the object will be stored with its own + transaction for the contrary type which reduces locking.
Requires ExtentWhen the persistent of a class is defined, the developer decides if the object will be stored with its own identity (in its own table for example) or whether it will be stored as part of another object. If it will - have its own identity, it will require and Extent.
SCOJDO defines 2 main groups of Java objects. The second group is those objects that don't have an identity. - These are termed "Second Class Objects" or SCO for short.
SQLJDO allows use of multiple query languages. One of these, for use with RDBMS datastores, is SQL.
transientThis is an object state where the object is not persistent.

\ No newline at end of file + have its own identity, it will require and Extent.
SCOJDO defines 2 main groups of Java objects. The second group is those objects that don't have an identity. + These are termed "Second Class Objects" or SCO for short.
SQLJDO allows use of multiple query languages. One of these, for use with RDBMS datastores, is SQL.
transientThis is an object state where the object is not persistent.
+
+ + + +
+
+
+
+
+ + + Modified: websites/production/db/content/jdo/guides.html ============================================================================== --- websites/production/db/content/jdo/guides.html (original) +++ websites/production/db/content/jdo/guides.html Tue Jan 15 06:29:01 2013 @@ -1,9 +1,239 @@ -Java Data Objects (JDO) - JDO Guides

Guides

- This section provides guides to the process of introducing JDO into your - application. -


\ No newline at end of file + + + + + + Maven - + JDO Guides + + + + + + + + + +
+ +
+
+
+ + +

Guides

+

+ This section provides guides to the process of introducing JDO into your application. +

+
+ + +
+
+
+
+
+ + + Modified: websites/production/db/content/jdo/guides/maven-jdo.html ============================================================================== --- websites/production/db/content/jdo/guides/maven-jdo.html (original) +++ websites/production/db/content/jdo/guides/maven-jdo.html Tue Jan 15 06:29:01 2013 @@ -1,164 +1,456 @@ -Java Data Objects (JDO) - JDO and Maven1

JDO Meets Maven

- By Andy Jefferson -

Background - Maven

Maven is a tool for managing + + + + + + Maven - + JDO and Maven + + + + + + + + +

+ +
+ +
+
+
+ + +

JDO Meets Maven

+

+ By Andy Jefferson +

+ +

Background - Maven

+

Maven is a tool for managing and building projects providing an alternative to the accepted - Ant build process. Maven is + Ant build process. Maven is almost totally plugin-driven, and provides plugins for many common tasks (for example: building EJB components such as WARs and EARs, generating documentation, running unit tests) and related software (for example: - Checkstyle, - PMD, - Clover, - JCoverage).

Maven builds on top of the definition of a project. It formalises project + Checkstyle, + PMD, + Clover, + JCoverage).

+ +

Maven builds on top of the definition of a project. It formalises project definitions such as dependencies (and hence classpaths), versions, source repositories, mailing lists, etc. This project definition provides placeholders for all of the typical metrics important to a project. It formalises the location of the source tree for a project and of the unit tests. This rigorous structure allows Maven's plugins to provide generalised functionality such as building the - source tree, running the unit tests, generating javadoc, code analysis, etc.

Maven operates using the concept of goals. Each goal can have "pre" - and "post" goals. This structure allows for chaining of operations, with one - operation firing off another, and another to achieve some overall end result.

Integrating JDO with Maven

In developing a JDO system, the developer has many concerns - not least the likes + source tree, running the unit tests, generating javadoc, code analysis, etc.

+ +

Maven operates using the concept of goals. Each goal can have "pre" + and "post" goals. This structure allows for chaining of operations, with one + operation firing off another, and another to achieve some overall end result.

+
+ +

Integrating JDO with Maven

+

In developing a JDO system, the developer has many concerns - not least the likes of object-relationship mapping - and should, as far as possible, be spared the - "administrative" burdens associated with building the system. Maven's + "administrative" burdens associated with building the system. Maven's formalization of the source tree structure and chaining of actions helps achieve this objective by saving the developer from having to explicitly define tasks like JDO class bytecode-enhancement. Thus, rather than explicitly invoking a bytecode-enhancement task in the system build, Maven is able to provide this activity by way of a plugin, which could even be automatically chained off the - existing Java compilation task.

Anatomy of a Maven JDO plugin

A Maven plugin can use a variety of languages, however most commonly utilises - Jelly scripting language, at least for definition of the plugin's goals. + existing Java compilation task.

+
+ +

Anatomy of a Maven JDO plugin

+

A Maven plugin can use a variety of languages, however most commonly utilises + Jelly scripting language, at least for definition of the plugin's goals. A Maven plugin typically requires a minimum of 3 files ... -

    -
  • project.xml (defining the dependencies of the plugin on other software)
  • -
  • plugin.jelly (providing the goals definition)
  • -
  • plugin.properties (properties available for configuration)
  • -
+

+
    +
  • project.xml (defining the dependencies of the plugin on other software)
  • +
  • plugin.jelly (providing the goals definition)
  • +
  • plugin.properties (properties available for configuration)
  • +
+

Maven plugins can use a variety of other scripting and templating utilities, however - these are not currently required for the JDO plugins implemented.

Plugins have now been developed for - JPOX, and - TJDO, though can readily be + these are not currently required for the JDO plugins implemented.

+ +

Plugins have now been developed for + JPOX, and + TJDO, though can readily be developed for any JDO implementation. The best way of understanding the process involved is by analysing a Maven JDO plugin - in this case, the JPOX plugin. Here - the plugin.jelly file is as follows:

-
-<goal name="<B>jpox</B>"
-    description="Enhance classes for use with Java Persistent Objects (JPOX)"
-    prereqs="jpox:enhance"/>
+				the plugin.jelly file is as follows:

+
+<goal name="jpox"
+    description="Enhance classes for use with Java Persistent Objects (JPOX)"
+    prereqs="jpox:enhance"/>
 
-<goal name="<B>jpox:init</B>">
-    ... snip ... code to generate <B>jpoxClasspath</B> and <B>jpoxMetaDataFiles</B>
+<goal name="jpox:init">
+    ... snip ... code to generate jpoxClasspath and jpoxMetaDataFiles
 </goal>
 
-<goal name="<B>jpox:enhance</B>"
-    description="Perform the enhancement of classes for use with JPOX"
-    prereqs="jpox:init">
+<goal name="jpox:enhance"
+    description="Perform the enhancement of classes for use with JPOX"
+    prereqs="jpox:init">
     <echo>JDO-enhancing classes for Java Persistent Objects</echo>
 
-    <ant:java dir="${maven.build.dest}"
-        classname="org.jpox.enhance.SunReferenceEnhancer"
-        failonerror="true"
-        fork="true">
-        <classpath refid="jpoxClasspath"/>
-        <arg line="${jpoxMetaDataFiles}"/>
+    <ant:java dir="${maven.build.dest}"
+        classname="org.jpox.enhance.SunReferenceEnhancer"
+        failonerror="true"
+        fork="true">
+        <classpath refid="jpoxClasspath"/>
+        <arg line="${jpoxMetaDataFiles}"/>
     </ant:java>
 
     <echo>Classes are now JDO-enhanced for Java Persistent Objects</echo>
 </goal>
-

It can be seen that the plugin has several goals, the default one being to run the + +

It can be seen that the plugin has several goals, the default one being to run the enhance goal. Since this goal requires (as a prerequisite) the running of the init - goal, they are chained.

Some JDO implementations (for example JPOX, or Kodo) allow the generation of the + goal, they are chained.

+ +

Some JDO implementations (for example JPOX, or Kodo) allow the generation of the JDO database schema prior to running the JDO-enabled application. This is catered - for with additional goal(s). For JPOX again, this is handled as follows

-
-<goal name="<B>jpox:schema-create</B>"
-    prereqs="jpox:init">
+				for with additional goal(s). For JPOX again, this is handled as follows 

+ +
+<goal name="jpox:schema-create"
+    prereqs="jpox:init">
     <echo>Creating tables for Persistence Capability</echo>
 
-    <ant:java dir="${maven.build.dest}"
-        classname="org.jpox.SchemaTool"
-        failonerror="true"
-        fork="true">
-        <classpath refid="jpoxClasspath"/>
-        <sysproperty key="database.driver" value="${maven.jpox.database.driver}"/>
-        <sysproperty key="database.url" value="${maven.jpox.database.url}"/>
-        <sysproperty key="database.user" value="${maven.jpox.database.user}"/>
-        <sysproperty key="database.password" value="${maven.jpox.database.password}"/>
-        <arg line="-create"/>
-        <arg line="${jpoxMetaDataFiles}"/>
+    <ant:java dir="${maven.build.dest}"
+        classname="org.jpox.SchemaTool"
+        failonerror="true"
+        fork="true">
+        <classpath refid="jpoxClasspath"/>
+        <sysproperty key="database.driver" value="${maven.jpox.database.driver}"/>
+        <sysproperty key="database.url" value="${maven.jpox.database.url}"/>
+        <sysproperty key="database.user" value="${maven.jpox.database.user}"/>
+        <sysproperty key="database.password" value="${maven.jpox.database.password}"/>
+        <arg line="-create"/>
+        <arg line="${jpoxMetaDataFiles}"/>
     </ant:java>
 </goal>
 
-<goal name="<B>jpox:schema-delete</B>"
-    prereqs="jpox:init">
+<goal name="jpox:schema-delete"
+    prereqs="jpox:init">
     <echo>Deleting tables for Persistence Capability</echo>
 
-    <ant:java dir="${maven.build.dest}"
-        classname="org.jpox.SchemaTool"
-        failonerror="true"
-        fork="true">
-        <classpath refid="jpoxClasspath"/>
-        <sysproperty key="database.driver" value="${maven.jpox.database.driver}"/>
-        <sysproperty key="database.url" value="${maven.jpox.database.url}"/>
-        <sysproperty key="database.user" value="${maven.jpox.database.user}"/>
-        <sysproperty key="database.password" value="${maven.jpox.database.password}"/>
-        <arg line="-delete"/>
-        <arg line="${jpoxMetaDataFiles}"/>
+    <ant:java dir="${maven.build.dest}"
+        classname="org.jpox.SchemaTool"
+        failonerror="true"
+        fork="true">
+        <classpath refid="jpoxClasspath"/>
+        <sysproperty key="database.driver" value="${maven.jpox.database.driver}"/>
+        <sysproperty key="database.url" value="${maven.jpox.database.url}"/>
+        <sysproperty key="database.user" value="${maven.jpox.database.user}"/>
+        <sysproperty key="database.password" value="${maven.jpox.database.password}"/>
+        <arg line="-delete"/>
+        <arg line="${jpoxMetaDataFiles}"/>
     </ant:java>
     </goal>
-

Hence there are 2 additional goals, one for creating all tables required by + +

Hence there are 2 additional goals, one for creating all tables required by JPOX, and a second for deleting these tables. Clearly this has more relevance to - schema generation than for existing schemas

Where a JDO implementation allows a particular configuration operation, a Maven - plugin goal can be added to deliver this functionality to the Maven user. + schema generation than for existing schemas

+

Where a JDO implementation allows a particular configuration operation, a Maven + plugin goal can be added to deliver this functionality to the Maven user. As a result, individual implementations can add as many goals as they wish to - fulfil their users requirements.

Using a Maven JDO plugin

Using the JPOX Maven plugin as an example, the basic enhancement process could be + fulfil their users requirements.

+
+ +

Using a Maven JDO plugin

+

Using the JPOX Maven plugin as an example, the basic enhancement process could be invoked as follows:

-
maven jpox:enhance
-

The problem with this is that it burdens the developer with having to explicitly +

maven jpox:enhance
+

The problem with this is that it burdens the developer with having to explicitly invoke the enhancement process. As an alternative it is possible to integrate bytecode enhancement as an automatic step chained off the basic Java compilation process. This is achieved by including the following in the project - maven.xml file:

-
-<postGoal name="java:compile">
-    <attainGoal name="jpox:enhance"/>
+				maven.xml file:

+
+<postGoal name="java:compile">
+    <attainGoal name="jpox:enhance"/>
 </postGoal>
-

So wherever the java:compile goal is called, as a postGoal it runs the - jpox:enhance goal, leaving the developer with JDO enabled classes ready to - run.

Maven's plugins can be made configurable using properties specified in the - plugin.properties file. For the JPOX plugin, the following properties can + +

So wherever the java:compile goal is called, as a postGoal it runs the + jpox:enhance goal, leaving the developer with JDO enabled classes ready to + run.

+ +

Maven's plugins can be made configurable using properties specified in the + plugin.properties file. For the JPOX plugin, the following properties can be set -

    -
  • maven.jpox.jdo.fileset.dir : Directory containing the JDO MetaData files
  • -
  • maven.jpox.jdo.fileset.include : Fileset include path for JDO MetaData files (default: **/*.jdo)
  • -
  • maven.jpox.jdo.fileset.exclude : Fileset exclude path for JDO MetaData files
  • -
  • maven.jpox.database.driver : Driver for use in connecting to datastore
  • -
  • maven.jpox.database.url : URL defining the datastore
  • -
  • maven.jpox.database.user : Login name for the datastore
  • -
  • maven.jpox.database.password : Password for the datastore
  • -
- For example, the following properties could be included in the Maven project.properties file

-
+		    

+
    +
  • maven.jpox.jdo.fileset.dir : Directory containing the JDO MetaData files
  • +
  • maven.jpox.jdo.fileset.include : Fileset include path for JDO MetaData files (default: **/*.jdo)
  • +
  • maven.jpox.jdo.fileset.exclude : Fileset exclude path for JDO MetaData files
  • +
  • maven.jpox.database.driver : Driver for use in connecting to datastore
  • +
  • maven.jpox.database.url : URL defining the datastore
  • +
  • maven.jpox.database.user : Login name for the datastore
  • +
  • maven.jpox.database.password : Password for the datastore
  • +
+

+ For example, the following properties could be included in the Maven project.properties file +

+ +
 maven.jpox.jdo.fileset.dir=${basedir}/jdo
 maven.jpox.jdo.fileset.include=**/*.jdo
 maven.jpox.database.driver=com.mysql.jdbc.Driver
 maven.jpox.database.url=jdbc:mysql://localhost/jpox
 maven.jpox.database.user={my_username}
 maven.jpox.database.password={my_password}
-

This would define the JDO MetaData files residing under the "jdo" project directory, with names matching *.jdo and would be used when all JDO plugin goals (such as enhance) are called. The 4 database properties are used in the schema-create/schema-delete goals (as seen in the plugin.jelly file earlier).

Invocation of the JPOX schema-create optional goal could be achieved as follows:

-
maven jpox:schema-create
-

Conclusion

This article has attempted to give a feel for both the operation of Maven, and how + +

This would define the JDO MetaData files residing under the "jdo" project directory, with names matching *.jdo and would be used when all JDO plugin goals (such as enhance) are called. The 4 database properties are used in the schema-create/schema-delete goals (as seen in the plugin.jelly file earlier).

+ +

Invocation of the JPOX schema-create optional goal could be achieved as follows:

+
maven jpox:schema-create
+
+ +

Conclusion

+

This article has attempted to give a feel for both the operation of Maven, and how to integrate JDO into a Maven project. The various Maven JDO plugins can be downloaded as follows -

-

About the author

Andy Jefferson is an independent software consultant who has been working in the +

+ +
+ +

About the author

+

Andy Jefferson is an independent software consultant who has been working in the IT industry for more than 15 years, primarily in the United Kingdom. He is an active participator in several OpenSource projects, primarily JPOX, and - Apache JDO, and a member of the JSR243 (JDO2) Expert Group.


\ No newline at end of file + Apache JDO, and a member of the JSR243 (JDO2) Expert Group.

+
+
+ + +
+
+
+
+
+ + +