[kepler-users] New Kepler Repository

[HSU JIMS]

hi, all
I built Kepler using Eclipse last month, and I  re-checkout kepler now.
But the latest trunk seems that didn't use the configuration  on this
webpage:http://www.kepler-project.org/Wiki.jsp?page=UsingEclipseForKeplerDevelopment
(like .classpath, Run seeting,...)

So,anyone can help me how to configuration the new kepler trunk in  Eclipse ?

Thanks!!

Jims


> 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
>
>
>
> ------------------------------
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>
> End of Kepler-users Digest, Vol 43, Issue 4
> *******************************************
>