rationalise targets

[marklogic]

rationalise targets

[rjrudin]

In general, I've chosen a syntax of "ml(verb)(noun)" - e.g. mlClearModules, mlReloadModules.

The reason I have tasks like "mlAppDeploy" and "mlCpfDeploy" - i.e. "ml(noun)(verb)" - is that if I use e.g. "mlDeployCpf", then a user can't shorten "mlDeploy" to something like "mldep", which Gradle will then figure out must be "mlDeploy". But that may not really matter. It's convenient when a verb is really long, but there aren't many such verbs.

So do you think it would suffice if all tasks fit the "ml(verb)(noun)" pattern? I think that would make things intuitive for the user - the user then just has to learn the verbs and nouns that matter to ml-gradle.

There's then the issue of "mlPostDeploy", but I think it would be intuitive if there's a set of "mlPost(verb)" tasks which gives the user an easy way of tacking more tasks onto the end of an existing task. We don't need "mlPre(verb)" tasks because Gradle handles that via "dependsOn".

[xquery]

I was more thinking more of having a single verb ex. 'mlDeploy' which would deploy everything then you would exclude (via commandline switches and/or properties). I am fine with the current naming convention perse.

Don't let me distract you, I am all for specific targets as you have them ... just thinking control via properties/commandline switches of nouns maybe worth investigating.

[rjrudin]

Okay, so e.g. instead of mlCpfDeploy, "gradle mlDeploy -Pfeature=cpf"?

[xquery]

maybe ... I wonder how that might translate in terms of a set of java properties eg.

  feature=cpf

resources might also be represented

  database=MyModuleDB,MyContentDb

admittedly, this is tinkering around the edges, but thought I would mention it.

[rjrudin]

Jim, I'm going to close this - I did standardize the naming a while back for tasks to start with "mlDeploy" in general, and they're better grouped when you run "gradle tasks" as well.