birth of "console ui" in eclipse

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

birth of "console ui" in eclipse

Max Rydahl Andersen
Contributed by Rob Cernich.

work in progress - feedback welcome ;)




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Stan Silvert
Looks a lot like the CLI GUI.  We should collaborate.

On 2/10/2012 12:26 PM, Max Rydahl Andersen wrote:
Contributed by Rob Cernich.

work in progress - feedback welcome ;)





_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Marek Novotny
In reply to this post by Max Rydahl Andersen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nice, what nightly build does it contain?


On 02/10/2012 06:26 PM, Max Rydahl Andersen wrote:

> Contributed by Rob Cernich.
>
> work in progress - feedback welcome ;)
>
>
> /max
> http://about.me/maxandersen
>
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


- --
Marek Novotny
- --
WFK and Seam Product Lead

Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk81V3EACgkQU4HO8G8hNxUiMgCfSNHxcXI5Bl4WIb01EoE2DTui
06oAoOHSzas1KhCLyrc0Te1A+0wHbT2g
=4BUu
-----END PGP SIGNATURE-----
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Rob Cernich
In reply to this post by Stan Silvert
> Looks a lot like the CLI GUI. We should collaborate.

It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
* a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
* an attributes node - container for attributes defined by a resource
* an attribute node - an attribute value associated with a resource
* a category node - represents a "child-type" defined by a resource (e.g. subsystem).

The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.

For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.

Best,
Rob
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Max Rydahl Andersen

For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
for "older" AS's where you can do edit operations etc.

but for now we just do this "baby" raw console as a read only operation and see where it takes us.

/max
 
On Feb 10, 2012, at 19:08, Rob Cernich wrote:

>> Looks a lot like the CLI GUI. We should collaborate.
>
> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
> * an attributes node - container for attributes defined by a resource
> * an attribute node - an attribute value associated with a resource
> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>
> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>
> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>
> Best,
> Rob
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Heiko Braun


IMO it's pretty lame to work on three different, redundant efforts:

- the web UI
- the CLI UI
- the eclipse UI

I can somehow understand the CLI UI, but i think the best approach for eclipse would be to embed the web UI. Maybe with a different layout. Something that fits better into the overall frame. But technically it should be possible to reuse the web UI.

I keep hearing the term "like JMX console" over and over again. If  you think that power users require something more generic then the full blown web UI, why not build it within the console itself? And then use it embedded within eclipse?

/Ike

On Feb 10, 2012, at 7:54 PM, Max Rydahl Andersen wrote:

>
> For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
> for "older" AS's where you can do edit operations etc.
>
> but for now we just do this "baby" raw console as a read only operation and see where it takes us.
>
> /max
>
> On Feb 10, 2012, at 19:08, Rob Cernich wrote:
>
>>> Looks a lot like the CLI GUI. We should collaborate.
>>
>> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
>> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
>> * an attributes node - container for attributes defined by a resource
>> * an attribute node - an attribute value associated with a resource
>> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>>
>> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>>
>> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>>
>> Best,
>> Rob
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Stan Silvert
In reply to this post by Max Rydahl Andersen
It will be interesting to see where it goes.  In the beginning I started
to structure the nodes in a similar way.  But because the CLI GUI is
geared toward building and executing commands, I kept it so that each
node represents part of the address.

The self-describing nature of the DMR is really powerful.  We already
have three or four apps built on top of it and I suspect we haven't seen
the last.

BTW, is it impossible to run Swing code from inside Eclipse?

On 2/10/2012 1:54 PM, Max Rydahl Andersen wrote:

> For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
> for "older" AS's where you can do edit operations etc.
>
> but for now we just do this "baby" raw console as a read only operation and see where it takes us.
>
> /max
>  
> On Feb 10, 2012, at 19:08, Rob Cernich wrote:
>
>>> Looks a lot like the CLI GUI. We should collaborate.
>> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
>> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
>> * an attributes node - container for attributes defined by a resource
>> * an attribute node - an attribute value associated with a resource
>> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>>
>> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>>
>> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>>
>> Best,
>> Rob
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> /max
> http://about.me/maxandersen
>
>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Max Rydahl Andersen-2
In reply to this post by Heiko Braun
Embedding webui is crapy.

Which is why we link
To the console and show in browser externally or embedded.

We deliberately try not to depend
Nor duplicate the console.

The "tree" browser is simply just there since its trivial to do and been asked for.

Afaik there is no tree browser in console and even if there is then its a webapp with no way to integrate with besides viewing.

Btw. Latest as7.1 has weird scrolling behavior when embedded in eclipse. Just noticed that :(

/max (sent from my phone)


On 10/02/2012, at 20.09, Heiko Braun <[hidden email]> wrote:

>
>
> IMO it's pretty lame to work on three different, redundant efforts:
>
> - the web UI
> - the CLI UI
> - the eclipse UI
>
> I can somehow understand the CLI UI, but i think the best approach for eclipse would be to embed the web UI. Maybe with a different layout. Something that fits better into the overall frame. But technically it should be possible to reuse the web UI.
>
> I keep hearing the term "like JMX console" over and over again. If  you think that power users require something more generic then the full blown web UI, why not build it within the console itself? And then use it embedded within eclipse?
>
> /Ike
>
> On Feb 10, 2012, at 7:54 PM, Max Rydahl Andersen wrote:
>
>>
>> For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
>> for "older" AS's where you can do edit operations etc.
>>
>> but for now we just do this "baby" raw console as a read only operation and see where it takes us.
>>
>> /max
>>
>> On Feb 10, 2012, at 19:08, Rob Cernich wrote:
>>
>>>> Looks a lot like the CLI GUI. We should collaborate.
>>>
>>> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
>>> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
>>> * an attributes node - container for attributes defined by a resource
>>> * an attribute node - an attribute value associated with a resource
>>> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>>>
>>> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>>>
>>> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>>>
>>> Best,
>>> Rob
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Rob Cernich
In reply to this post by Stan Silvert
> BTW, is it impossible to run Swing code from inside Eclipse?

I believe it's possible, but I don't think it's very pretty.  The biggest problem is that the underlying windowing systems are very different between the two: SWT rides the OS, while Swing provides its own.  All SWT controls are either native controls or built using native controls.

That said, I've never attempted this, never researched and never seen it done.  (I don't get out much though. ;) )
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Stan Silvert
In reply to this post by Heiko Braun
On 2/10/2012 2:09 PM, Heiko Braun wrote:
>
> IMO it's pretty lame to work on three different, redundant efforts:
>
> - the web UI
> - the CLI UI
> - the eclipse UI
All three of these have slightly different audiences, but they will
probably converge eventually.  I think it's too early to stifle
innovation and insist that there is one true way to leverage the DMR.

One thing I would like to try is to see if we can run the CLI GUI as an
applet behind the console's security.  That would instantly give us the
"expert mode" Jason was talking about.

>
> I can somehow understand the CLI UI, but i think the best approach for eclipse would be to embed the web UI. Maybe with a different layout. Something that fits better into the overall frame. But technically it should be possible to reuse the web UI.
>
> I keep hearing the term "like JMX console" over and over again. If  you think that power users require something more generic then the full blown web UI, why not build it within the console itself? And then use it embedded within eclipse?
>
> /Ike
>
> On Feb 10, 2012, at 7:54 PM, Max Rydahl Andersen wrote:
>
>> For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
>> for "older" AS's where you can do edit operations etc.
>>
>> but for now we just do this "baby" raw console as a read only operation and see where it takes us.
>>
>> /max
>>
>> On Feb 10, 2012, at 19:08, Rob Cernich wrote:
>>
>>>> Looks a lot like the CLI GUI. We should collaborate.
>>> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
>>> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
>>> * an attributes node - container for attributes defined by a resource
>>> * an attribute node - an attribute value associated with a resource
>>> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>>>
>>> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>>>
>>> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>>>
>>> Best,
>>> Rob
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Max Rydahl Andersen-2
In reply to this post by Stan Silvert
Swing can run but semi broken. Especially on non-windows platforms.

We can share the model not ui.

P.s. and we would need code that works across multiple versions of as7/eap. Not sure cli has the same goal?

/max (sent from my phone)


On 10/02/2012, at 20.13, [hidden email] wrote:

> It will be interesting to see where it goes.  In the beginning I started
> to structure the nodes in a similar way.  But because the CLI GUI is
> geared toward building and executing commands, I kept it so that each
> node represents part of the address.
>
> The self-describing nature of the DMR is really powerful.  We already
> have three or four apps built on top of it and I suspect we haven't seen
> the last.
>
> BTW, is it impossible to run Swing code from inside Eclipse?
>
> On 2/10/2012 1:54 PM, Max Rydahl Andersen wrote:
>> For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got
>> for "older" AS's where you can do edit operations etc.
>>
>> but for now we just do this "baby" raw console as a read only operation and see where it takes us.
>>
>> /max
>>
>> On Feb 10, 2012, at 19:08, Rob Cernich wrote:
>>
>>>> Looks a lot like the CLI GUI. We should collaborate.
>>> It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet.  The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side).  The model code could be shared, but there's not much there on the Eclipse side:
>>> * a resource node - represents an addressable resource (e.g. /subsystem=switchyard)
>>> * an attributes node - container for attributes defined by a resource
>>> * an attribute node - an attribute value associated with a resource
>>> * a category node - represents a "child-type" defined by a resource (e.g. subsystem).
>>>
>>> The model is built using read-resource-description, read-children-names and read-resource, depending on the node type.
>>>
>>> For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View.  The "baby console" was just a POC demonstrating the possibilities.
>>>
>>> Best,
>>> Rob
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Heiko Braun
In reply to this post by Max Rydahl Andersen-2

On Feb 10, 2012, at 8:26 PM, Max Andersen wrote:

Afaik there is no tree browser in console and even if there is then its a webapp with no way to integrate with besides viewing. 


no, that's true. it's not yet there. but it's been requested several times and it will come.  

you know eclipse better then me and your concerns about embedding may be right. but if you guys could work towards something decoupled from it's view technology, I might be able to re-use large parts of it.


/Ike



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Max Rydahl Andersen-2
In reply to this post by Marek Novotny
Got into trunk a few days ago. Should be on nightly trunk update sites soon if not already.

/max (sent from my phone)


On 10/02/2012, at 18.44, Marek Novotny <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nice, what nightly build does it contain?
>
>
> On 02/10/2012 06:26 PM, Max Rydahl Andersen wrote:
>> Contributed by Rob Cernich.
>>
>> work in progress - feedback welcome ;)
>>
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> - --
> Marek Novotny
> - --
> WFK and Seam Product Lead
>
> Red Hat Czech s.r.o.
> Purkynova 99
> 612 45 Brno
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk81V3EACgkQU4HO8G8hNxUiMgCfSNHxcXI5Bl4WIb01EoE2DTui
> 06oAoOHSzas1KhCLyrc0Te1A+0wHbT2g
> =4BUu
> -----END PGP SIGNATURE-----
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Rob Cernich
In reply to this post by Max Rydahl Andersen-2
> Embedding webui is crapy.

Unfortunately, I agree.  One of the first customizations I make in my workspace is, "open in external browser."

> Which is why we link
> To the console and show in browser externally or embedded.
>
> We deliberately try not to depend
> Nor duplicate the console.

I agree with this.  I don't think the goal is or should be to duplicate what's in the console, but it does make sense to have some limited capabilities that help the developer.  I don't think the target audience for this is or should be system administrators and operations folks.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Max Rydahl Andersen-2
In reply to this post by Rob Cernich
For this I don't see it worth it.

Only sensible usage ive seen of it when my eclipse "ported" netbeans swing editor to eclipse.

That would be way to complex to
Port natively and would need swing anyway for rendering.

/max (sent from my phone)


On 10/02/2012, at 20.27, Rob Cernich <[hidden email]> wrote:

>> BTW, is it impossible to run Swing code from inside Eclipse?
>
> I believe it's possible, but I don't think it's very pretty.  The biggest problem is that the underlying windowing systems are very different between the two: SWT rides the OS, while Swing provides its own.  All SWT controls are either native controls or built using native controls.
>
> That said, I've never attempted this, never researched and never seen it done.  (I don't get out much though. ;) )
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: birth of "console ui" in eclipse

Rob Cernich
In reply to this post by Heiko Braun
> you know eclipse better then me and your concerns about embedding may
> be right. but if you guys could work towards something decoupled
> from it's view technology, I might be able to re-use large parts of
> it.

I certainly think there may be opportunity here from a model perspective.  For example, creating higher level types than "resource" (e.g. data source), that encapsulate specific resource types within the server.  That said, I'm not sure if there is any support available for the AutoBean framework in Eclipse (knowing the console makes heavy use of AutoBean).  If there is, that would certainly simplify adding more detailed capabilities.

The model used in the Eclipse POC is simply a model around the low level, generic resource API, nothing more.  It's simple, complete, but not very pretty (or usable, in my opinion).

Best,
Rob
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
Hey folks,

I've spent a brief amount of time adding SwitchYard specific console features into the Eclipse Servers View.  It would be a *huge* help if the models used in the GWT console could be used in Eclipse.

That said, there is a lot of mileage to be gained by simply being able to use the AutoBean framework within Eclipse.  Does anyone have any experience using AutoBeans in an Eclipse or OSGi environment?  (In SY land, we're slowly moving to a place where our core management/configuration model API can be used in the tooling as well.)

Best,
Rob

> > you know eclipse better then me and your concerns about embedding
> > may
> > be right. but if you guys could work towards something decoupled
> > from it's view technology, I might be able to re-use large parts of
> > it.
>
> I certainly think there may be opportunity here from a model
> perspective.  For example, creating higher level types than
> "resource" (e.g. data source), that encapsulate specific resource
> types within the server.  That said, I'm not sure if there is any
> support available for the AutoBean framework in Eclipse (knowing the
> console makes heavy use of AutoBean).  If there is, that would
> certainly simplify adding more detailed capabilities.
>
> The model used in the Eclipse POC is simply a model around the low
> level, generic resource API, nothing more.  It's simple, complete,
> but not very pretty (or usable, in my opinion).
>
> Best,
> Rob
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Max Rydahl Andersen-2
> Hey folks,
>
> I've spent a brief amount of time adding SwitchYard specific console features into the Eclipse Servers View.  It would be a *huge* help if the models used in the GWT console could be used in Eclipse.
>
> That said, there is a lot of mileage to be gained by simply being able to use the AutoBean framework within Eclipse.  Does anyone have any experience using AutoBeans in an Eclipse or OSGi environment?  (In SY land, we're slowly moving to a place where our core management/configuration model API can be used in the tooling as well.)

I know very little about AutoBean framework so cannot say how/if it will work.

What I'm most worried about though is any eclipse tooling that hard-binds/limits itself to specific versions of runtimes/admin apis.

Will this allow you to support multiple versions better or worse ?

What I understand is you would be using/linking with the Admin console code which would tie you 100% to a specific version ... that sounds like a bad approach to me ?
 
/max

>
> Best,
> Rob
>
>>> you know eclipse better then me and your concerns about embedding
>>> may
>>> be right. but if you guys could work towards something decoupled
>>> from it's view technology, I might be able to re-use large parts of
>>> it.
>>
>> I certainly think there may be opportunity here from a model
>> perspective.  For example, creating higher level types than
>> "resource" (e.g. data source), that encapsulate specific resource
>> types within the server.  That said, I'm not sure if there is any
>> support available for the AutoBean framework in Eclipse (knowing the
>> console makes heavy use of AutoBean).  If there is, that would
>> certainly simplify adding more detailed capabilities.
>>
>> The model used in the Eclipse POC is simply a model around the low
>> level, generic resource API, nothing more.  It's simple, complete,
>> but not very pretty (or usable, in my opinion).
>>
>> Best,
>> Rob
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Max Rydahl Andersen-2
>> That said, there is a lot of mileage to be gained by simply being able to use the AutoBean framework within Eclipse.  Does anyone have any experience using AutoBeans in an Eclipse or OSGi environment?  (In SY land, we're slowly moving to a place where our core management/configuration model API can be used in the tooling as well.)

Oh and this is even worse now I reread it - having *hard coupled* dependencies to core from eclipse plugins is our biggest problem we have in Drools, Teiid and Modeshape.

This causes *massive* problems from both user and plugin-dev side since each release of the plugin extremely easy becomes tied to specific versions of the runtime.

Does the API allow decoupling ? (i.e. one option is the plugin to load dynamically the runtime jars from the targeted runtime)  
 
/max


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
In reply to this post by Max Rydahl Andersen-2
> I know very little about AutoBean framework so cannot say how/if it
> will work.

The framework creates a dynamic proxy for a bean interface which is backed by JSON, and can serialize object instances to JSON.  The shared component would be the interfaces.  The nice bit here is that it really simplifies the task of converting to/from JSON (much easier than managing ModelNode objects).

> What I'm most worried about though is any eclipse tooling that
> hard-binds/limits itself to specific versions of runtimes/admin
> apis.

You cannot avoid this problem.  Ideally, the best solution is to have well defined rules regarding the evolution of the API.  In my opinion, the management model should be treated no differently than any other public API provided by the server.

Back in the real world, this may require tooling specific to each version.  (The tooling is different between AS 5 and 7.)

> Will this allow you to support multiple versions better or worse ?

No difference here.  If the API changes between releases, you're stuck either way.  (Although, it may be better.  Because the framework simply proxies back to JSON, added structure will be invisible and removed structure will be null; i.e. you won't really see the changes.  It may be odd for the user, wondering why some setting appears to be ignored, but...)

> What I understand is you would be using/linking with the Admin
> console code which would tie you 100% to a specific version ... that
> sounds like a bad approach to me ?

Actually, you would be tied to an API specific to the management structure for each version of the runtime.  The console and other bits of tooling would depend upon that API.  If the API is stable between releases, then all is well.  If the API changes, then the console and other bits of tooling will need to be updated.  This is really no different than depending on any other API, like Eclipse or OSGi.  Those just happen to have a well defined process for managing the evolution of their API, which is the crux of the problem here.

That said, having a specific project(s) for a management model(s) might help ensure the stability of the API.

Best,
Rob
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12