> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> > OK, how is the code suppose to know if something has to be
> > resolved based on the local basedir or the global one?
>
> IMO:
> - default = resolve based on the local basedir ( so all
> existing build.xml
> can be imported and will behave as expected )
> - explicit override = an attribute to import that allows you
> to override
> the basedir.
>
What happens when I need things like xslt files to be found relative to
the imported project, but I need other files of the actual build to
be relative to the global build (like the builddir to use).
My point is that things are not that simple, it is not an all or nothing
situation, you will have to be able to pick and choose because some files
depend on the static layout of the project and other depend on the
dynamic dependencies make by the imports.
> In all projects that I know, the basedir is used to resolve
> files relative
> to the location of the build file - and I think the default
> should reflect
> that.
>
So why do we allow basedir to be changed using -Dbasedir=xxx
or using <ant dir="xxx" file="somelocalfile"/>
Or am I mistaken such functionality is there? How would that affect
the behaviour of import? Things need to be consistent.
Following your line of thought, are you advocating for each task or target
to actually remember from which buildfile it came from? Even if they are
called using <antcall> from some other target coming from somewhere else?
Jose Alberto
>
> >
> > How does the user makes certain the correct choices are being taken?
> > What happens if I do:
> >
> > ant -f build.xml -Dbasedir=mynewdir
> >
> > would this affect only build.xml or also the imported buildfiles?
> >
> > With respect to XSLT, the correct comparison is with the use of
> > the document() function and in that case you have to pass as part of
> > the call a parameter used to indicate which base to use
> when resolving
> > the filename of the document.
> >
> > In other words we need to be able to say ${basedir}/a/b
> meaning the local
> > ${basedir} and to say ${basedir}/a/b meaning the global basedir AND
> > ${basedir}/a/b meaning the ${basedir} of some other
> imported file (there
> > is no reason why the imported cannot access thing from the imported
> > projects). This is why ${basedir.projname} is needed.
> >
> > Of course, if for every file we need to write fullpaths
> then the whole
> > purpose of the resolvers is kind of defeated.
> >
> > Jose Alberto
> >
> >> -----Original Message-----
> >> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> >> Sent: 09 January 2003 15:34
> >> To: [EMAIL PROTECTED]
> >> Subject: RE: Improt task and project basedir
> >>
> >>
> >> Jose Alberto Fernandez wrote:
> >>
> >> >> To solve the problem we could add a importable="true"
> >> >> attribute to the
> >> >> project. We can post a message that warns that it's not
> marked as
> >> >> importable, and if the build fails and a file was imported,
> >> >> we can add
> >> >> to the message a note that tells the user that the file that was
> >> >> imported was not marked as importable.
> >> >>
> >> >
> >> > I like this, but I would be even more strict, the project must be
> >> > "importable" in order to be imported, and this also would make
> >> > ${ant.file.projectname} and ${basedir.projectname} available.
> >> >
> >> > This will force an specific clear pattern for the
> imports and will
> >> > make users more aware of the suttle diferences on file
> >> resolution rules.
> >>
> >> I'm not very comfortable with special requirements on the
> >> imported files.
> >> Xslt doesn't - and one major use case is using existing
> build files.
> >>
> >> Solving the problem is easy, and it can be made
> customizable. All we
> >> need is to solve the BuildFile info in the UE and make a
> small change
> >> in the code that resolves.
> >>
> >> Costin
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
