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 > ******************************************* >
