#18 Convert DataProvider to a modular MVN project

[Kevin Black]

The DataProvider APIs would be more easily consumed by CCASH and other projects if it were a modular MVN project with the following modules:

• common: packages: base, orm, orm.graphutils, util (parts), orm.testutils
• server: depends on common; packages: rs, util (parts), util.persistence, and c3p0.properties
• client: depends on common; packages: client, util (parts)

With this setup a consumer would only need to depend on the client module and not all of the server implementation as well.

Mavenizing the DataProvider may also facilitate easier implementation of making DP GWT compatible [#11].

[Kevin Black]

DP [r351] [#18]: Updated project to a MVN web project w/ Eclipse support

This is a first step towards [#18].

Configured DataProvider as a MVN web project which caused various other
changes to occur in the Eclipse project settings, especially regarding
project preferences.

Updated web.xml from version 2.5 to version 3.0 to match the dynamic web
module project facet.

Corrected @Path parameter in DataProviderRS from "/" to "" so that the
container would be found by Jetty. I don't know why that worked or why
it was necessary but it worked as suggested at
http://stackoverflow.com/questions/18122336

Updated ResourceGroupType, ResourceType, and Resource JPA queries and
private no-arg constructors to pass JPA validation that was turned on as
part of the project reconfiguration.

[Kevin Black]

[r351] with the changes to pass JPA validation also seems to have made it so DataProviderClientTests all pass when run. Before, testGetRootResourcesWithGroupType failed.

[Kevin Black]

DP [r352] [#18]: Replaced binary libraries with maven dependencies.

Why?: An advantage of using maven dependencies instead of binary
libraries is that binary libraries do not have to stored in the version
control management system taking up space and being hard to diff.
Another advantage is that maven dependencies document their related
dependencies such that they can be retrieved automatically which removes
the burden of manual dependency management from the developer.

Replaced the following binary libraries with appropriate maven
dependency directives:

• antlr-2.7.6
  --- Dependency of hibernate-core.
• asm-3.1
  --- Dependency of cglib, a dependency of hibernate-entitymanager.
• c3p0-0.9.1
  --- Dependency of hibernate-c3p0.
• commons-collections-3.2.1
• commons-lang-2.6
• dom4j
  --- v1.6.1 dependency of hibernate-core.
• hibernate-jpa-2.0-api-1.0.0.Final
  --- Dependency of hibernate-core and other hibernate modules.
• hibernate-jpamodelgen-1.1.1.Final
• hibernate-validator-4.1.0.Final
• hibernate3
  --- Replaced with hibernate-core, hibernate-entitymanager, and
  hibernate-c3p0 all v3.6.4.Final
• jackson-annotation-2.0.4
• jackson-core-2.0.4
• jackson-databind-2.0.4
• jackson-dataformat-xml-2.0.4
• jackson-jaxrs-json-provider-2.0.5
• jackson-module-jaxb-annotations-2.0.4
• javassist
• jersey-bundle-1.4
• jsr311-api-1.1
  --- Now using v1.1.1 since maven's v1.1 didn't have the ApplicationPath
  annotation.
• postgresql-8.4-702.jdbc4
• slf4j-api-1.6.4
• slf4j-jdk14-1.6.4

Removed the following unused binary libraries:

• aopalliance
• commons-beanutils-1.8.3
• commons-email
• commons-fileupload-1.2.1
• commons-httpclient-3.1
• commons-io-1.4
• commons-logging-1.1.1
• dozer.osgi-5.2.0
• geronimo-jta_1.0.1B_spec-1.0.1
• json-20080701
• ws-commons-util-1.0.2

Updated the eclipse .classpath file to not require the binary libraries.

Updated persistence.xml to specify the persistence provider as
org.hibernate.ejb.HibernatePersistence which was necessary after
switching to the maven hibernate dependencies (I don't know why it
was not required before).

Corrected the testGetRootResourcesWithGroupType test in DataProvider-
ClientTests to do a set comparison instead of an ordered list
comparison.

Added messages to testResourceLinks tests in DataProviderClientTests to
try to determine why and when errors occur with this test. However,
after adding the messages I cannot get the error to occur (see [#19]).
I did add the testResourceRelinking tests to verify that the error
doesn't seem to be with relinking.

[Kevin Black]

DP [r353] [#18]: Initial split into modular maven project.

The modules are dataprovider-core, dataprovider-server, and
dataprovider-client.

The core project produces a jar artifact. For now it includes the java
packages: base, orm, orm.graphutils, util (all), and orm.testutils.

The server project produces a war artifact. It depends on the core
module. For now it includes just the rs package and c3p0.properties. It
includes the web.xml definition.

The client project produces a jar artifact. It depends on the core
module. For now it includes just the client package.

For now, the core module defines all of the external dependencies, both
common ones and web-specific ones.

[Kevin Black]

DP [r354] [#18]: Added the files that were not committed in r353.

This includes the web.xml and DataProviderClient.java files.

[Kevin Black]

DP [r355] [#18]: Moved Jackson dependency management to the core module.

[Kevin Black]

DP [r356] [#18]: Made smaller set of tests to validate the restful
service is properly initialized.

[Kevin Black]

DP [r357] [#18]: Moved dependencies from base project to core and
server modules.

[Kevin Black]

A further step not specified in the original spec is that the Resource modeling classes (Resource, ResourceGroupType, ResourceType) should be made interfaces and then there should be server and client implementations of the interface. The interface is what will likely make GWT compatibility possible.

[Kevin Black]

DP [r358] [#18]: Updated DataProvider version from 0.0.1 to 0.0.2.

[Kevin Black]

DP [r359] [#18]: Restored java files that had been lost in factoring
the project into maven modules.

The dataprovider-core and dataprovider-server java classes had been lost
in the refactoring but fortunately I had a local working copy still so
that I can restore them now. In future, don't use Eclipse's drag and
drop to move svn-controlled files around.

[Kevin Black]

DP [r360] [#18]: Breaking change. Working on subclassing Resource with
PersistetResource.

Updated ResourceTests to create PersistentResource where appropriate.
Changed the testLazyLoadSuperResources because PersistentResource now
annotated the getId property instead of the id field so the lazy loading
of super resources works differently now.

[Kevin Black]

DP [r361] [#18]: Working again. Updated necessary files to use
Persisten[t]Resource instead of Resource; now all tests pass.

Updated resource utilities and tests to do the following where necessary
to get the tests to run:

• create PersistentResource objects instead of Resource objects
• supply EntityManager find method with PersistentResource.class

Updated the persistent.xml file in dataprovider-server to reference
PersistentResource instead of Resource.