[kepler-dev] Add depency in build.xml?

Jing Tao tao at nceas.ucsb.edu
Thu Mar 25 09:52:10 PST 2004

Hi, Matt et al:

Thanks for the information. 

So now we have two solutions: one is setup CVSROOT environment variable( I 
think linux user already did that, but window's user didn't). The other is 
everytime when we build kepler, we need input a the cvs username.

Please vote which one you prefer to :)

I prefer the first one. It is more convenient(only setup once).


On Thu, 25 Mar 2004, 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
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>
> > 

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

More information about the Kepler-dev mailing list