[kepler-dev] [kepler-users] New Kepler Repository
Christopher Brooks
cxh at eecs.berkeley.edu
Mon Dec 8 18:43:23 PST 2008
Hi Chad,
The new build looks pretty good! Congratulations. Below are some
minor nits. None of these require immediate action.
1) Checking out a separate ptII tree is great, but it means that the
user has no feedback about the files coming over the wire. The build
seems hung. Would it be possible to show the output of the svn
command that is checking out the ptII repository?
2) Minor white space problem. When I run ant, I get
-start--
[checkout-if-not-exists] set property ptIImod =
svn://source.eecs.berkeley.edu/chess/ptII/trunk
[checkout-if-not-exists] set property moduleName =ptII
--end--
Why does one line have a space after the = and the other line does not?
3) I'm using my own ptII tree, which I did with:
cd kepler/modules
ln -s ~/ptII .
When I run "ant" in the kepler/ directory, why are the doc files
copied:
--start--
prepare:
[copy] Copying 5459 files to
/Users/cxh/src/kepler/modules/ptII/build/doc/doc
--end--
Is there anyway to avoid this? This ends up taking a huge amount of
time.
I added <exclude name="doccheck/"/>
to avoid the doccheck output.
However, I don't understand why the codeDoc files are copied.
4) Why are these files copied?
[copy] Copying 1705 files to
/Users/cxh/src/kepler/modules/ptII/build/src
Every time there is a copy, there is wasted time and space. In
addition, there is the problem of being out of sync.
5) When building the ptolemy.jar file, why are these files copied?
jar:
[copy] Copying 2461 files to
/Users/cxh/src/kepler/modules/ptII/build/classes
Since we copied the sources, can't the .class files be put in the
right place?
6) What if I want to not build the ptolemy.jar file every time I
compile?
7) I ran "ant" and everything built, but there was no message about
what to do to run it. The build.xml file says "ant buildkarlib run"
With the old build, running just "ant" would show what options are
available.
8) Can someone update the version number on the splash screen from
1.0.0 to 1.1 or something? The new build system merits the version
change.
9) When I do "ant run", why are files recompiled?
getDependencies:
[echo] Building dependencies for kepler-core
[echo] Done with dependencies for kepler-core
[javac] Compiling 5 source files to
/Users/cxh/src/kepler/modules/core/build/classes
[javac] Note:
/Users/cxh/src/kepler/modules/core/src/exp/ptolemy/actor/lib/URLDirectoryReader.java
uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
10) Why is there a kepler/modules/ptolemy directory and a
kepler/modules/ptII directory?
11) Now might be a good time to fix up the indentation of the files
by running a tool like the Eclipse indenter. The files are pretty hard
to read. modules/util/src/org/kepler/gui/TabbedLibraryPane.java is an
example.
12) files like /modules/util/src/org/kepler/gui/LibraryPaneFactory.java
have bogus comments. The comment mentions TableauFactory, which is
probably the original source of this file:
//////////////////////////////////////////////////////////////////////////
//// TableauFactory
And, the authors are:
*@author Steve Neuendorffer and Edward A. Lee
These should be updated.
Again, congrats on a successful refactoring of the build system.
I now need to get going on the triquetrum refactoring, which should make
it easier to build Kepler by just including a small set of Ptolemy
modules.
_Christopher
Chad Berkley wrote:
> 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
--
Christopher Brooks (cxh at eecs berkeley edu) University of California
CHESS Executive Director US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718 (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480
More information about the Kepler-dev
mailing list