Re: Structure of the repository

Craig L Russell Tue, 11 Dec 2007 12:36:07 -0800

Hi Neeraj,

On Dec 11, 2007, at 7:41 AM, Neeraj Joshi wrote:

Perhaps a quick introduction to what we have in our CVS currently would

help you'all recommend what would be the optimal repository structure.

1. We have several eclipse projects in our current setup. They are as
follows:
   a. SPLCore - As the name suggests is the core SPL policy processor
   b. JavaSPLProvider - This is the Java binding for SPL
   c. CIMSPLProvider - This is a CIM binding for SPL that runs on the
OpenPegasus Server

d. CIMSPLClientSideProvider - This is another CIM binding for SPL that

runs independant for CIM servers
   e. SPLEditor - This is an eclipse based editor for SPL
   f. CIMSPLEditor - This is an editor extension for CIM
   g. JavaSPLEditor - This is an editor extension for Java

h. SPLCustomExpressions - This contains some sample custom expressions

(custom expressions is a way to extend the built-in set of SPL
expressions)
   i.  SPLDemo - A couple of samples

All of the above would be good candidates for a directory directly under trunk.

   j. ImperiusSite - The static HTML files for the website (under
construction)

Site might better live at the same level as trunk, as the site would have information that related to the project as a whole including multiple releases.


2. Each project has a
\bin - for generated binaries
\src - src folder

And within src, you might have java, conf, other src artifacts that aren't java.

\lib folders  - prereq libararies

It might be better to put dependencies in a more common area, to avoid unnecessary thrashing to update the same dependency in multiple sub-projects. Or worse, end up with different versions in different sub-projects.


Have you looked at Ivy or Maven for dependency management?

and build.xml

3. Currently we are using plain ANT.  A master build.xml drives builds
under each of the above listed projects

4. The generated targets are as follows:

a. JavaSPLProvider.zip - Contains the required jars and samples and some

scripts to run the samples
b. CIMSPLProvider.zip
c. CIMSPLClientSideProvider.zip
d. EclipseUpdateSite - That contains 2 features JavaSPLEditor and
CIMSPLEditor
e. SPLDemo - Contains the required jars and scripts to run the demo

So I guess we could put all the projects listed under 1. under the trunk

and at the same time have them under a release branch marked 1.0 or
something?

During development, everything is under trunk. When ready for release, copy the trunk to a branch and finalize the release. When approved, copy the branch to a tag.


Some of the mechanics of release are done more easily if you use Maven.

Another issue to discuss is what would be our release process - how to
determine schedule, what criterion to use to promote a build to a release
build etc

All good questions. Take a look at the openjpa project as an example of a release process including branching and tagging.


Craig


Suggestions? comments?
Thanks
Neeraj


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"'In the end, everything is fine. If it is not, it is not the end"
Neeraj Joshi
Autonomic Policy Development
Autonomic Computing Division
(919)543-5298
TIE: 441-5298
Ext: 3-5298
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Craig L Russell <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
12/10/2007 02:29 PM
Please respond to
[email protected]


To
[email protected]
cc

Subject
Structure of the repository






Now would be a great time to discuss the structure of the repository.

Under the root (incubator/imperius) we currently have only board.

What most projects do is to add a trunk for current (possibly broken
in small ways) development, branches for maintained branches as well
as multi-developer features that are too incomplete for the trunk,
and tags for released code.

Under trunk, complex projects with multiple jar files often have
several sub-projects, each of which has a structure suitable for the
build/integration tool. For example, openjpa uses maven to build and
has openjpa/trunk/openjpa-jdbc/ in which you find src and target
directories and the pom.xml that defines the openjpa-jdbc sub-project.

Some also have their site as a directory in the main repository.
Others use Confluence and publish directly to the web.

Craig

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!


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

Re: Structure of the repository

Reply via email to