I am familiar a little with the winrm protocol so it will be interesting
for me to translate the pywinrm implementation we use in java.
I would like to take this task.
Valentin
On 10/13/2015 04:34 AM, Hadrian Zbarcea wrote:
Agree.
Created an issue [1] for tracking. Anybody interested in taking on
such a task?
Hadrian
[1] https://issues.apache.org/jira/browse/BROOKLYN-180
On 10/12/2015 12:48 PM, Martin Harris wrote:
+1 to a rewrite. I'd considered this option when working on WinRM, but
didn't have time to give it a try
In the longer term it will probably also provide other benefits in our
WinRM offering, including stability, security and reliability of exit
codes
Cheers
M
On 12 Oct 2015 17:41, "Aled Sage" <[email protected]> wrote:
If a pure-java re-write of winrm4j will make our life significantly
easier
for OSGi'fying Apache Brooklyn, then yes.
But if it's going to be a lot more effort to rewrite it, then we should
live with it for now.
---
My gut feel is that a rewrite won't be that hard, given we have the
reference implementation in Python.
We also have pretty good live-test coverage for various different
scripts
(I'm copying what we have in Brooklyn WinrmMachineLocationLiveTest
into the
winrm4j repo).
Aled
p.s. we are trying to get the OSGi stuff done within the next couple of
weeks, to include it in a 0.9.0 release.
On 12/10/2015 17:25, Valentin Aitken wrote:
+1
However exactly because it is just 822 it is really not a problem
that it
is a python code.
We are using it intensively and we didn't hit any problems still.
So I vote to do it but later.
Valentin
On 10/12/2015 07:20 PM, Richard Downer wrote:
// new subject, was [PROPOSAL] Split brooklyn-core during
OSGification
The core code of PyWinRM (i.e. excluding tests) is 822 lines of code.
I know that Java line counts tend to explode, but I'm thinking that
maybe creating a Java implementation of the WinRM client is not
such a
horrible task as I thought it perhaps was. Doing this would mean that
we could drop the Jython dependency. It's a disproportionately large
dependency for the value it gives us.
https://github.com/diyan/pywinrm/tree/master/winrm
Thoughts?
On 12 October 2015 at 17:14, Alex Heneveld
<[email protected]> 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
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
