[kepler-dev] Add depency in build.xml?
Christopher Hylands Brooks
cxh at eecs.berkeley.edu
Wed Mar 31 10:38:25 PST 2004
Sorry for the delay, last week was Spring Break and I was on vacation.
The idea of having a KEPLER_BUILD_BASE tag is a good one. I have not
tried moving cvs tags, so I'll have to see if that can be made to
work.
Edward and I discussed having tests automatically tag the code if
the tests in kernel, data, moml and actor passed.
Our plan is to release Ptolemy II 4.0 on April 26. My guess is that
it will be a beta release, with docs to follow about a month later.
The upshot is that I don't know if I have time to set up an automated
test based tagging system before then.
Another issue is that having all Kepler developers have access to the
Ptolemy II development CVS repository represents a big change for us.
In the past, we have granted CVS access on an individual basis, and
not automatically to an entire group.
It is up to Professor Lee as to whether we open up our CVS repository
further.
My primary issue is that I'm concerned about the stability of the
release, most days the build completes without errors, but there are
always test failures. I don't want offsite developers to suffer from
the wild swings of our development process.
If we tag the tree with a STABLE tag, then this issue will be
addressed.
Another issue is that I don't have much time to spend massaging the
tree. Each day I spend 30 minutes to an hour fixing nightly build
issues. I'm loath to add to this burden. If I can get the automatic
tagging to work, then this would help.
A big issue is that Edward is about to check in a bunch of changes
to the kernel that could affect Kepler. It would be good if
we could get moving on this sooner rather than later.
The build failed last night (my fault). I checked in a fix and I'm
rerunning the build and tests. I can see about tagging the release
sometime today or tomorrow.
-Christopher
--------
I think that's a good idea. Right now the current Kepler build does not
work with the HEAD of the Ptolemy CVS tree, but Efrat aid on IRC the
other day that she is working on getting the problems worked out. Right
Efrat? Once it builds against the HEAD, I think that it would be good
to start our build off of the Ptolemy tree CVS, rather than ptII3.0.2 as
we currently are doing. Of course, this depends on the HEAD of the tree
being relatively robust.
And it also has implications for when we can release versions of Kepler.
I assume that you wouldn't want us to release Kepler with any Ptolemy
code that hasn't been released in Ptolemy. So....maybe we could create
a tag in the Ptolemy tree (e.g., KEPLER_BUILD_BASE) that we would check
out and build against. When code in the Ptolemy tree stabilizes and is
releasable by Kepler, we would either move the tag or create a new tag
against which we would be building.
If we did it this way, we could probably stay much more closely
synchronized with the changes in the Ptolemy tree, and it would be
automated as part of the ant build.
Thoughts,
Matt
Edward A Lee wrote:
>
> Perhaps we should do something similar with the Ptolemy core code
> also... I.e., integrate it into the CVS tree of a Kepler checkout
> by somehow performing the checkout from a read-only account on the
> Ptolemy server
> (write access could also be granted selectively).
>
> Christopher?
>
> Edward
>
> At 09:46 AM 3/25/2004 -0900, Matt Jones wrote:
>
>> I guess the problem comes down to this: where should code live that is
>> re-used inmultiple projects. For many external projects, we make a
>> copy because we have no access to the CVS servers. But for this
>> EcoGrid client code, it is part of one of the sponsoring projects for
>> Kepler, and the same people contributing the code for EcoGrid are
>> integrating it into Kepler. In this situation, code duplication seems
>> like it will complicate maintenance tremendously (from our experience,
>> its a huge time sink to duplicate code). Given that Ant supports CVS
>> checkouts, its easy to build the dependencies directly into the build,
>> and thereby eliminate a lot of maintenance headaches.
>>
>> In terms of shipping a release of Kepler, I think that release should
>> include all of the code on which Kepler depends and that we control,
>> so we'll just have to make the dist target build a release package
>> that includes the relevant code. Again, this shouldn't be hard.
>>
>> Matt
>>
>> David Buttler wrote:
>>
>>> I will just note that this will complicate any type of source
>>> distribution for Kepler. Either it will need to contain SEEK, or the
>>> build file will have to be modified to exclude Jing's functionality.
>>> I am not sure if this will turn out to be a problem, as I do not see
>>> how separate SEEK and Kepler are.
>>> Matt, are the JUnit tests you are referring to in SEEK or in Kepler?
>>> Thanks,
>>> Dave
>>> Matt Jones wrote:
>>>
>>>> Jing,
>>>>
>>>> Ant has the ability to prompt for input. Matthew has used this
>>>> feature in the JUnit tests in utilities -- check that for an example.
>>>> So you should be able to construct the CVSROOT from a userid that
>>>> you either get from user input or from the environment (for example,
>>>> from $USER or $CVSROOT environment vars). That way the developer
>>>> does not have to edit build.xml, and the account will change to the
>>>> right CVS account.
>>>>
>>>> As to whether or not we should include the checkout in the build
>>>> process, I think we should. Everyone that has CVS access to kepler
>>>> has CVS access to seek, and the costs of duplicating code and having
>>>> it be out of date is high. THat is why we have the development
>>>> guideline in the Kepler development guidelines:
>>>> 4. Try to not check in files that can be generated from the build
>>>> system
>>>>
>>>> I think your approach follows this guideline well.
>>>>
>>>> Matt
>>>>
>>>> Jing Tao wrote:
>>>>
>>>>> Hi, Dave:
>>>>>
>>>>> No, you don't need to my username and password. But user should
>>>>> customize the build.xml before running kepler(it is a pain:)). In
>>>>> the init target, there is property named cvs.root and current
>>>>> value is :ext:tao at cvs.ecoinformatics.org:/cvs. Users can change the
>>>>> value and use their own username and password. For example, if a
>>>>> username is "foo", he needs to change the value to
>>>>> ":ext:foo at cvs.ecoinformatics.org:/cvs".
>>>>>
>>>>> The reseaon why we add this cvs.root property is we don't want to
>>>>> duplicate code. The alternative way is adding ecogrid jar files
>>>>> directly to kepler/lib/jar dir. This way would not cause this issue
>>>>> (needing customize build.xml), but the code will be duplicated to
>>>>> seek/project/ecogrid module.
>>>>>
>>>>> Your suggestion for asking username and password is good. But I
>>>>> have no idea how ant can do that. Does anyone have some suggestions?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jing
>>>>>
>>>>> On Wed, 24 Mar 2004, David Buttler wrote:
>>>>>
>>>>>
>>>>>> Hi Jing,
>>>>>> I looked at the CVS diff of the build.xml file you just updated
>>>>>> and I have a question:
>>>>>> it looks like you have modified the general compile target so that
>>>>>> it requires your package, but in the build file you also added a
>>>>>> CVS target that would check it out from the repository under your
>>>>>> username, requesting the password from the builder at compile time.
>>>>>> Does this mean that I need your password in order to compile
>>>>>> kepler now?
>>>>>> There has to be a better way to manage this; at the very least ask
>>>>>> for username and password, rather than hard coding your username
>>>>>> into the build file. Does anyone else have other suggestions?
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> Jing Tao wrote:
>>>>>>
>>>>>>
>>>>>>> Hi, everyone:
>>>>>>>
>>>>>>> My kepler code will need the some jar files (about 6) in lib when
>>>>>>> it communicates to ecogrid service. Those jar files come from
>>>>>>> ecogrid client library in seek/ecogrid project.
>>>>>>>
>>>>>>> Now I have a question: do I need add those jar file direclty to
>>>>>>> kepler cvs or add adependency on seek/ecogrid project in
>>>>>>> build.xml(add a target in kepler build.xml and this target will
>>>>>>> create those jar files then copy them to kepler/lib/jar)?
>>>>>>> The first one is easiest one but duplicate code. The second one
>>>>>>> doesn't duplicate the codes, but make user to run kepler should
>>>>>>> checkout seek module first(it is pain too).
>>>>>>>
>>>>>>> Any idea or suggestions?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Jing
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>
>> --
>> -------------------------------------------------------------------
>> Matt Jones jones at nceas.ucsb.edu
>> http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
>> National Center for Ecological Analysis and Synthesis (NCEAS)
>> University of California Santa Barbara
>> Interested in ecological informatics? http://www.ecoinformatics.org
>> -------------------------------------------------------------------
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>
> ------------
> 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
--
-------------------------------------------------------------------
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------
--------
More information about the Kepler-dev
mailing list