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

[Matt Jones]

Jing, how about this: have a dependency check to see if CVSROOT is set 
already in the environemnt.  If not, prompt the user for a userid and 
set up the CVSROOT var in the environment.  THen, later, use this var 
for the input to the checkout.  Under this scenario, the developer only 
has to provide the info once per terminal session, and not at all if 
they have CVSROOT set.

Matt

Jing Tao wrote:
> 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).
> 
> Jing 
> 
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
> 

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