[kepler-dev] Add depency in build.xml?
Edward A Lee
eal at eecs.berkeley.edu
Thu Mar 25 12:59:20 PST 2004
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
More information about the Kepler-dev
mailing list