Meecrowave Roadmap

[Remo Meier <re...@adnovum.ch>]

Hi

I would have a number of questions and feedback about Meecrowave. I may 
also be able to contribute a few things.

1. Is there any alignment planned with EE4J or micro-profile? In 
contrast to other approaches like Wildfly Swarm, Meecrowave for sure is 
a big step in the right direction for JEE IMHO.

2. Will it stay a openwebbeans thing? Or are you also interested in 
contributions from other JEE vendors? My company is married to Weld & 
Hibernate for example, but likes Deltaspike, Tomcat and CXF from the 
Apache side. With CDI and Jigsaw I would expect something like this to 
work in the future with JEE.

3. Asciidoc for documentation would be great.

4. I'm not so familiar with the Apache guidelines regarding 
collaboration. But Git, Github presence, Travis, Sonar, Gitter or 
similar would be great to have.

5. In terms of missing features and contributions, for example JSR 352 
Batch (like jberet), Weld, metrics, health checks, configuration API, 
Hibernate and opinionated Gradle plugins to create RPMs (with systemd 
integration) and docker would be great to have.

Regards Remo

Re: Meecrowave Roadmap

[Remo Meier <re...@adnovum.ch>]

Thx for all the answers and pointers. No more questions currently, have 
to investigate a bit further, maybe just some input:

1. I did not notice the documentation is already in asciidoc. The single 
page flavor of it could potentially be nice to have (like 
http://www.crnk.io/documentation/).

2. "as it is pretty tightly bound to OWB." & "but a highly integrated 
asf stack". It would be nice to see that EE4J or microprofile align a 
bit in this direction. Standardizing the API from Meecroware and make it 
accessible to all the vendors as one possibility. Spring Boot and 
Dropwizard let the way in the area and are successful. And with Jigsaw 
Java 9 moves in this direction as well. As you mentioned that seems 
currently unlikely. Maybe one of the vendors opening up a bit could be a 
start... :-) Or start to facilitate these manual approaches like Hammock 
a bit more by splitting up the JTA spec and implementations (I barely 
see anybody making use of the distributed features), avoiding 
dependencies to APIs like JNDI or having a configuration/health/metrics 
spec in place.

I will look at bit more into hammock and MB. But e.g. the depenency to 
Hibernate for our applications is high. So flexibility is one of the 
important things for us.

Regards Remo



Am 02.10.2017 um 09:26 schrieb Mark Struberg:
> To answer a few questions:
>
> Meecrowave will likely remain an OWB subproject as it is pretty tightly bound to OWB.
> As Thomas already explained: if you stick to the CDI spec then both should give you the same features.
> And yes, OWB still performs 2..3x better than Weld and is also much smaller. Used to be 50..200x compared to former Weld versions.
>
> If you want to use a Server which is portable between Weld and OWB then you might enjoy looking at John Aments Hammock project.
> Different goals, different pros and cons coming with it of course.
>
> Do we plan to incorporate MP parts out of the box?
> Hmm not sure myself to be honest as all this can easily added by just adding a dependency. And that way you are totally flexible regarding versioning.
> We might change is in the future probably, but for now it doesn't look that way. Note that I'm saying this despite I'm one of the Microprofile spec authors and I really like MP.
> But it's really so easy to add that it doesn't put any burden to the user but adds flexibility to _not_ have it by default.
>
> Otoh add a few samples an also add some ITs in the future might be a good idea!
>
> Oh and thanks for your question!
> Just ping us if you have any question comint to your mind.
>
> txs and LieGrue,
> strub
>
>> Am 01.10.2017 um 22:22 schrieb Thomas Andraschko <an...@gmail.com>:
>>
>> Some additions about Weld <> OWB:
>> Please also note that there are almost no reasons that application code must depend on Weld or OWB. The behavior of both implementations are almost identical.
>> In the past OWB had (much) better performance, mem size and disk size. Not sure how much is the difference today.
>>
>> IMO there is no reason that you should stick to a specific CDI impl, nor that we should support Weld.
>>
>> 2017-10-01 19:56 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>> Hi Remo,
>>
>> Le 1 oct. 2017 18:56, "Remo Meier" <re...@adnovum.ch> a écrit :
>> Hi
>>
>> I would have a number of questions and feedback about Meecrowave. I may also be able to contribute a few things.
>>
>> 1. Is there any alignment planned with EE4J or micro-profile? In contrast to other approaches like Wildfly Swarm, Meecrowave for sure is a big step in the right direction for JEE IMHO.
>>
>> No but since MP is just a set of cdi extensions no blocker to use it. FYI it is done at geronimo project.
>>
>> Same applies for JavaEE or EE4J. In particular since one goal of Meecrowave was to keep only good things of EE we will probably not grow too much.
>>
>> Anything special you are thinking about?
>>
>>
>> 2. Will it stay a openwebbeans thing? Or are you also interested in contributions from other JEE vendors? My company is married to Weld & Hibernate for example, but likes Deltaspike, Tomcat and CXF from the Apache side. With CDI and Jigsaw I would expect something like this to work in the future with JEE.
>>
>> Not sure I get it, it will stay an OWB subproject which doesnt prevent contributions - we already got some ;).
>>
>>
>> 3. Asciidoc for documentation would be great.
>>
>>
>> It is the case, see doc module.
>>
>> 4. I'm not so familiar with the Apache guidelines regarding collaboration. But Git, Github presence, Travis, Sonar, Gitter or similar would be great to have.
>>
>> We are on github, we can have a sonar at asf - dont wait for me for that since i have only bad experiences with it ;), no blocker for travis AFAIK.
>>
>>
>> 5. In terms of missing features and contributions, for example JSR 352 Batch (like jberet), Weld, metrics, health checks, configuration API, Hibernate and opinionated Gradle plugins to create RPMs (with systemd integration) and docker would be great to have.
>>
>> Batchee works OOTB with meecrowave - for jbatch, weld will not be integrated since we dont aim to be portable between spec vendors but a highly integrated asf stack, others parts are already covered elsewhere with cdi extensions or build tools (even if here we intentionally integrate more with mvn).
>>
>> For the config deltaspike or geronimo config are good fit, sirona for the monitoring works well - or metrics-cdi if you prefer, hibernate works well with deltaspike or jpa meecrowave extension.
>>
>>
>>
>> Regards Remo
>>
>>
>
> .

Re: Meecrowave Roadmap

[Mark Struberg <st...@yahoo.de>]

To answer a few questions:

Meecrowave will likely remain an OWB subproject as it is pretty tightly bound to OWB. 
As Thomas already explained: if you stick to the CDI spec then both should give you the same features. 
And yes, OWB still performs 2..3x better than Weld and is also much smaller. Used to be 50..200x compared to former Weld versions.

If you want to use a Server which is portable between Weld and OWB then you might enjoy looking at John Aments Hammock project.
Different goals, different pros and cons coming with it of course.

Do we plan to incorporate MP parts out of the box?
Hmm not sure myself to be honest as all this can easily added by just adding a dependency. And that way you are totally flexible regarding versioning.
We might change is in the future probably, but for now it doesn't look that way. Note that I'm saying this despite I'm one of the Microprofile spec authors and I really like MP.
But it's really so easy to add that it doesn't put any burden to the user but adds flexibility to _not_ have it by default. 

Otoh add a few samples an also add some ITs in the future might be a good idea!

Oh and thanks for your question!
Just ping us if you have any question comint to your mind.

txs and LieGrue,
strub

> Am 01.10.2017 um 22:22 schrieb Thomas Andraschko <an...@gmail.com>:
> 
> Some additions about Weld <> OWB:
> Please also note that there are almost no reasons that application code must depend on Weld or OWB. The behavior of both implementations are almost identical.
> In the past OWB had (much) better performance, mem size and disk size. Not sure how much is the difference today.
> 
> IMO there is no reason that you should stick to a specific CDI impl, nor that we should support Weld.
> 
> 2017-10-01 19:56 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> Hi Remo,
> 
> Le 1 oct. 2017 18:56, "Remo Meier" <re...@adnovum.ch> a écrit :
> Hi
> 
> I would have a number of questions and feedback about Meecrowave. I may also be able to contribute a few things.
> 
> 1. Is there any alignment planned with EE4J or micro-profile? In contrast to other approaches like Wildfly Swarm, Meecrowave for sure is a big step in the right direction for JEE IMHO.
> 
> No but since MP is just a set of cdi extensions no blocker to use it. FYI it is done at geronimo project.
> 
> Same applies for JavaEE or EE4J. In particular since one goal of Meecrowave was to keep only good things of EE we will probably not grow too much.
> 
> Anything special you are thinking about?
> 
> 
> 2. Will it stay a openwebbeans thing? Or are you also interested in contributions from other JEE vendors? My company is married to Weld & Hibernate for example, but likes Deltaspike, Tomcat and CXF from the Apache side. With CDI and Jigsaw I would expect something like this to work in the future with JEE.
> 
> Not sure I get it, it will stay an OWB subproject which doesnt prevent contributions - we already got some ;).
> 
> 
> 3. Asciidoc for documentation would be great.
> 
> 
> It is the case, see doc module.
> 
> 4. I'm not so familiar with the Apache guidelines regarding collaboration. But Git, Github presence, Travis, Sonar, Gitter or similar would be great to have.
> 
> We are on github, we can have a sonar at asf - dont wait for me for that since i have only bad experiences with it ;), no blocker for travis AFAIK.
> 
> 
> 5. In terms of missing features and contributions, for example JSR 352 Batch (like jberet), Weld, metrics, health checks, configuration API, Hibernate and opinionated Gradle plugins to create RPMs (with systemd integration) and docker would be great to have.
> 
> Batchee works OOTB with meecrowave - for jbatch, weld will not be integrated since we dont aim to be portable between spec vendors but a highly integrated asf stack, others parts are already covered elsewhere with cdi extensions or build tools (even if here we intentionally integrate more with mvn).
> 
> For the config deltaspike or geronimo config are good fit, sirona for the monitoring works well - or metrics-cdi if you prefer, hibernate works well with deltaspike or jpa meecrowave extension.
> 
> 
> 
> Regards Remo
> 
> 


.

Re: Meecrowave Roadmap

[Thomas Andraschko <an...@gmail.com>]

Some additions about Weld <> OWB:
Please also note that there are almost no reasons that application code
must depend on Weld or OWB. The behavior of both implementations are almost
identical.
In the past OWB had (much) better performance, mem size and disk size. Not
sure how much is the difference today.

IMO there is no reason that you should stick to a specific CDI impl, nor
that we should support Weld.

2017-10-01 19:56 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:

> Hi Remo,
>
> Le 1 oct. 2017 18:56, "Remo Meier" <re...@adnovum.ch> a écrit :
>
> Hi
>
> I would have a number of questions and feedback about Meecrowave. I may
> also be able to contribute a few things.
>
> 1. Is there any alignment planned with EE4J or micro-profile? In contrast
> to other approaches like Wildfly Swarm, Meecrowave for sure is a big step
> in the right direction for JEE IMHO.
>
>
> No but since MP is just a set of cdi extensions no blocker to use it. FYI
> it is done at geronimo project.
>
> Same applies for JavaEE or EE4J. In particular since one goal of
> Meecrowave was to keep only good things of EE we will probably not grow too
> much.
>
> Anything special you are thinking about?
>
>
> 2. Will it stay a openwebbeans thing? Or are you also interested in
> contributions from other JEE vendors? My company is married to Weld &
> Hibernate for example, but likes Deltaspike, Tomcat and CXF from the Apache
> side. With CDI and Jigsaw I would expect something like this to work in the
> future with JEE.
>
>
> Not sure I get it, it will stay an OWB subproject which doesnt prevent
> contributions - we already got some ;).
>
>
> 3. Asciidoc for documentation would be great.
>
>
>
> It is the case, see doc module.
>
>
> 4. I'm not so familiar with the Apache guidelines regarding collaboration.
> But Git, Github presence, Travis, Sonar, Gitter or similar would be great
> to have.
>
>
> We are on github, we can have a sonar at asf - dont wait for me for that
> since i have only bad experiences with it ;), no blocker for travis AFAIK.
>
>
> 5. In terms of missing features and contributions, for example JSR 352
> Batch (like jberet), Weld, metrics, health checks, configuration API,
> Hibernate and opinionated Gradle plugins to create RPMs (with systemd
> integration) and docker would be great to have.
>
>
> Batchee works OOTB with meecrowave - for jbatch, weld will not be
> integrated since we dont aim to be portable between spec vendors but a
> highly integrated asf stack, others parts are already covered elsewhere
> with cdi extensions or build tools (even if here we intentionally integrate
> more with mvn).
>
> For the config deltaspike or geronimo config are good fit, sirona for the
> monitoring works well - or metrics-cdi if you prefer, hibernate works well
> with deltaspike or jpa meecrowave extension.
>
>
>
> Regards Remo
>
>
>

Re: Meecrowave Roadmap

[Romain Manni-Bucau <rm...@gmail.com>]

Hi Remo,

Le 1 oct. 2017 18:56, "Remo Meier" <re...@adnovum.ch> a écrit :

Hi

I would have a number of questions and feedback about Meecrowave. I may
also be able to contribute a few things.

1. Is there any alignment planned with EE4J or micro-profile? In contrast
to other approaches like Wildfly Swarm, Meecrowave for sure is a big step
in the right direction for JEE IMHO.


No but since MP is just a set of cdi extensions no blocker to use it. FYI
it is done at geronimo project.

Same applies for JavaEE or EE4J. In particular since one goal of Meecrowave
was to keep only good things of EE we will probably not grow too much.

Anything special you are thinking about?


2. Will it stay a openwebbeans thing? Or are you also interested in
contributions from other JEE vendors? My company is married to Weld &
Hibernate for example, but likes Deltaspike, Tomcat and CXF from the Apache
side. With CDI and Jigsaw I would expect something like this to work in the
future with JEE.


Not sure I get it, it will stay an OWB subproject which doesnt prevent
contributions - we already got some ;).


3. Asciidoc for documentation would be great.



It is the case, see doc module.


4. I'm not so familiar with the Apache guidelines regarding collaboration.
But Git, Github presence, Travis, Sonar, Gitter or similar would be great
to have.


We are on github, we can have a sonar at asf - dont wait for me for that
since i have only bad experiences with it ;), no blocker for travis AFAIK.


5. In terms of missing features and contributions, for example JSR 352
Batch (like jberet), Weld, metrics, health checks, configuration API,
Hibernate and opinionated Gradle plugins to create RPMs (with systemd
integration) and docker would be great to have.


Batchee works OOTB with meecrowave - for jbatch, weld will not be
integrated since we dont aim to be portable between spec vendors but a
highly integrated asf stack, others parts are already covered elsewhere
with cdi extensions or build tools (even if here we intentionally integrate
more with mvn).

For the config deltaspike or geronimo config are good fit, sirona for the
monitoring works well - or metrics-cdi if you prefer, hibernate works well
with deltaspike or jpa meecrowave extension.



Regards Remo