You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by aledsage <gi...@git.apache.org> on 2015/08/20 00:26:02 UTC
[GitHub] incubator-brooklyn pull request: Refactor: move more packages
GitHub user aledsage opened a pull request:
https://github.com/apache/incubator-brooklyn/pull/854
Refactor: move more packages
See individual commit descriptions for explanation of what has changed.
See @ahgittin comment in https://github.com/apache/incubator-brooklyn/pull/853 and also the doc https://docs.google.com/document/d/1un7SwvoE43lWaIlD5CRdIdza4XJkHji-OhTKXpkr0NA that was originally written #844
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/aledsage/incubator-brooklyn refactor/move-packages-20150819b
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-brooklyn/pull/854.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #854
----
commit 0eab0fa05e4b9f700cef855e974971faf494116c
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T21:31:05Z
Rename o.a.b.util.groovy.internal to o.a.b.util.groovy
commit 4820fa46722e980f3b90b55849977c3b115492e0
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T21:35:40Z
Move SshEffectorTasks into core’s effector.ssh package
commit 8dbb0e4b2de44840f23f6cce2862dc41ae9ff307
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T21:39:55Z
Rename o.a.b.effector.core to o.a.b.core.effector
commit 2a78e273dae0caf2e7a3b791f365d7c839a9b20b
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T21:42:32Z
Rename o.a.b.sensor.core to o.a.b.core.sensor
commit daf40919b6fa20f16b6cd7d9eb1ad9f79baaa8f4
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T21:56:13Z
Rename o.a.b.sensor.feed to o.a.b.feed and o.a.b.core.feed
commit 6f15e8a6d61c2e648547cf7faba03fbc06716421
Author: Aled Sage <al...@gmail.com>
Date: 2015-08-19T22:07:28Z
Rename o.a.b.sensor.enricher to o.a.b.core.enricher
- and o.a.b.enricher.stock for actual enricher impls
----
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-brooklyn pull request: Refactor: move more packages
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-brooklyn/pull/854
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-brooklyn pull request: Refactor: move more packages
Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/854#issuecomment-132816079
looks great. merging. to your other questions:
* `org.apache.brooklyn.camp.brooklyn.api.HasBrooklynManagementContext` - let's move this to be alongside `ManagementContextInjectable`
* underscore - this is becoming more common with python ascending but no strong feelings
* `SshCommandEffector` move to `o.a.b.effector.core.ssh`
* enrichers to `brooklyn-policy` - i think not
the others i think are less important and/or less clear, and for now we should do nothing with them. when we osgify things hopefully many of the packages can avoid being exported, and these we can move to `internal` sub-packages. (and if any `internal` ones are used, we fix those.) i am less concerned with doing that later on as it will not be very disruptive.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-brooklyn pull request: Refactor: move more packages
Posted by aledsage <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---