Re: Proposal for a 'contrib' space in openjpa repository

[Craig L Russell]

On Dec 22, 2007, at 6:56 AM, Patrick Linskey wrote:

c) A non-committer should be able to contribute to the 'contrib' space

I'm not sure about Apache policy, but I think that this might be a problem.

% cd openjpa/trunk/extensions
trunk/extensions % ls
pom.xml
db4o



trunk/extensions % ls
pom.xml
db4o
loosely-typed



Craig

We can use the existing policy to cover this case. As long as a contributor signs the ICLA and uploads the contribution via our normal JIRA patch process, and a committer reviews and commits the contribution, it's ok. What's not obvious to me is how to package and build the extensions. We might want to set up a new directory in the top level that contains a number of self-contained maven projects, each of which builds a jar. We can probably create a maven archetype specifically for this purpose, and put the archetype definition into the new directory. trunk/extensions % mvn archetype:create - DgroupId=org.apache.openjpa.extensions -DartifactId=loosely-typed - DarchetypeArtifactId=openjpa-extensions We need to think carefully about what to call these extensions, so it's clear that they're not supported, endorsed, built, or distributed by the project. But in future, we might want to build and distribute them if they turn out to be useful. But at that point, we might promote them to their own endorsed sub-project (e.g. trunk/ openjpa-db4o).

-Patrick

On Dec 17, 2007 8:23 PM, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

Hi,

purposes such as non-relational datastores, customized mapping
strategies support for loosely-typed data structures etc.

here is a proposal:
a) A 'contrib' space should be created in OpenJPA SVN repository for
sharing any such contributions with the community.
b) The entires in the 'contrib' space should neither imapct the build
process or nor be a part of the distribution package. However, the

core openjpa downloads.


d) the contributions must adhere to the coding conventions and other
software conventions followd by OpenJPA

  Regards --

Pinaki

OpenJPA architecture allows extensible feature derivations for various To promote contributions from wider community of users and developers, entries must be available with requisite artifacts (e.g. source, build script, docs) for interested parties to build the extension and use with c) A non-committer should be able to contribute to the 'contrib' space Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature