[kepler-dev] Hiding port names

[Dan Higgins]

Edward,
    I just checked out a new version of the head of the PTII CVS tree, 
updated my KEPLER module and then executed

ant ptolemy

from the $KEPLER directory. The compile work fine (Windows machine) and 
the compiled code is put in the file 'ptolemy.jar'. I then executed

ant run

and KEPLER comes up OK for me. (Both the PTII and KEPLER environment 
variable are set.)

I don't know why you would have a problem unless you inadvertently used 
the ant build file that is in PTII. I think this is an older file that 
doesn't work properly. As I said, the build file in KEPLER works for me 
but it is missing some features (like building javadoc files) and some 
PT features (e.g. Java 3D checks) are skipped.

I also did this on a Linux box a few days ago with no problem.

Dan Higgins
NCEAS

Edward A Lee wrote:

> At 08:09 AM 7/26/2004 -0800, Matt Jones wrote:
>
>> Yeah, we fully intend to support the CVS HEAD for PTII in our kepler 
>> builds, as it seems like the only way to really keep synchronized.  
>> Over the last week several of us have been building against the CVS 
>> head, with mixed results.  Sometimes it works, sometimes 
>> not...haven't yet figured out the differences among these builds yet 
>> that cause the failures.  We'll get the issues worked out fully and 
>> then post instructions on the web site.  It should be as simple as 
>> checking out the two trees, set 2 env vars, then run 'ant ptolemy 
>> run'.  I think the problems we are hitting are due to us not encoding 
>> in our ant build some of the dependencies that you cover in your 
>> makefiles.
>
>
> I doubt this... We do builds with Eclipse, which don't use
> the makefile dependencies either...
>
> Ideally, I would like to be able to have Kepler and Ptolemy II as
> two Eclipse projects, and not use either ant or make... But this
> is a personal preference.
>
> I think it would be very helpful if some of us would routinely
> build the kepler tree against our current repository... This way,
> we could check for problems before checking in major changes to
> our tree...
>
> However, I still can't get the ant build to yield an executable
> kepler... Any ideas about the problem I reported?  I suspect a classpath
> problem, but I haven't been able to figure it out...
>
>
>> In addition, we need a way to try to incorporate Kepler changes into 
>> the PTII tree.  We are working on a variety of changes relating to 
>> data access and semantic typing, and several of these require UI 
>> changes in vergil.  We have been developing them using the ptolemy 
>> extension mechanism through the configuration, so they could be used 
>> or not depending on how the configuration is set up.  But there are 
>> many areas of vergil which are not configurable, and so we are 
>> extending those areas to be configurable where needed.  Ultimately, 
>> we need to contribute this code to PTII through the code review 
>> process -- I think the easiest way to do this is to have a couple of 
>> Kepler developers who have write access to the PTII CVS tree and can 
>> contribute code after consultation with PTII developers (like 
>> Christopher and yourself).
>
>
> This sounds like the right approach...
>
>
>> In many ways I would prefer to not have to maintain two separate CVS 
>> trees at all, but I currently don't see a good way to do this because 
>> we want the Kepler project to be fully open to a variety of 
>> contributors, while the PTII tree is really reserved for the Berkeley 
>> Ptolemy project.  But it would be nice to use just a single 
>> integrated tree.  I would be interested in chatting with you about 
>> whether you could see the two projects really sharing a cvs tree or 
>> not, given the project management implications this would have.
>
>
> In practice, we have a fairly informal mechanism where people
> with access to the tree self-regulate.  Those with less experience,
> for example, don't check in changes to the kernel package without
> running them by others.  Moreover, we have regions of the tree
> where "anything goes" (at one extreme, we
> have an "apps" directory containing
> unproven and sometimes very rough projects).
>
> I could see this mechanism extending to a larger group...
>
> Edward
>
>
> ------------
> Edward A. Lee, Professor
> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0455, fax: 510-642-2739
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev