brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: WinRM support via PyWinRM+Jython
Date Tue, 13 Oct 2015 01:34:12 GMT
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" <aled.sage@gmail.com> 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
>>>> <alex.heneveld@cloudsoftcorp.com> 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
>>>>>>
>>>>>
>>>
>>>
>>
>

Mime
View raw message