What about this: when given a nonabsolute path to 'style', have it first try to resolve against project basedir, and it finds it then OK. If not, try against task basedir, and if found then print a deprecation warning and use that; else error. This would permit the task to have sane semantics and still not break old scripts.
The only incompatibility would then be if you had a style file of the same name in two different directories happening to match the project and task basedirs, in which case it would use the "wrong" one. But I think this is pretty obscure. -Jesse Stefan Bodewig wrote: > > Sam Ruby <[EMAIL PROTECTED]> wrote: > > > "basedir" no longer seems to be used in resolving "style". > > Yes, this is true. > > I've brought it into line with all other tasks, because I didn't know > the original intent was to make the attribute relative to the tasks > basedir attribute. Jesse Glick has already pointed out that this > change was not backwards compatible. > > As this now causes problems (I didn't expect anybody to rely on this - > at least for me - undocumented behavior), the only option I see is to > revert my patch - at least partially, the task should at least try to > check whether the style attribute contains an absolute path. -- Jesse Glick <mailto:[EMAIL PROTECTED]> NetBeans, Open APIs <http://www.netbeans.org/> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
