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

Shawn Bowers sbowers at ucdavis.edu
Sat May 16 08:56:19 PDT 2009


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
>


More information about the Kepler-dev mailing list