Makes sense splitting up the core.
+1 to moving winrm-integration. I'd be happy to make that an optional
dependency, rather than it always being pulled in. But I'm keen that we
don't break Windows support, so that it can still (somehow) be included.
*Alex*, are you saying they want to exclude it because of its size? Or
some other reason?
---
*Hadrian*, For the impact to current users, are you thinking in terms of
renaming bundles and/or packages that are being referenced by users'
OSGi manifests? Or something else?
If it "just" requires users to update their manifests slightly and
rebuild their bundles, then I think that is acceptable.
---
*Hadrian*, It feels like brooklyn-rt-felix should have just the
felix-specific code (rather than it being a rename of the current
brooklyn-core). I'm not sure I follow that suggestion.
---
I'd also take the split-up opportunity to move the task framework to its
own bundle, but that is low priority.
Aled
On 12/10/2015 17:14, Alex Heneveld wrote:
We should move winrm/jython to a new project in any case. Many users
will want to exclude that bundle.
I suggest software/winrm/ folder brooklyn-software-winrm project.
--A
On 12/10/2015 17:59, Hadrian Zbarcea wrote:
I think we'll need to split the core in multiple parts actually. I am
having a bit of trouble myself with winrm4j. The complication is that
it depends on jython, which does not provide an OSGi bundle either. I
am not sure for instance if winrm4j is always necessary or it could
be another core-ish bundle.
A second thought is that I don't know what the impact on current
users would be to move the current use of the OSGi framework in a
different jar. One possibility is to split the core into multiple
jar, following a convention we can agree upon (brooklyn-rt-* would be
a common convention), but then let what Cipi called
brooklyn-rt-felix, keep the current name brooklyn-core.
Cheers,
Hadrian
On 10/12/2015 09:53 AM, Ciprian Ciubotariu wrote:
While working on running Brooklyn inside Karaf I ran into the code that
manages an embedded Apache Felix runtime.
Since the roles are now reversed, I propose to split brooklyn-core
into the
following:
* brooklyn-core - new implementation using the Karaf-provided OSGi
runtime
* brooklyn-rt-felix - existing code using felix as an embedded OSGI
runtime
(which will no longer be needed when OSGification is complete)
This change is much needed since the Apache Felix packages that are
used to
start and stop the embedded framework are private within the felix
bundle
My intention is to move current code to brooklyn-rt-felix, and defer
to it
when the Karaf container is not present, while using the Karaf-provided
felix/equinox framework by default.
I have already started to code in that direction, but since this is
a larger
change I would like to hear your thoughts on the matter.
