[kepler-dev] kepler build broken due to changes with ptolemy's port and relation getWidth() function
David Welker
david.v.welker at gmail.com
Mon Nov 3 09:06:48 PST 2008
Hi Tristan,
I just thought I would point out, it is not actually necessary to work
from the trunk of Kepler. In fact, I wouldn't recommend it unless you
are actually doing work directly on the trunk.
As you may already be aware, I have developed a new build system. It
easily allows you to work from either the 1.0 release of Kepler or the
trunk. If you are inclined, feel free to check it out.
https://dev.kepler-project.org/developers/teams/build/documentation/the-new-build-system/?searchterm=instructions%20build%20system
With respect to the new build system, there is the 1.0 branch, and the
1.1 branch. The 1.0 branch is fairly stable. I plan on only doing bug
fixes and minor changes here. The 1.1 branch is more cutting edge -- it
is also less stable and less documented.
The 1.1 branch is nice, because it actually uses jars of Kepler and
Ptolemy when you are working off the 1.0 release. This means there is no
risk of the code you rely on changing underneath you, no worries about
synchronization issues between Kepler and Ptolemy, no need to compile
either Kepler or Ptolemy, and finally, faster downloads of both Kepler
and Ptolemy.
If I try to go from nothing to a working set of Kepler and Ptolemy
environment, it usually takes me about 3-4 minutes using wireless off
the very fast network connection we have here at UC Davis. So its pretty
fast.
I should also note that the build system generates project files for
three major IDEs, including Eclipse, Netbeans, and Intellij IDEA. There
is much less need for particular configuration of these generated
project files than previously.
Anyway, I am not sure how you plan on working, but I thought I would let
you know about the new build system in case you were not already aware.
David
> Hi Tristan,
> Sorry about the lossage, it looks like the Kepler automatic build is
> erroneously reporting that the build works properly.
>
> I started fixing build problems, but I'm not sure how many problems
> there are. My write access to the kepler tree seems to be disabled, so
> I can't check in my changes right now. It could be something simple
> on my end.
>
> I've cc'd Bert Rodiers, who is responsible for the width inference work.
> The width inference work is important because it fixes a long standing
> usability issue surround multiport composite actors.
>
> Bert, could you check out the svn head Kepler head and build it against
> the latest ptII head and get a sense of how many changes are required
> to update Kepler? The instructions are at
> http://www.kepler-project.org/Wiki.jsp?page=DevelopmentForKepler
> I suggest building with Eclipse even though building with Eclipse is
> somewhat complex as the Eclipse build will tell you the total number of
> errors, but "ant -k run-dev" halts at the first error.
>
> Also, can someone look at the Kepler automatic build and see why it
> is not reporting failures like:
> compile-dev:
> [javac] Compiling 972 source files to
> c:\tmp\cxh\src\kepler\build\classes
> [javac]
> c:\tmp\cxh\src\kepler\build\src\org\ecoinformatics\seek\gis\gdal\GDALTranslateActor.java:131:
> unre
> ported exception ptolemy.kernel.util.IllegalActionException; must be
> caught or declared to be thrown
> [javac] "input width was" + inputFilename.getWidth());
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
>
> _Christopher
>
> Tristan King wrote:
>> I reverted both kepler and ptolemy back to the day before the change
>> to ptolemy (which from the logs seems to be the 20th of Nov). I tried
>> to just put ptolemy back to that date, but there seems to be other
>> changes to kepler that depend on future ptolemy code.
>>
>> so from the command line i did:
>>
>> cd $PTII && svn switch
>> svn+ssh://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk
>> <http://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk> -r
>> {2008-10-20}
>>
>> which resulted in ptolemy revision 50844. Then:
>>
>> cd $KEPLER && svn switch
>> https://code.kepler-project.org/code/kepler/trunk -r {2008-10-20}
>>
>> which gave kepler revision 8114. After that "ant full-clean ptolemy
>> jar" finished succsessfully.
>>
>> The kepler/ptolemy guys may be able to find more recent revisions
>> that work, I've wasted too much of the day playing with this already
>> and need to get onto some real work :).
>>
>> Hope this helps
>> -Tristan
>>
>> On Mon, Nov 3, 2008 at 2:06 PM, <Peter.Fitch at csiro.au> wrote:
>>
>> Hi Tristan,
>>
>> Good to know. Do you know which versions of kepler and ptolemy
>> currently compile?
>>
>> Cheers
>> Peter
>>
>>
>> On 3/11/08 2:48 PM, "Tristan King" <tristan.king at jcu.edu.au
>> <mailto:tristan.king at jcu.edu.au>> wrote:
>>
>> Hi all,
>>
>> Just thought i'd let everyone know that kepler no longer compiles
>> against the current trunk of ptolemy.
>>
>> I think this brings up a bit of an issue. Is the plan with the
>> kepler trunk to always compile against the ptolemy trunk? If not,
>> then the INSTALL.TXT file should probably be updated to specify the
>> revision to use, or maybe ptolemy should be pulled down by svn
>> external when pulling down kepler (I think this may have been
>> discussed tho, and was decided to not be a good idea, I don't
>> remember why). an svn external would make sure every kepler
>> developer is working with the same revision of ptolemy, and since
>> you can specify a specific revision for the external, someone could
>> be responsible for integration of new ptolemy revisions into kepler
>> and avoid problems like this one.
>>
>> Peter Fitch
>> Group Leader, Predicting and Reporting Technologies
>> CSIRO Land and Water
>>
>> Clunies Ross Street
>> Black Mountain ACT.
>>
>> Telephone: +61 (0)2 6246 5763
>> Facsimile: +61 (0)2 6246 5800
>>
>>
>>
>>
>> --
>> Tristan King
>> Research Officer,
>> eResearch Centre
>> James Cook University, Townsville Qld 4811
>> Australia
>>
>> Phone: +61747816902
>> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au> www:
>> http://eresearch.jcu.edu.au
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
More information about the Kepler-dev
mailing list