ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Property setting Policy.
Date Mon, 18 Jun 2001 15:07:38 GMT
> From:
> Peter Donald wrote:
> > > Would that be a bad thing?  If we have a policy, tasks
> should follow
> > > it, no?
> >
> > Depends who you ask ;) It would be good to be able to
> enforce the policy but
> > there will always be people who want to do something else.
> ie I think most
> > people agree that immutable properties are better but some
> people have
> > requested mutability of properties. If were to enforce the
> immutability in
> > core they could not get around that when they think we are wrong ;)
> This is probably overkill, but once we have decided what the
> general policy
> would be and where its major "hinge points" are (I think
> that's the term Peter
> likes to use) could we not have a policy
> file/system/whatever, much like the
> java security system does?
> grant {
>   permission ant.Property "cli", "read";    //  CLI
> properties are read-only
>   permission ant.Property "project", "write"; // Project
> level properties are
> read-write
>   permission ant.Property "target", "write"; // Target level
> properties are
> read-write
>   permission ant.Property "parent-project", "read"; //
> Parent/Super project
> properties are read-only
> }
> In a more XMLish way
> <ant-policy>
>   <permission type="ant.Property">
>     <target name="cli" action="read" />
>     <target name="project" action="write"/>
>     <target name="target" action="write" />
>     <target name="super-project" action="read" />
>   </permission>
> </ant-policy>
> That way, at each stage of the game we can check the policy
> to see what the
> build file writer is allowed to do.  We can suggest the
> "correct" policy with
> our default file, but the user/sysadmin can change the policy
> for a site.

I think we need to make up our minds on what the property operators are and
mean. If they are an intrinsic part of the ANT language, they need to have a
consistent meaning and behavior. It cannot be that to be able to understand
what a buildfile is doing you need to know what a sysadmin decided to have
as policy.

I would prefer a well defined programmatic API the tasks use to manipulate
ANT properties. And, of course, I would advocate for them to be inmutable. I
see little reason to have different behaviour all over the place. Are there
any examples of why such thing is needed in core?

If someone wants to write its own <type> and corresponding manipulation
tasks that allow to store mutable values, well I have no problem with that,
as long it is out of core on some specialized environment. We already plan
${foo} to be applicable to things other than properties (i.e., <type>
instances), so it should be possible for a user to define its own mutable

Jose Alberto

View raw message