[kepler-dev] New Kepler Repository

[Chad Berkley]

Hi,

The new Kepler repository is now in place.  You can checkout the trunk 
from https://code.kepler-project.org/code/kepler/trunk.  I want to 
highlight the changes we've made.  If anyone has any questions or 
problems, please feel free to respond to the list and we'll get things 
sorted out as quickly as possible.  This is a huge change for us that we 
hope will make developing with Kepler much easier in the future.  Please 
be patient with us as we continue to find and fix bugs in the coming 
weeks.  Please note that everyone *MUST* re-checkout kepler.  Do not use 
your old sandbox.  It will not work.

Here are the major changes that we've made:

1) Modularization: Kepler is now divided into a series of modules. 
You'll notice the root src/ directory is now gone.  It is replaced by 
two modules in the modules/ directory, 'util' and 'core'.  Core contains 
everything needed to run Kepler in a headless environment. Util contains 
everything else that used to be in the src/ directory.  You'll notice 
that within each module, there is a specific directory structure 
consisting of the src/, module-info/, lib/ and other directories.  Each 
module can also contain its own build.xml file for local building (see 
"build system" below).

Each module contains it's own source and it's own dependency jars.  Jars 
that are common to more than one module are in the "common" module. 
Modules can depend on each other and dependencies are listed in the 
module-info directory.

In the next month or so, the 'util' module will be broken up further 
into other modules based on functional requirements.  For instance, 
there will be a 'gui' module to house all of the required source for the 
gui components of Kepler.  The current structure is a jumping off point 
for further changes that will make it easier to develop for and extend 
Kepler in meaningful ways.

2) Build system: There are currently two ways to build Kepler.  If you 
are (or have been) doing development in the main src tree of kepler 
(i.e. what is now modules/core/src or modules/util/src), you can use the 
new ant build.xml file that is found at the root of the trunk.  The 
build for the core has been simplified so that there are only two 
commands required to build Kepler and you no longer have to set the PTII 
or KEPLER environment variables.  See the notes in the top of the build 
file for instructions on building and running the core.  There is also 
more information here:
https://dev.kepler-project.org/developers/teams/build/systems/build-system/core-build-system-howto

The second way to build Kepler with with the extension build system 
developed by the folks at UC Davis.  If you have been using that build 
system, David has modified it to work with the new directory structure. 
  You can check it out from 
https://code.kepler-project.org/code/kepler/kepler.build
Note that the directories in all existing modules have been changed so 
that they no longer use the Maven standard of main/java inside the src 
directory.  David can answer any questions about using the extension 
build system with the new repository structure.

3) Branches/tags renaming and standardization
In the old repository, each module had its own branches, tags and trunk 
directory.  We have now moved those directories to a higher level so 
that all branches or tags of modules will go in the high level branches 
or tags directories.  Because we foresee large numbers of branches and 
tags, we have implemented a standard naming convention that will be 
used.  The naming convention is as follows:

Branches:
<description>-['release']-[version]-branch
where 'release' and version are optional  and are used only for releases 
or versioned branches.  In the case of general Kepler releases, the 
description is optional.
Some examples are:
kepler-osgi-bunles-branch
release-1.0.0-branch
scia-release-1.0-branch

Tags:
<description>-tag-['release' | 'checkpoint']
where 'release' or 'checkpoint' denotes what kind of tag this is.  A 
checkpoint tag is one that can be used by a developer simply to create a 
checkpoint in the code base in case he or she wishes to return to that 
state.  The 'release' tag is for releases only and denotes some public 
release of Kepler.
Some examples are:
kepler-1.0.0-tag-release
leinfelder-20070924-tag-checkpoint

All of the superfluous and old tags and branches have been removed for 
readability.  The ones that remain have been renamed.


Future work:

-The build systems will eventually be merged into one.
-further modularization of the core
-build tools for creating skeleton modules and actors
-division of actors into functional group modules
-further clean up the trunk directory


I hope that I haven't neglected anything.  This has been a large effort 
over the last month or more, so there are bound to be some small 
problems cropping up.  Please feel free to contact us on kepler-dev if 
you have any questions or concerns.

Thanks,
chad