[kepler-dev] Proposal: Kepler should work off a snapshot or release of Ptolemy instead of the trunk of Ptolemy

[Christopher Brooks]

Hi Shawn,
Yep, I agree that build time has increased with ant.  Eclipse keeps the
system compiled, so this is less of an issue there.

In the longer term, I hope to break Ptolemy II down in to smaller
modules so that it is possible for Kepler to use a more minimal set
of packages.  This work is a ways away though, the Ptolemy II 8.0
release is first, and then there are optimizations needed for a sponsor.

_Christopher

Shawn Bowers wrote:
> One issue with some of the recent changes of including a larger set of
> ptolemy classes and building directly against the trunk of ptolemy in
> this way is the amount of time it takes to compile Kepler, even when
> the ptolemy classes have already been compiled and only one class has
> changed in the kepler source (or in a module). It takes close to 20
> seconds on my new mac book for java/ant to check whether any of the
> ptolemy classes have been modifed, whereas the remaining compilation
> process is very quick.  This significantly increases compilation time,
> and reduces productivity (IMHO).
> 
> Shawn
> 
> On Fri, May 15, 2009 at 11:23 AM, Chad Berkley <berkley at nceas.ucsb.edu> wrote:
>> IMHO, the trunk of Kepler should always be built against the trunk of PTII.
>>  If this does not happen, we get out of date really quickly and it takes
>> more work to address multiple incompatibilities than if we just figure out
>> and fix them as they come up.  These problems happen so infrequently, that,
>> even if they take a moderate amount of time to debug, it's not like it
>> happens on a daily, weekly or even monthly basis.  I think I can count on
>> one hand the number of times it's happened in the last year.
>>
>> With the module system, it seems to me that anyone is free to use a snapshot
>> of ptII by creating their own suite that depends on a branch or tag.  I
>> don't see any reason to force the trunk development to use a snapshot of
>> ptII.  After 2.0 is released, module developers can base their work on it if
>> they don't want to use the trunk.
>>
>> chad
>>
>>
>> Matt Jones wrote:
>>> Yeah, I agree that there is a problem until we get a stable release
>>> out with modules released to develop against.  I think getting help to
>>> resolve problems is fine.  I would support an interim approach that
>>> helps to bridge the gap while we transition into the released modules
>>> scenario. Not quite sure what that would be though...
>>>
>>> Matt
>>>
>>> On Thu, May 14, 2009 at 3:50 PM, Timothy McPhillips <tmcphillips at mac.com>
>>> wrote:
>>>> HI Matt,
>>>> In the meantime, I wonder what people (like me) should be building
>>>> against
>>>> when developing modules (like comad) we hope to have work with Kepler
>>>> 2.0?
>>>>  Until there is a better way, I'm going to keep working at the trunk (of
>>>> both) and asking questions on irc when things don't work, which means
>>>> others
>>>> are going to spend considerable time tracking down these issues.
>>>>
>>>> Cheers,
>>>>
>>>> Tim
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

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