[kepler-dev] [kepler-users] New Kepler Repository
Chad Berkley
berkley at nceas.ucsb.edu
Tue Dec 9 10:13:42 PST 2008
Hey Christopher,
Thanks for your thorough critique. See my comments below:
Christopher Brooks wrote:
> 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?
Yeah, Ant does not yet support SVN natively, so I have to use the svnant
plugin from eclipse. I'll see if I can coax some more output from it.
It is annoying that there is no indication of activity.
>
> 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?
I'll fix it. Typo.
>
> 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.
Changing the ptII build is still on my list of stuff to do. It's still
using the old build-ptolemy.xml file to build it. Once I get some of
this other stuff worked out, including the eclipse build, I'll get the
ptII build optimized.
>
>
> 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.
>
See 3)
>
> 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?
See 3)
>
> 6) What if I want to not build the ptolemy.jar file every time I
> compile?
I fixed this yesterday. It should now build just the ptII source and
not jar it.
>
> 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.
I need to set the default task. I'll do that today. I used the 'ant
-projecthelp' functionality for setting the help info.
>
> 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.
We haven't released anything, so I'm not sure what the version would be.
I could change it to be "1.x developers version" or something.
>
> 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.
>
I fixed this yesterday. It was because the ptolemy files were in the
'exp' directory. They no longer are. My ambitious goal is to get rid
of the exp files by the time I go on leave.
> 10) Why is there a kepler/modules/ptolemy directory and a
> kepler/modules/ptII directory?
Because ptII does not have the same directory structure that the rest of
the modules have, I've made a dummy module that directs the building of
ptII. It just allows the flexibility to build ptII the way it needs to
be built without forcing our structure on you. If you look at the
module.properties file for util or core, you'll see they both depend on
'ptolemy'. When the build gets to that dependency, it uses the build
file in the ptolemy module to build ptII. Right now it just calls
build-ptolemy.xml but that will change.
>
> 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.
My style or yours :) I think we've had this discussion a few times.
While I'm all for having a uniformly styled code base, I also hate
working with other peoples' styles. I know that I learned in CS101 that
I need to just deal with it or talk to a psychologist about it or
something, but I still feel like it hampers my productivity when I have
to use a style that doesn't jive with the way I write code. The rule
that we've had for a long time is that the file should be styled in the
author's format and that it should stay that way. If there is a file
that is not formatted at all, or does not follow any style guidelines
(i.e. lines of the same block are not indented to the same tab point,
etc) then I have no problem reformatting them.
>
> 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.
Like I said before, hopefully all of the exp files will go away in the
next few weeks. When I merge the changes back into the ptII tree I will
make sure they are styled to meet your guidelines and I will update the
documentation.
>
>
>
> 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.
Great! Looking forward to it. Let me know if you find any other
issues. I really appreciate the feedback.
chad
>
> _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
>
More information about the Kepler-dev
mailing list