Adam Murdoch wrote
> The question then is what the scheme should be.
I thought we'd more or less follow your proposal:
- model classes in org.gradle.${function}
- task classes in org.gradle.${function}.tasks
- plugin and extension classes in org.gradle.${function}.plugins
- internal stuff in org.gradle.${function}.internal
Two things I noticed:
* It can be difficult to distinguish between models and extensions. Is there
a way around this?
* If possible, I'd like to avoid to mirror the "outer" package structure
under `internal`. Can we instead have `org.gradle.${function}.internal`,
`org.gradle.${function}.tasks.internal`, and
`org.gradle.${function}.plugins.internal`?
Adam Murdoch wrote
> If we go with a package naming scheme, then for incubating classes, we'll
> move the classes to the new packages. For public classes, we'll can
> exclude them or make the inspections tweakable (as the existing classes
> are already separated to various degrees).
Judging from your previous explanation, this is about much more than
verification, so we'll definitely have to make it work for existing public
classes.
Luke Daley wrote
>> If we go with some source/bytecode analysis, then the existing stuff
>> should just work.
> What are the downsides of this approach?
Given all the things we want to do based on this separation, it becomes an
important part of Gradle's architecture, and may also be relevant to
third-party plugins. In that case, the biggest drawback of inferring the
separation automagically is that the code's structure doesn't reflect the
architecture. Also, there may be limitations to what we can infer, which can
lead to further complications. In summary, a package naming scheme will be
easier to understand and deal with. The one big drawback is that we can't
change our existing public code to adhere to the new scheme.
Cheers,
Peter
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Package-names-for-tasks-and-plugins-tp5711007p5711105.html
Sent from the gradle-dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
