PROPOSAL: ${basedir} usage

[Brett Porter <br...@yahoo.com>]

Hi all,

I wanted to gather some thoughts on ${basedir} usage in
project.xml/maven.xml and how it relates to the reactor. This will help
clear up the problems in MAVEN-442.

The following tags in project.xml potentially can be used as relative
paths:
<extend>
<*sourceDirectory> (ie includeing unit tests, etc)
<directory> (under resource)
(and <filters> - see my next proposal :)

There are two alternatives:
1) assume all of these paths are relative to project.xml.
2) require all to be absolute paths (using basedir where needed to know
where project.xml lives).

In either case, ${basedir} will always be an absolute path that
specifies the directory containing project.xml/maven.xml.

Any plugins (and custom jelly maven.xml scripts) that don't work with
the choice will need to be modified.

Can anyone see any problems with either case, or provide favourable
reasons for either? This bug is currently blocking RC1, so I'd like to
decide and implement soon - either one should be fairly brief.

Cheers,
Brett


http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: PROPOSAL: ${basedir} usage

["Mark H. Wilkinson" <mh...@kremvax.net>]

On Tue, 2003-06-24 at 23:28, Brett Porter wrote:
> > I don't see an inconsistency, but I might be misinterpreting this last
> > sentence. It seems to make sense to me that relative paths in a
> 
> I was really concerned with the inconsistency between project.xml and 
> maven.xml

Ah; yeah, that's a bit of a bummer.

> > Oddly enough, the only call to File.isAbsolute in the maven source tree
> > is in the jxr plugin [...]
> 
> That does seem odd :) But its right - the plugin shouldn't have to care, 
> it should just get a File that works. Because Java doesn't want to 
> chdir, setting all File objects to absolute by prepending ${basedir} 
> makes sense (and ${basedir} should probably be put through a 
> getAbsoluteFile() too).

Agreed - ${pom.build.sourceDirectory} should always return an absolute
path, because most of the time that's what a plugin will want.

There are occasions when a plugin will want a value for a path relative
to ${basedir} - the Eclipse plugin needs to do this because paths in the
Eclipse .classpath file need to be relative as well, and it might be
useful for diagnostic messages too. Jelly doesn't make it easy to do
this, so it would be useful to have some way to perform this conversion.
I'm thinking this could either be a sister-method that returns exactly
what was in project.xml (${pom.build.verbatimSourceDirectory} perhaps),
or a generic helper method to make a project-relative path:
${pom.getProjectRelativePath(srcDir)}
I don't think the verbatimSourceDirectory option is a good one though:
unless we're ensuring the project.xml *only* contains relative paths,
verbatimSourceDirectory might still be an absolute path. The helper
method (or something like it) seems like a better option to me.

> One alternative, but its a bit dodgy, is to make sure all relative paths 
> are done using File objects, and there is no other supposition of CWD, 
> because then you can redefine the system property user.dir and File's 
> start moving as though that is the base if you call getAbsolutePath - 
> but I see this to be quite error prone :)

Ick! For reactor builds you'd need to set user.dir every time you run
code that's working on behalf of a different project, just in case it
creates a new calls getAbsolutePath on a File object. That sounds
tricky!

-Mark.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: PROPOSAL: ${basedir} usage

[Brett Porter <bp...@f2network.com.au>]

> I don't see an inconsistency, but I might be misinterpreting this last
> sentence. It seems to make sense to me that relative paths in a

I was really concerned with the inconsistency between project.xml and 
maven.xml

> Oddly enough, the only call to File.isAbsolute in the maven source tree
> is in the jxr plugin, where it does exactly this, with the comment:
> 
> <!-- XXX This is a dirty hack until the semantics of
> pom.build.sourceDirectory are cleared up -->
> 
> :-)

That does seem odd :) But its right - the plugin shouldn't have to care, 
it should just get a File that works. Because Java doesn't want to 
chdir, setting all File objects to absolute by prepending ${basedir} 
makes sense (and ${basedir} should probably be put through a 
getAbsoluteFile() too).

> Yeah, true. It's probably not possible to reliably identify relative
> paths in maven.xml scripts. Not without making all the jelly tags aware
> of basedir, anyway. That inconsistency is a bit of a pain. People are
> going to have working maven.xml files that suddenly break when they run
> them with a different working directory.

... unless they use basedir. Fair enough I guess?
One alternative, but its a bit dodgy, is to make sure all relative paths 
are done using File objects, and there is no other supposition of CWD, 
because then you can redefine the system property user.dir and File's 
start moving as though that is the base if you call getAbsolutePath - 
but I see this to be quite error prone :)

Thanks for your feedback. The more I think about it, I believe you are 
right - there should be no need for basedir in project.xml or 
project.properties or build.properties in a project directory.

Cheers,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: PROPOSAL: ${basedir} usage

["Mark H. Wilkinson" <mh...@kremvax.net>]

On Mon, 2003-06-23 at 23:31, Brett Porter wrote:
> Mark H. Wilkinson wrote:
> > On Mon, 2003-06-23 at 14:42, Brett Porter wrote:
> > 
> >>There are two alternatives:
> >>1) assume all of these paths are relative to project.xml.
> > 
> > I'd vote for this one unless someone can explain...
> 
> If you vote for this one, do you also allow ${basedir}?

Hrrm; good question. Given a clean slate I'd remove it, but I suspect
that would break a significant number of projects already out there. The
right thing to do is probably to allow relative or absolute paths (after
interpolation), and prefix ${basedir} to all relative paths. The
documentation should then explain that prefixing with ${basedir} is
redundant and other absolute paths are a bad idea (because they are
generally not portable between machines and operating systems).

Perhaps prefixing with ${basedir} could be deprecated over time?

> >>2) require all to be absolute paths (using basedir where needed to know
> >>where project.xml lives).
> > 
> > ... under what circumstances project.xml should contain an absolute path
> > that doesn't start with ${basedir}.
> 
> I can't think of any to be honest. I was thinking of letting Maven 
> silently convert relative paths to absolute ones by adding basedir to 
> the front, but I'm worried about the inconsistency of allowing basedir 
> and not.

I don't see an inconsistency, but I might be misinterpreting this last
sentence. It seems to make sense to me that relative paths in a
configuration file should be relative to the directory containing the
configuration file, absolute ones should be taken as is. The logic
doesn't seem difficult:

public File absolute(String basedir, String path) {
    File f = new File(path);
    if (!f.isAbsolute)
        f = new File(basedir, path);
    return f;
}

Oddly enough, the only call to File.isAbsolute in the maven source tree
is in the jxr plugin, where it does exactly this, with the comment:

<!-- XXX This is a dirty hack until the semantics of
pom.build.sourceDirectory are cleared up -->

:-)

> Also, when we get to jelly scripts like maven.xml, it gets harder (if 
> possible?) to preprocess relative paths, so ${basedir} is then required. 
>   However, this is likely to generate less complaints on the user list 
> as fewer people do any jelly scripting for their builds :)

Yeah, true. It's probably not possible to reliably identify relative
paths in maven.xml scripts. Not without making all the jelly tags aware
of basedir, anyway. That inconsistency is a bit of a pain. People are
going to have working maven.xml files that suddenly break when they run
them with a different working directory.

-Mark.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: PROPOSAL: ${basedir} usage

[Brett Porter <bp...@f2network.com.au>]

Mark H. Wilkinson wrote:
> On Mon, 2003-06-23 at 14:42, Brett Porter wrote:
> 
>>There are two alternatives:
>>1) assume all of these paths are relative to project.xml.
> 
> 
> I'd vote for this one unless someone can explain...

If you vote for this one, do you also allow ${basedir}?

>>2) require all to be absolute paths (using basedir where needed to know
>>where project.xml lives).
> 
> ... under what circumstances project.xml should contain an absolute path
> that doesn't start with ${basedir}.

I can't think of any to be honest. I was thinking of letting Maven 
silently convert relative paths to absolute ones by adding basedir to 
the front, but I'm worried about the inconsistency of allowing basedir 
and not.

Also, when we get to jelly scripts like maven.xml, it gets harder (if 
possible?) to preprocess relative paths, so ${basedir} is then required. 
  However, this is likely to generate less complaints on the user list 
as fewer people do any jelly scripting for their builds :)

I wonder though - if all the examples have ${basedir} and the FAQ has 
"why don't my relative paths work?", whether there would be too many 
problems? Maybe I'm too much of an optimist :)

Cheers,
Brett

-- 
Web Developer
f2 network ~ everything essential
02 8596 4437


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: PROPOSAL: ${basedir} usage

["Mark H. Wilkinson" <mh...@kremvax.net>]

On Mon, 2003-06-23 at 14:42, Brett Porter wrote:
> 
> There are two alternatives:
> 1) assume all of these paths are relative to project.xml.

I'd vote for this one unless someone can explain...

> 2) require all to be absolute paths (using basedir where needed to know
> where project.xml lives).

... under what circumstances project.xml should contain an absolute path
that doesn't start with ${basedir}.

I can't see how requiring everyone to remember to say
<sourceDirectory>${basedir}/src/java</sourceDirectory>
is anything other than a recipe for more "why doesn't it work?" traffic
on the mailing list. Better to let the tool do this, surely?

-Mark.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org