You are viewing a plain text version of this content. The canonical link for it is here.
Posted to imperius-dev@incubator.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/12/10 19:29:59 UTC
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!
Re: Structure of the repository
Posted by Kevan Miller <ke...@gmail.com>.
Looks like I agree with all of Craig's comments. You'll definitely
want to look at a dependency management build system. I've never used
Ivy. If you're willing to follow the maven-way, then it works pretty
well and simplifies many tasks...
On Dec 11, 2007, at 3:35 PM, Craig L Russell wrote:
> Hi Neeraj,
>
> On Dec 11, 2007, at 7:41 AM, Neeraj Joshi wrote:
>
<snip>
>
>> 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.
There are release mechanics (copying to a branch, voting, tagging,
deploying artifacts, etc), which can be spelled out pretty explicitly.
Then there are more organic processes (e.g. determining release
content). The key to these are discussion via this dev list.
You'll need to lay out goals for the project and where you want the
project to end up (this can/will change over time). From this you can
start to define logically consistent release checkpoints along the
way. Important point in all of this is open communications. This is
also very important in helping to attract new contributors to the
project.
Scheduling of releases is hard. Creating target dates is useful in
focusing energies and prioritizing. However, schedules should be
secondary to working within the community and delivering function.
You can assume that the release process will take *much* longer than
you think it will. Getting the source code and release artifacts to
meet Apache standards will take significant time. The project and
incubator voting process can also be slow... Patience is a virtue... ;-)
--kevan
Re: Structure of the repository
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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!
Re: Structure of the repository
Posted by Neeraj Joshi <jn...@us.ibm.com>.
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
j. ImperiusSite - The static HTML files for the website (under
construction)
2. Each project has a
\bin - for generated binaries
\src - src folder
\lib folders - prereq libararies
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?
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
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 <Cr...@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!