Model paths and '.' in task names.

161 views
Skip to first unread message

Luke Daley

unread,
Nov 26, 2014, 11:51:03 PM11/26/14
to gradl...@googlegroups.com
Hi,

We can’t currently build master with master due to a problem that we are going to have to resolve before the release of 2.3.

The problem is caused by the addition of some validation that wasn’t there in previous releases. Namely, we now validate property names in the “model space”. We use the term “model space” to refer to the configuration model that we manage with the new infrastructure. One of the properties of the model space is that you can “path” into it in a formal way. 

We bridge the task container into the “model space”, which allows tasks to be mutated/consumed by configuration rules etc. This means that you can address a particular task via its path, which is “tasks.«name»”. In “model space” terms, “tasks” is a root property and task is available as a property of it. The recent change is that we now validate when properties are inserted/registered that their name does not contain ‘.’ characters. Obviously, if we are to use ‘.’ as the property separator in a path, things get awkward if the property name may contain this character. The problem is that we do not restrict which characters can be used in task names right now. This is valid: `tasks.create(“ “)`. 

The current validation rules for property names in model space are more or less the rules for Java identifiers (i.e. [a-zA-Z0-9_])

At this point in time, tasks are the only thing that suffer from this constraint impedance mismatch.

Options as I see them:

1. Don’t make tasks whose name violates model space naming constraints visible in the model space
2. Don’t constrain model space property names
3. Add a special case for allowing task names to contain “invalid” characters

Options #2 and #3 will require ‘.’, and possibly other characters, to be escaped in model path representations. 

My preference would be to go for #1, and we deprecate allowing [^a-zA-Z0-9_] in task names. 


Szczepan Faber

unread,
Nov 27, 2014, 5:14:52 AM11/27/14
to gradl...@googlegroups.com
+1 to #1

I like strict naming rules. Just last week I debugged an issue which
root cause was that the task was created with name with trailing space
("someName ")

I see that the plan is to also prevent '-' in the task name - I think
it is a good idea (although I've seen many custom tasks with '-' at
clients).

Cheers!
> --
> You received this message because you are subscribed to the Google Groups
> "gradle-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gradle-dev+...@googlegroups.com.
> To post to this group, send email to gradl...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gradle-dev/etPan.5476adaf.6763845e.b1%40Trajan.local.
> For more options, visit https://groups.google.com/d/optout.



--
Szczepan Faber
Core dev@gradle; Founder@mockito

Luke Daley

unread,
Nov 27, 2014, 6:26:58 PM11/27/14
to gradl...@googlegroups.com
Hmm. Good point on ‘-‘ I think we could allow that in names without issue if we wanted to.

Daz DeBoer

unread,
Nov 27, 2014, 6:38:40 PM11/27/14
to Gradle Development List
On Thu, Nov 27, 2014 at 4:26 PM, Luke Daley <luke....@gradleware.com> wrote:
Hmm. Good point on ‘-‘ I think we could allow that in names without issue if we wanted to.

Yep it's kind of nice to have names-with-dashes. I guess one downside is that we can't use the name directly as a java identifier. Not sure if that's important.
 

For more options, visit https://groups.google.com/d/optout.



--
Darrell (Daz) DeBoer

Luke Daley

unread,
Nov 27, 2014, 6:58:17 PM11/27/14
to gradl...@googlegroups.com



On 28 November 2014 at 9:38:40 am, Daz DeBoer (darrell...@gradleware.com) wrote:



On Thu, Nov 27, 2014 at 4:26 PM, Luke Daley <luke....@gradleware.com> wrote:
Hmm. Good point on ‘-‘ I think we could allow that in names without issue if we wanted to.

Yep it's kind of nice to have names-with-dashes. I guess one downside is that we can't use the name directly as a java identifier. 

It’s ok for the “pathing language”, but is slightly problematic at other times. We potentially have this problem already with the `BinaryTasksContainer` type idea where you want to provide a view of a collection where properties are static identifiers to items in the collection. 

Not sure if that's important.

If we were starting from scratch, I’d definitely push for not allowing ‘-' in task names. I’m not sure we have this option though now.

Not sure what to do.

Szczepan Faber

unread,
Nov 28, 2014, 12:55:06 AM11/28/14
to gradl...@googlegroups.com
We could keep support of '-'. It reduces the impact and might make
some users happy (those attached to this kind of naming).

I generally don't like task names with '-' because a) they require
quotes when referred as literal in the build files b) they are not
completely compatible with shorthand task invocation (which works best
if standard camel case is used) c) they lead to inconsistencies in
naming conventions: in large plugin suites, some tasks use '-' some
tasks are camel-case'y. In general it feels like, consistent,
stricter, camel case naming scheme would allow users to benefit from
Gradle more.

However, keeping support '-' means lower impact. This is always a good
thing :). ant import simpler :). Possibly keeps some users happy
(those attached to '-' convention).

Cheers!
> https://groups.google.com/d/msgid/gradle-dev/etPan.5477b33c.2ae8944a.bd%40Trajan.local.

Adam Murdoch

unread,
Dec 1, 2014, 5:21:51 PM12/1/14
to gradl...@googlegroups.com
On 28 Nov 2014, at 10:58 am, Luke Daley <luke....@gradleware.com> wrote:




On 28 November 2014 at 9:38:40 am, Daz DeBoer (darrell...@gradleware.com) wrote:



On Thu, Nov 27, 2014 at 4:26 PM, Luke Daley <luke....@gradleware.com> wrote:
Hmm. Good point on ‘-‘ I think we could allow that in names without issue if we wanted to.

Yep it's kind of nice to have names-with-dashes. I guess one downside is that we can't use the name directly as a java identifier. 

It’s ok for the “pathing language”, but is slightly problematic at other times. We potentially have this problem already with the `BinaryTasksContainer` type idea where you want to provide a view of a collection where properties are static identifiers to items in the collection. 

Not sure if that's important.

If we were starting from scratch, I’d definitely push for not allowing ‘-' in task names. I’m not sure we have this option though now.

Not sure what to do.


I think we should be somewhat forgiving, particularly for things like tasks that already exist. I’d allow ‘-‘ and ‘_’ for now, and see what falls out later.



For more options, visit https://groups.google.com/d/optout.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Schalk Cronjé

unread,
Dec 2, 2014, 8:36:54 AM12/2/14
to gradl...@googlegroups.com
Currently Ant allows nearly anything in property & task names. If you reflect an Ant project using

ant.importBuild 'build.xml'

you'll get whatever task names are in there as Gradle tasks.

If you are planning to disallow certain characters in identifiers, you'll have to decide how you plan to handle this long-supported feasture of Gradle.

(AAMOF we were going to see if we could reflect Rake task names back into Gradle in the same way).

Luke Daley

unread,
Dec 2, 2014, 6:02:49 PM12/2/14
to gradl...@googlegroups.com
If we do introduce restrictions, people importing Ant builds can deal with that via renaming the Ant targets.

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

Adam Murdoch

unread,
Dec 2, 2014, 6:19:04 PM12/2/14
to gradl...@googlegroups.com

Whatever we do for tasks, we should apply the same validation for project names, as we will have exactly the same problems when we start mixing projects into the new world.


-- 
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Luke Daley

unread,
Dec 2, 2014, 7:21:47 PM12/2/14
to gradl...@googlegroups.com
Same applies to “named” things, but we shouldn’t have too much of a backwards compatibility issue here.

I’ll just add a story to the spec about all this for now and revisit in a little bit.

Schalk Cronjé

unread,
Dec 3, 2014, 9:53:42 AM12/3/14
to gradl...@googlegroups.com


On Tuesday, 2 December 2014 23:02:49 UTC, luke.daley wrote:
If we do introduce restrictions, people importing Ant builds can deal with that via renaming the Ant targets.


On 2 December 2014 at 11:36:56 pm, Schalk Cronjé (ysb...@gmail.com) wrote:



That's pretty awesome. I can live with that.
Reply all
Reply to author
Forward
0 new messages