incubator-imperius-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Structure of the repository
Date Tue, 11 Dec 2007 20:35:33 GMT
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 <Craig.Russell@Sun.COM>
> Sent by: Craig.Russell@Sun.COM
> 12/10/2007 02:29 PM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> imperius-dev@incubator.apache.org
> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

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


Mime
View raw message