[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).
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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>
--
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