Github user aledsage commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/854#issuecomment-132810140
For other package renames / class moves that I'd like to see (or at least
think about more):
* More review of `org.apache.brooklyn.util.core.*` for what we can/should
move out of core.
What are your thoughts on brooklyn-util-common getting bigger, and ending
up with lots more dependencies
(e.g. we could move .osgis and .crypto, but that would give osgi.jar and
bouncycastle.jar dependencies).
* Think about org.apache.brooklyn.util.core.task (and other task classes):
Do we want to move those into their own brooklyn-task module?
* core.mgmt.persist versus core.mgmt.rebind: figure out exactly what is the
difference, and move classes accordingly.
* org.apache.brooklyn.camp.brooklyn.api.HasBrooklynManagementContext:
can we move this, and get rid of the package?
* org.apache.brooklyn.enricher.stock: I wonder if these should be in
brooklyn-policy instead of brooklyn-core.
But the o.a.b.entity.stock makes use of it, so probably not.
* brooklyn-rest-server: no common prefix (except o.a.b.rest, which is also
used by rest-api and rest-swagger).
* Initializers such as AddEffector etc: not sure if these should be
gathered somewhere, or if it's good to leave them in the package most related
to what they do.
There are still some anomalies such as `SshCommandEffector` in
`o.a.b.sensor.ssh`.
* `org.apache.brooklyn.entity.system_service`: do we want to remove the
underscore?
* .internal package names.
Would be nice if that meant what OSGi expects - i.e. package is not
accessible to any other modules (except "friend", but use that sparingly).
* A definition of our "public" api, and thus what our deprecation policy
applies to.
I completely agree that YAML is most important moving forwards.
But if are free to refactor back-end stuff (without deprecating) then it
will make our lives much simpler.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
