6:25 a.m.
Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added
support for RESTful endpoints which was very basic to start with, but more
and more feature requests have come which is the reason for creating this
email.
We did not set out to implement the RESTful support our selves, instead the
goal was to use RestEasy but as we required to be able to programmatically
add endpoints which was not an option at the time (but support for this
does now exist in RestEasy).
AeroGear controller's REST support started out very simple but as time
passed more request for things that are taken for granted in a JAX-RS
implementation were being asked for. We were moving toward something
equivalent to a JAX-RS implementation with regards to what we supported.
Adding more of these features added to the complexity of the Controller as
we needed to figure out good ways to provide the features requested, and
this also brings up the question if we should be doing this. The controller
is not specific to mobil, as any backend can be used with the client SDKs.
Also, there are plenty of options to implement RESTful backends, in Java
using RestEasy for example, or in a different language.
And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for
example the Unified Push Server and SimplePush Server etc.
So how do we make it visible that we have deprecated AeroGear-Controller?
A clear notice in the README.md is a good start. Should we mark every class
as deprecated as well?
These are just suggestions and if you have other ideas please let us know.
/Dan
8:30 a.m.
Fair points but I have to admit that this make me a bit sad because ag-controller was a
really nice piece of software, the fluent API and the integration with security were
really smart.
But indeed the link with mobile was not flagrant.
It remembers me a bit the Betamax / VHS story ;)
Maybe, some people in the open source community will take it over.
Seb
Envoyé de mon iPhone
Le Jun 9, 2013 à 13:25, Daniel Bevenius <daniel.bevenius(a)gmail.com> a écrit :
Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added support for
RESTful endpoints which was very basic to start with, but more and more feature requests
have come which is the reason for creating this email.
We did not set out to implement the RESTful support our selves, instead the goal was to
use RestEasy but as we required to be able to programmatically add endpoints which was not
an option at the time (but support for this does now exist in RestEasy).
AeroGear controller's REST support started out very simple but as time passed more
request for things that are taken for granted in a JAX-RS implementation were being asked
for. We were moving toward something equivalent to a JAX-RS implementation with regards to
what we supported. Adding more of these features added to the complexity of the Controller
as we needed to figure out good ways to provide the features requested, and this also
brings up the question if we should be doing this. The controller is not specific to
mobil, as any backend can be used with the client SDKs. Also, there are plenty of options
to implement RESTful backends, in Java using RestEasy for example, or in a different
language.
And after some discussions it has been decided that we should focus are efforts in other
places when it comes to our server side offerings, for example the Unified Push Server and
SimplePush Server etc.
So how do we make it visible that we have deprecated AeroGear-Controller?
A clear notice in the README.md is a good start. Should we mark every class as deprecated
as well?
These are just suggestions and if you have other ideas please let us know.
/Dan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:57 a.m.
Deprecate?! Why?! Do we have a lightweight MVC to replace?
I
should have written, deprecate the RESTful part of AeroGear controller,
as this is really what has been discussed.
If it makes sense to keep the MVC parts we can certainly do that.
On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Aloha Daniel,
So how do we make it visible that we have deprecated AeroGear-Controller?
Deprecate?! Why?! Do we have a lightweight MVC to replace?
-
abstractj
On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added
support for RESTful endpoints which was very basic to start with, but more
and more feature requests have come which is the reason for creating this
email.
We did not set out to implement the RESTful support our selves, instead
the goal was to use RestEasy but as we required to be able to
programmatically add endpoints which was not an option at the time (but
support for this does now exist in RestEasy).
AeroGear controller's REST support started out very simple but as time
passed more request for things that are taken for granted in a JAX-RS
implementation were being asked for. We were moving toward something
equivalent to a JAX-RS implementation with regards to what we supported.
Adding more of these features added to the complexity of the Controller as
we needed to figure out good ways to provide the features requested, and
this also brings up the question if we should be doing this. The controller
is not specific to mobil, as any backend can be used with the client SDKs.
Also, there are plenty of options to implement RESTful backends, in Java
using RestEasy for example, or in a different language.
And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for
example the Unified Push Server and SimplePush Server etc.
So how do we make it visible that we have deprecated AeroGear-Controller?
A clear notice in the README.md is a good start. Should we mark every
class as deprecated as well?
These are just suggestions and if you have other ideas please let us know.
/Dan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:02 a.m.
Ok, I almost had a heart attack here :) I'd say leave the REST bits as is and give to
people a choice.
-
abstractj
10:40 a.m.
I'm not sure deprecation is necessary but I would vote with Bruno to just leave the
REST bits as is and ensure nothing else depends on them. Then we just make a note in the
README that we have discontinued development and support on them. Then remove any
references from AeroGear.org and only talk about our other server side bits.
On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Ok, I almost had a heart attack here :) I'd say leave the REST
bits as is and give to people a choice.
-
abstractj
On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
> I should have written, deprecate the RESTful part of AeroGear controller, as this is
really what has been discussed.
> If it makes sense to keep the MVC parts we can certainly do that.
>
>
>
>
> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>> Aloha Daniel,
>>
>>
>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>
>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>
>> -
>> abstractj
>>
>>
>>>
>>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>>
>>>
>>
>>> Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added support for
RESTful endpoints which was very basic to start with, but more and more feature requests
have come which is the reason for creating this email.
>>>
>>> We did not set out to implement the RESTful support our selves, instead the
goal was to use RestEasy but as we required to be able to programmatically add endpoints
which was not an option at the time (but support for this does now exist in RestEasy).
>>>
>>> AeroGear controller's REST support started out very simple but as time
passed more request for things that are taken for granted in a JAX-RS implementation were
being asked for. We were moving toward something equivalent to a JAX-RS implementation
with regards to what we supported. Adding more of these features added to the complexity
of the Controller as we needed to figure out good ways to provide the features requested,
and this also brings up the question if we should be doing this. The controller is not
specific to mobil, as any backend can be used with the client SDKs. Also, there are plenty
of options to implement RESTful backends, in Java using RestEasy for example, or in a
different language.
>>>
>>> And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for example the
Unified Push Server and SimplePush Server etc.
>>>
>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>>
>>>
>>>>
>>>> A clear notice in the README.md is a good start. Should we mark every
class as deprecated as well?
>>>
>>>
>>>> These are just suggestions and if you have other ideas please let us
know.
>>>
>>> /Dan
>>>
>>
>> _______________________________________________
>>
>>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:42 a.m.
I would also say that this should happen in a 1.1.0 release since this is a major change
in supported bits.
On Jun 9, 2013, at 10:41, Kris Borchers <kborcher(a)redhat.com> wrote:
I'm not sure deprecation is necessary but I would vote with Bruno
to just leave the REST bits as is and ensure nothing else depends on them. Then we just
make a note in the README that we have discontinued development and support on them. Then
remove any references from AeroGear.org and only talk about our other server side bits.
On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Ok, I almost had a heart attack here :) I'd say leave the REST bits as is and
give to people a choice.
>
> -
> abstractj
>
> On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>
>> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
>> I should have written, deprecate the RESTful part of AeroGear controller, as this
is really what has been discussed.
>> If it makes sense to keep the MVC parts we can certainly do that.
>>
>>
>>
>>
>> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>> Aloha Daniel,
>>>
>>>
>>>> So how do we make it visible that we have deprecated
AeroGear-Controller?
>>>
>>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>>
>>> -
>>> abstractj
>>>
>>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>>
>>>> Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added support for
RESTful endpoints which was very basic to start with, but more and more feature requests
have come which is the reason for creating this email.
>>>>
>>>> We did not set out to implement the RESTful support our selves, instead
the goal was to use RestEasy but as we required to be able to programmatically add
endpoints which was not an option at the time (but support for this does now exist in
RestEasy).
>>>>
>>>> AeroGear controller's REST support started out very simple but as
time passed more request for things that are taken for granted in a JAX-RS implementation
were being asked for. We were moving toward something equivalent to a JAX-RS
implementation with regards to what we supported. Adding more of these features added to
the complexity of the Controller as we needed to figure out good ways to provide the
features requested, and this also brings up the question if we should be doing this. The
controller is not specific to mobil, as any backend can be used with the client SDKs.
Also, there are plenty of options to implement RESTful backends, in Java using RestEasy
for example, or in a different language.
>>>>
>>>> And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for example the
Unified Push Server and SimplePush Server etc.
>>>>
>>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>>>
>>>> A clear notice in the README.md is a good start. Should we mark every
class as deprecated as well?
>>>>
>>>> These are just suggestions and if you have other ideas please let us
know.
>>>>
>>>> /Dan
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:01 p.m.
Some of my thoughts:
The concern I have with leaving the REST bits as they are is confusion in what should be
used, and when. If we're not going to be enhancing the REST support, we should
deprecate it imo.
If the controller's MVC functionality is going to move forward (i.e. not be
deprecated) we should plan for its future carefully so that it works well with the REST
support provided by JAX-RS /RESTEasy. I'm just not sure of the priority over other
things atm. So it might be the type of thing where we take it where we can, and see if
there is community interest in moving it forward.
I certainly would like to see a solid MVC be standardized in EE(X), and it might be in the
future. However, there are a lot of different mvc frameworks out there and I'm
concerned over trying to create another, especially if it seems our functionality is tied
to it.
Either way, we should update our examples to show how to use our technology with RESTEasy,
with or without the controller and/or other mvc options. So that users know they have
options here.
On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
I'm not sure deprecation is necessary but I would vote with Bruno
to just leave the REST bits as is and ensure nothing else depends on them. Then we just
make a note in the README that we have discontinued development and support on them. Then
remove any references from AeroGear.org and only talk about our other server side bits.
On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Ok, I almost had a heart attack here :) I'd say leave the REST bits as is and
give to people a choice.
>
> -
> abstractj
>
> On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>
>> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
>> I should have written, deprecate the RESTful part of AeroGear controller, as this
is really what has been discussed.
>> If it makes sense to keep the MVC parts we can certainly do that.
>>
>>
>>
>>
>> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>> Aloha Daniel,
>>
>>
>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>
>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>
>> -
>> abstractj
>>
>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>
>>> Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added support for
RESTful endpoints which was very basic to start with, but more and more feature requests
have come which is the reason for creating this email.
>>>
>>> We did not set out to implement the RESTful support our selves, instead the
goal was to use RestEasy but as we required to be able to programmatically add endpoints
which was not an option at the time (but support for this does now exist in RestEasy).
>>>
>>> AeroGear controller's REST support started out very simple but as time
passed more request for things that are taken for granted in a JAX-RS implementation were
being asked for. We were moving toward something equivalent to a JAX-RS implementation
with regards to what we supported. Adding more of these features added to the complexity
of the Controller as we needed to figure out good ways to provide the features requested,
and this also brings up the question if we should be doing this. The controller is not
specific to mobil, as any backend can be used with the client SDKs. Also, there are plenty
of options to implement RESTful backends, in Java using RestEasy for example, or in a
different language.
>>>
>>> And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for example the
Unified Push Server and SimplePush Server etc.
>>>
>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>>
>>> A clear notice in the README.md is a good start. Should we mark every class
as deprecated as well?
>>>
>>> These are just suggestions and if you have other ideas please let us know.
>>>
>>> /Dan
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:07 p.m.
Though I am mostly on board with the idea of deprecating the REST bits of controller, I
guess what I'm trying to figure out is when this was decided. I heard some passing
mentions of controller getting beyond its initial scope, etc. but a discussion around
deprecation/removal never happened that I am aware of. I think a combination of this
e-mail and parts of Dan's would have been nice before we got an e-mail stating that
the deprecation was happening and asking how we should go about it.
On Jun 9, 2013, at 10:01 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
Some of my thoughts:
The concern I have with leaving the REST bits as they are is confusion in what should be
used, and when. If we're not going to be enhancing the REST support, we should
deprecate it imo.
If the controller's MVC functionality is going to move forward (i.e. not be
deprecated) we should plan for its future carefully so that it works well with the REST
support provided by JAX-RS /RESTEasy. I'm just not sure of the priority over other
things atm. So it might be the type of thing where we take it where we can, and see if
there is community interest in moving it forward.
I certainly would like to see a solid MVC be standardized in EE(X), and it might be in
the future. However, there are a lot of different mvc frameworks out there and I'm
concerned over trying to create another, especially if it seems our functionality is tied
to it.
Either way, we should update our examples to show how to use our technology with
RESTEasy, with or without the controller and/or other mvc options. So that users know they
have options here.
On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
> I'm not sure deprecation is necessary but I would vote with Bruno to just leave
the REST bits as is and ensure nothing else depends on them. Then we just make a note in
the README that we have discontinued development and support on them. Then remove any
references from AeroGear.org and only talk about our other server side bits.
>
> On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
>> Ok, I almost had a heart attack here :) I'd say leave the REST bits as is and
give to people a choice.
>>
>> -
>> abstractj
>>
>> On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>>
>>> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>> I should have written, deprecate the RESTful part of AeroGear controller, as
this is really what has been discussed.
>>> If it makes sense to keep the MVC parts we can certainly do that.
>>>
>>>
>>>
>>>
>>> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>> Aloha Daniel,
>>>
>>>
>>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>>
>>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>>
>>> -
>>> abstractj
>>>
>>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>>
>>>> Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added support for
RESTful endpoints which was very basic to start with, but more and more feature requests
have come which is the reason for creating this email.
>>>>
>>>> We did not set out to implement the RESTful support our selves, instead
the goal was to use RestEasy but as we required to be able to programmatically add
endpoints which was not an option at the time (but support for this does now exist in
RestEasy).
>>>>
>>>> AeroGear controller's REST support started out very simple but as
time passed more request for things that are taken for granted in a JAX-RS implementation
were being asked for. We were moving toward something equivalent to a JAX-RS
implementation with regards to what we supported. Adding more of these features added to
the complexity of the Controller as we needed to figure out good ways to provide the
features requested, and this also brings up the question if we should be doing this. The
controller is not specific to mobil, as any backend can be used with the client SDKs.
Also, there are plenty of options to implement RESTful backends, in Java using RestEasy
for example, or in a different language.
>>>>
>>>> And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for example the
Unified Push Server and SimplePush Server etc.
>>>>
>>>> So how do we make it visible that we have deprecated AeroGear-Controller?
>>>>
>>>> A clear notice in the README.md is a good start. Should we mark every
class as deprecated as well?
>>>>
>>>> These are just suggestions and if you have other ideas please let us
know.
>>>>
>>>> /Dan
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:15 p.m.
I think a combination of this e-mail and parts of Dan's would
have been
nice before we got an e-mail stating that the deprecation was happening
and
asking how we should go about it.
I'm to blame for this not being as open as it probably could have. The line
of what is public and what in internal was a little blurred, and I opted to
be careful, so the discussions have been mostly over private channels.
The concern I have with leaving the REST bits as they are is confusion
in
what should be used, and when. If we're not going to be enhancing the REST
support, we should deprecate it imo.
I agree with this.
On 10 June 2013 05:07, Kris Borchers <kris(a)redhat.com> wrote:
Though I am mostly on board with the idea of deprecating the REST
bits of
controller, I guess what I'm trying to figure out is when this was decided.
I heard some passing mentions of controller getting beyond its initial
scope, etc. but a discussion around deprecation/removal never happened that
I am aware of. I think a combination of this e-mail and parts of Dan's
would have been nice before we got an e-mail stating that the deprecation
was happening and asking how we should go about it.
On Jun 9, 2013, at 10:01 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
Some of my thoughts:
The concern I have with leaving the REST bits as they are is confusion in
what should be used, and when. If we're not going to be enhancing the REST
support, we should deprecate it imo.
If the controller's MVC functionality is going to move forward (i.e. not
be deprecated) we should plan for its future carefully so that it works
well with the REST support provided by JAX-RS /RESTEasy. I'm just not sure
of the priority over other things atm. So it might be the type of thing
where we take it where we can, and see if there is community interest in
moving it forward.
I certainly would like to see a solid MVC be standardized in EE(X), and it
might be in the future. However, there are a lot of different mvc
frameworks out there and I'm concerned over trying to create another,
especially if it seems our functionality is tied to it.
Either way, we should update our examples to show how to use our
technology with RESTEasy, with or without the controller and/or other mvc
options. So that users know they have options here.
On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
I'm not sure deprecation is necessary but I would vote with Bruno to just
leave the REST bits as is and ensure nothing else depends on them. Then we
just make a note in the README that we have discontinued development and
support on them. Then remove any references from
AeroGear.org<http://aerogear.org/>and only talk about our other server side bits.
On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Ok, I almost had a heart attack here :) I'd say leave the REST bits as is
and give to people a choice.
-
abstractj
On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>Deprecate?! Why?! Do we have a lightweight MVC to replace?
I should have written, deprecate the RESTful part of AeroGear controller,
as this is really what has been discussed.
If it makes sense to keep the MVC parts we can certainly do that.
On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Aloha Daniel,
>
>
> So how do we make it visible that we have deprecated AeroGear-Controller?
>
>
> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>
> -
> abstractj
>
> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>
> Originally, AeroGear Controller was an MVC only implementation, where
> requests could be forwarded to different types of views. Later we added
> support for RESTful endpoints which was very basic to start with, but more
> and more feature requests have come which is the reason for creating this
> email.
>
> We did not set out to implement the RESTful support our selves, instead
> the goal was to use RestEasy but as we required to be able to
> programmatically add endpoints which was not an option at the time (but
> support for this does now exist in RestEasy).
>
> AeroGear controller's REST support started out very simple but as time
> passed more request for things that are taken for granted in a JAX-RS
> implementation were being asked for. We were moving toward something
> equivalent to a JAX-RS implementation with regards to what we supported.
> Adding more of these features added to the complexity of the Controller as
> we needed to figure out good ways to provide the features requested, and
> this also brings up the question if we should be doing this. The controller
> is not specific to mobil, as any backend can be used with the client SDKs.
> Also, there are plenty of options to implement RESTful backends, in Java
> using RestEasy for example, or in a different language.
>
> And after some discussions it has been decided that we should focus are
> efforts in other places when it comes to our server side offerings, for
> example the Unified Push Server and SimplePush Server etc.
>
> So how do we make it visible that we have deprecated AeroGear-Controller?
>
> A clear notice in the README.md is a good start. Should we mark every
> class as deprecated as well?
>
> These are just suggestions and if you have other ideas please let us
> know.
>
> /Dan
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:06 a.m.
To be honest, I'm not sure it's relevant to make the distinction between
Controller with or without REST support. We are in 2013, I'm not using the
Controller to render JSPs, especially not in a mobile scope with our Front
End libraries which are REST focused. I was using the controller because I
could describe with a fluent API my (rest) routes and integrate seamlessly
my security concerns.
On Mon, Jun 10, 2013 at 6:15 AM, Daniel Bevenius
<daniel.bevenius(a)gmail.com>wrote:
> I think a combination of this e-mail and parts of Dan's
would have
been nice before we got an e-mail stating that the deprecation was
happening and asking how we should go about it.
I'm to blame for this not being as open as it probably could have. The
line of what is public and what in internal was a little blurred, and I
opted to be careful, so the discussions have been mostly over private
channels.
>The concern I have with leaving the REST bits as they are is confusion
in what should be used, and when. If we're not going to be enhancing the
REST support, we should deprecate it imo.
I agree with this.
On 10 June 2013 05:07, Kris Borchers <kris(a)redhat.com> wrote:
> Though I am mostly on board with the idea of deprecating the REST bits of
> controller, I guess what I'm trying to figure out is when this was decided.
> I heard some passing mentions of controller getting beyond its initial
> scope, etc. but a discussion around deprecation/removal never happened that
> I am aware of. I think a combination of this e-mail and parts of Dan's
> would have been nice before we got an e-mail stating that the deprecation
> was happening and asking how we should go about it.
>
> On Jun 9, 2013, at 10:01 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
>
> Some of my thoughts:
>
> The concern I have with leaving the REST bits as they are is confusion in
> what should be used, and when. If we're not going to be enhancing the REST
> support, we should deprecate it imo.
>
> If the controller's MVC functionality is going to move forward (i.e. not
> be deprecated) we should plan for its future carefully so that it works
> well with the REST support provided by JAX-RS /RESTEasy. I'm just not sure
> of the priority over other things atm. So it might be the type of thing
> where we take it where we can, and see if there is community interest in
> moving it forward.
>
> I certainly would like to see a solid MVC be standardized in EE(X), and
> it might be in the future. However, there are a lot of different mvc
> frameworks out there and I'm concerned over trying to create another,
> especially if it seems our functionality is tied to it.
>
> Either way, we should update our examples to show how to use our
> technology with RESTEasy, with or without the controller and/or other mvc
> options. So that users know they have options here.
>
>
> On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
>
> I'm not sure deprecation is necessary but I would vote with Bruno to just
> leave the REST bits as is and ensure nothing else depends on them. Then we
> just make a note in the README that we have discontinued development and
> support on them. Then remove any references from
AeroGear.org<http://aerogear.org/>and only talk about our other server side bits.
>
> On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
> Ok, I almost had a heart attack here :) I'd say leave the REST bits as is
> and give to people a choice.
>
> -
> abstractj
>
> On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>
> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
> I should have written, deprecate the RESTful part of AeroGear controller,
> as this is really what has been discussed.
> If it makes sense to keep the MVC parts we can certainly do that.
>
>
>
>
> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
>> Aloha Daniel,
>>
>>
>> So how do we make it visible that we have deprecated
>> AeroGear-Controller?
>>
>>
>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>
>> -
>> abstractj
>>
>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>
>> Originally, AeroGear Controller was an MVC only implementation, where
>> requests could be forwarded to different types of views. Later we added
>> support for RESTful endpoints which was very basic to start with, but more
>> and more feature requests have come which is the reason for creating this
>> email.
>>
>> We did not set out to implement the RESTful support our selves, instead
>> the goal was to use RestEasy but as we required to be able to
>> programmatically add endpoints which was not an option at the time (but
>> support for this does now exist in RestEasy).
>>
>> AeroGear controller's REST support started out very simple but as time
>> passed more request for things that are taken for granted in a JAX-RS
>> implementation were being asked for. We were moving toward something
>> equivalent to a JAX-RS implementation with regards to what we supported.
>> Adding more of these features added to the complexity of the Controller as
>> we needed to figure out good ways to provide the features requested, and
>> this also brings up the question if we should be doing this. The controller
>> is not specific to mobil, as any backend can be used with the client SDKs.
>> Also, there are plenty of options to implement RESTful backends, in Java
>> using RestEasy for example, or in a different language.
>>
>> And after some discussions it has been decided that we should focus are
>> efforts in other places when it comes to our server side offerings, for
>> example the Unified Push Server and SimplePush Server etc.
>>
>> So how do we make it visible that we have deprecated
>> AeroGear-Controller?
>>
>> A clear notice in the README.md is a good start. Should we mark every
>> class as deprecated as well?
>>
>> These are just suggestions and if you have other ideas please let us
>> know.
>>
>> /Dan
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:37 p.m.
Sebastien,
Does this affect the Aerogear scaffolding plugin in Forge?
-Rodney
----- Original Message -----
To be honest, I'm not sure it's relevant to make the
distinction between
Controller with or without REST support. We are in 2013, I'm not using the
Controller to render JSPs, especially not in a mobile scope with our Front
End libraries which are REST focused. I was using the controller because I
could describe with a fluent API my (rest) routes and integrate seamlessly
my security concerns.
On Mon, Jun 10, 2013 at 6:15 AM, Daniel Bevenius <
daniel.bevenius(a)gmail.com
> wrote:
> > I think a combination of this e-mail and parts of Dan's
would have been
> > nice before we got an e-mail stating that the deprecation was happening
> > and asking how we should go about it.
> I'm to blame for this not being as open as it probably could have. The line
> of what is public and what in internal was a little blurred, and I opted to
> be careful, so the discussions have been mostly over private channels.
> > The concern I have with leaving the REST bits as they are
is confusion in
> > what should be used, and when. If we're not going to be enhancing the
> > REST
> > support, we should deprecate it imo.
> I agree with this.
> On 10 June 2013 05:07, Kris Borchers < kris(a)redhat.com >
wrote:
> > Though I am mostly on board with the idea of deprecating
the REST bits of
> > controller, I guess what I'm trying to figure out is when this was
> > decided.
> > I heard some passing mentions of controller getting beyond its initial
> > scope, etc. but a discussion around deprecation/removal never happened
> > that
> > I am aware of. I think a combination of this e-mail and parts of Dan's
> > would
> > have been nice before we got an e-mail stating that the deprecation was
> > happening and asking how we should go about it.
>
> > On Jun 9, 2013, at 10:01 PM, Jay Balunas <
jbalunas(a)redhat.com > wrote:
>
> > > Some of my thoughts:
> >
>
> > > The concern I have with leaving the REST bits as they
are is confusion
> > > in
> > > what should be used, and when. If we're not going to be enhancing the
> > > REST
> > > support, we should deprecate it imo.
> >
>
> > > If the controller's MVC functionality is going to
move forward (i.e.
> > > not
> > > be
> > > deprecated) we should plan for its future carefully so that it works
> > > well
> > > with the REST support provided by JAX-RS /RESTEasy. I'm just not sure
> > > of
> > > the
> > > priority over other things atm. So it might be the type of thing where
> > > we
> > > take it where we can, and see if there is community interest in moving
> > > it
> > > forward.
> >
>
> > > I certainly would like to see a solid MVC be
standardized in EE(X), and
> > > it
> > > might be in the future. However, there are a lot of different mvc
> > > frameworks
> > > out there and I'm concerned over trying to create another, especially
> > > if
> > > it
> > > seems our functionality is tied to it.
> >
>
> > > Either way, we should update our examples to show how
to use our
> > > technology
> > > with RESTEasy, with or without the controller and/or other mvc options.
> > > So
> > > that users know they have options here.
> >
>
> > > On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
> >
>
> > > > I'm not sure deprecation is necessary but I
would vote with Bruno to
> > > > just
> > > > leave the REST bits as is and ensure nothing else depends on them.
> > > > Then
> > > > we
> > > > just make a note in the README that we have discontinued development
> > > > and
> > > > support on them. Then remove any references from AeroGear.org and
> > > > only
> > > > talk
> > > > about our other server side bits.
> > >
> >
>
> > > > On Jun 9, 2013, at 9:03, Bruno Oliveira <
bruno(a)abstractj.org >
> > > > wrote:
> > >
> >
>
> > > > > Ok, I almost had a heart attack here :)
I'd say leave the REST bits
> > > > > as
> > > > > is
> > > > > and
> > > > > give to people a choice.
> > > >
> > >
> >
>
> > > > > -
> > > >
> > >
> >
>
> > > > > abstractj
> > > >
> > >
> >
>
> > > > > On Jun 9, 2013, 10:57 AM, Daniel Bevenius
wrote:
> > > >
> > >
> >
>
> > > > > > > Deprecate?! Why?! Do we have a
lightweight MVC to replace?
> > > > >
> > > >
> > >
> >
>
> > > > > > I should have written, deprecate the RESTful part of
AeroGear
> > > > > > controller,
> > > > > > as
> > > > > > this is really what has been discussed.
> > > > >
> > > >
> > >
> >
>
> > > > > > If it makes sense to keep the MVC parts we can certainly do
that.
> > > > >
> > > >
> > >
> >
>
> > > > > > On 9 June 2013 15:51, Bruno Oliveira
< bruno(a)abstractj.org >
> > > > > > wrote:
> > > > >
> > > >
> > >
> >
>
> > > > > > > Aloha Daniel,
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > So how do we make it visible
that we have deprecated
> > > > > > > > AeroGear-Controller?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > Deprecate?! Why?! Do we have a
lightweight MVC to replace?
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > -
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > abstractj
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > On Jun 9, 2013, 8:25 AM, Daniel
Bevenius wrote:
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > Originally, AeroGear
Controller was an MVC only
> > > > > > > > implementation,
> > > > > > > > where
> > > > > > > > requests could be forwarded to different types of
views.
> > > > > > > > Later
> > > > > > > > we
> > > > > > > > added
> > > > > > > > support for RESTful endpoints which was very
basic to start
> > > > > > > > with,
> > > > > > > > but
> > > > > > > > more
> > > > > > > > and more feature requests have come which is the
reason for
> > > > > > > > creating
> > > > > > > > this
> > > > > > > > email.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > We did not set out to
implement the RESTful support our
> > > > > > > > selves,
> > > > > > > > instead
> > > > > > > > the
> > > > > > > > goal was to use RestEasy but as we required to be
able to
> > > > > > > > programmatically
> > > > > > > > add endpoints which was not an option at the time
(but
> > > > > > > > support
> > > > > > > > for
> > > > > > > > this
> > > > > > > > does
> > > > > > > > now exist in RestEasy).
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > AeroGear controller's
REST support started out very simple
> > > > > > > > but
> > > > > > > > as
> > > > > > > > time
> > > > > > > > passed
> > > > > > > > more request for things that are taken for
granted in a
> > > > > > > > JAX-RS
> > > > > > > > implementation were being asked for. We were
moving toward
> > > > > > > > something
> > > > > > > > equivalent to a JAX-RS implementation with
regards to what we
> > > > > > > > supported.
> > > > > > > > Adding more of these features added to the
complexity of the
> > > > > > > > Controller
> > > > > > > > as
> > > > > > > > we needed to figure out good ways to provide the
features
> > > > > > > > requested,
> > > > > > > > and
> > > > > > > > this also brings up the question if we should be
doing this.
> > > > > > > > The
> > > > > > > > controller
> > > > > > > > is not specific to mobil, as any backend can be
used with the
> > > > > > > > client
> > > > > > > > SDKs.
> > > > > > > > Also, there are plenty of options to implement
RESTful
> > > > > > > > backends,
> > > > > > > > in
> > > > > > > > Java
> > > > > > > > using RestEasy for example, or in a different
language.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > And after some discussions it
has been decided that we should
> > > > > > > > focus
> > > > > > > > are
> > > > > > > > efforts in other places when it comes to our
server side
> > > > > > > > offerings,
> > > > > > > > for
> > > > > > > > example the Unified Push Server and SimplePush
Server etc.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > So how do we make it visible
that we have deprecated
> > > > > > > > AeroGear-Controller?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > A clear notice in the
README.md is a good start. Should we
> > > > > > > > mark
> > > > > > > > every
> > > > > > > > class
> > > > > > > > as deprecated as well?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > These are just suggestions
and if you have other ideas please
> > > > > > > > let
> > > > > > > > us
> > > > > > > > know.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > /Dan
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > >
_______________________________________________
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > aerogear-dev mailing list
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > aerogear-dev(a)lists.jboss.org
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > >
_______________________________________________
> > > >
> > >
> >
>
> > > > > aerogear-dev mailing list
> > > >
> > >
> >
>
> > > > > aerogear-dev(a)lists.jboss.org
> > > >
> > >
> >
>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> >
>
> > > > _______________________________________________
> > >
> >
>
> > > > aerogear-dev mailing list
> > >
> >
>
> > > > aerogear-dev(a)lists.jboss.org
> > >
> >
>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
>
> > > _______________________________________________
> >
>
> > > aerogear-dev mailing list
> >
>
> > > aerogear-dev(a)lists.jboss.org
> >
>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
> > _______________________________________________
>
> > aerogear-dev mailing list
>
> > aerogear-dev(a)lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:56 p.m.
Hey Rodney,
Well, the (technical) impact is not that big, as you could configure the
plugin to not use the controller. But regarding security scaffolding, it's
heavily based on the controller in combination with aerogear security, the
client security scaffolding will remain unchanged (but there wasn't happen
very much things there for the moment).
So, basically if we want to offer the same (backend) security scaffolding
features but without the controller, the refactoring could be bigger and
could evolve changes on other third party forge plugins (like the REST
plugin).
Seb
On Mon, Jun 10, 2013 at 9:37 PM, Rodney Russ <rruss(a)redhat.com> wrote:
Sebastien,
Does this affect the Aerogear scaffolding plugin in Forge?
-Rodney
------------------------------
To be honest, I'm not sure it's relevant to make the distinction between
Controller with or without REST support. We are in 2013, I'm not using the
Controller to render JSPs, especially not in a mobile scope with our Front
End libraries which are REST focused. I was using the controller because I
could describe with a fluent API my (rest) routes and integrate seamlessly
my security concerns.
On Mon, Jun 10, 2013 at 6:15 AM, Daniel Bevenius <
daniel.bevenius(a)gmail.com> wrote:
> > I think a combination of this e-mail and parts of Dan's would have
> been nice before we got an e-mail stating that the deprecation was
> happening and asking how we should go about it.
> I'm to blame for this not being as open as it probably could have. The
> line of what is public and what in internal was a little blurred, and I
> opted to be careful, so the discussions have been mostly over private
> channels.
>
> >The concern I have with leaving the REST bits as they are is confusion
> in what should be used, and when. If we're not going to be enhancing the
> REST support, we should deprecate it imo.
> I agree with this.
>
>
>
>
> On 10 June 2013 05:07, Kris Borchers <kris(a)redhat.com> wrote:
>
>> Though I am mostly on board with the idea of deprecating the REST bits
>> of controller, I guess what I'm trying to figure out is when this was
>> decided. I heard some passing mentions of controller getting beyond its
>> initial scope, etc. but a discussion around deprecation/removal never
>> happened that I am aware of. I think a combination of this e-mail and parts
>> of Dan's would have been nice before we got an e-mail stating that the
>> deprecation was happening and asking how we should go about it.
>>
>> On Jun 9, 2013, at 10:01 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
>>
>> Some of my thoughts:
>>
>> The concern I have with leaving the REST bits as they are is confusion
>> in what should be used, and when. If we're not going to be enhancing the
>> REST support, we should deprecate it imo.
>>
>> If the controller's MVC functionality is going to move forward (i.e. not
>> be deprecated) we should plan for its future carefully so that it works
>> well with the REST support provided by JAX-RS /RESTEasy. I'm just not sure
>> of the priority over other things atm. So it might be the type of thing
>> where we take it where we can, and see if there is community interest in
>> moving it forward.
>>
>> I certainly would like to see a solid MVC be standardized in EE(X), and
>> it might be in the future. However, there are a lot of different mvc
>> frameworks out there and I'm concerned over trying to create another,
>> especially if it seems our functionality is tied to it.
>>
>> Either way, we should update our examples to show how to use our
>> technology with RESTEasy, with or without the controller and/or other mvc
>> options. So that users know they have options here.
>>
>>
>> On Jun 9, 2013, at 11:40 AM, Kris Borchers wrote:
>>
>> I'm not sure deprecation is necessary but I would vote with Bruno to
>> just leave the REST bits as is and ensure nothing else depends on them.
>> Then we just make a note in the README that we have discontinued
>> development and support on them. Then remove any references from
>> AeroGear.org <http://aerogear.org/> and only talk about our other
>> server side bits.
>>
>> On Jun 9, 2013, at 9:03, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>> Ok, I almost had a heart attack here :) I'd say leave the REST bits as
>> is and give to people a choice.
>>
>> -
>> abstractj
>>
>> On Jun 9, 2013, 10:57 AM, Daniel Bevenius wrote:
>>
>> >Deprecate?! Why?! Do we have a lightweight MVC to replace?
>> I should have written, deprecate the RESTful part of AeroGear
>> controller, as this is really what has been discussed.
>> If it makes sense to keep the MVC parts we can certainly do that.
>>
>>
>>
>>
>> On 9 June 2013 15:51, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>>> Aloha Daniel,
>>>
>>>
>>> So how do we make it visible that we have deprecated
>>> AeroGear-Controller?
>>>
>>>
>>> Deprecate?! Why?! Do we have a lightweight MVC to replace?
>>>
>>> -
>>> abstractj
>>>
>>> On Jun 9, 2013, 8:25 AM, Daniel Bevenius wrote:
>>>
>>> Originally, AeroGear Controller was an MVC only implementation, where
>>> requests could be forwarded to different types of views. Later we added
>>> support for RESTful endpoints which was very basic to start with, but more
>>> and more feature requests have come which is the reason for creating this
>>> email.
>>>
>>> We did not set out to implement the RESTful support our selves, instead
>>> the goal was to use RestEasy but as we required to be able to
>>> programmatically add endpoints which was not an option at the time (but
>>> support for this does now exist in RestEasy).
>>>
>>> AeroGear controller's REST support started out very simple but as time
>>> passed more request for things that are taken for granted in a JAX-RS
>>> implementation were being asked for. We were moving toward something
>>> equivalent to a JAX-RS implementation with regards to what we supported.
>>> Adding more of these features added to the complexity of the Controller as
>>> we needed to figure out good ways to provide the features requested, and
>>> this also brings up the question if we should be doing this. The controller
>>> is not specific to mobil, as any backend can be used with the client SDKs.
>>> Also, there are plenty of options to implement RESTful backends, in Java
>>> using RestEasy for example, or in a different language.
>>>
>>> And after some discussions it has been decided that we should focus are
>>> efforts in other places when it comes to our server side offerings, for
>>> example the Unified Push Server and SimplePush Server etc.
>>>
>>> So how do we make it visible that we have deprecated
>>> AeroGear-Controller?
>>>
>>> A clear notice in the README.md is a good start. Should we mark every
>>> class as deprecated as well?
>>>
>>> These are just suggestions and if you have other ideas please let us
>>> know.
>>>
>>> /Dan
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4203
days inactive
4204
days old
12 comments
8 participants
participants (8)
-
Bruno Oliveira -
Daniel Bevenius -
Jay Balunas -
Kris Borchers -
Kris Borchers -
Rodney Russ -
Sebastien Blanc -
Sébastien Blanc