You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@batchee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/01/02 07:05:34 UTC
Graduating....or not
Hi guys,
I'd like, before we graduate, to take the opportunity to discuss is that's
what we want.
Here a few facts and proposals associated with that statement:
I. Facts
1. JBatch is designed to work well with CDI but works smoothly in standalone
2. BatchEE allows to plug another artifact factory (the way you get jbatch
components) and therefore is compatible with any IoC, including
spring/guice/pico etc
3. Originally the goal to make BatchEE a TLP (this is why we went through
the incubator) was to ensure anyone (2.) can use BatchEE
4. Today, fact is that EE guys use it but other part of the ecosystem don't
embrace that for several good and bad reasons (for spring, spring-batch is
still preferred, some will use spark when not needed, some others will just
do a main - streams and lambda helped a lot to make this solution used more
than it should but it is the case)
At the end the original bet to embrace all ecosystem and unify the API
didn't make it.
II. Next steps for us
Therefore we have multiple options:
1. Retire and move the project on github somewhere (first proposal cause
likely not the one we want ;))
2. Graduate as expected
3. Move the project as a subproject of Geronimo. The rational being
Geronimo is an umbrella project for EE stuff @asf so it is a good fit for
BatchEE if we don't go TLP.
Due to the fact the communities overlap a lot and we kind of fail to do the
last steps for the graduation since long enough I'm tempted to say that 3
is likely the sanest for BatchEE today. I don't expect the BatchEE
community to grow a lot in the coming years so 2 will bring us more work
with not much gain IMHO.
Anyone seeing things differently?
Side note: if there is no strong objection this week I will likely call a
vote end of the week (friday?) about that.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Graduating....or not
Posted by Romain Manni-Bucau <rm...@gmail.com>.
will run the vote thread now
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 2 janv. 2019 à 21:41, Gerhard Petracek <gp...@apache.org> a
écrit :
> @mark:
> +1
>
> regards,
> gerhard
>
>
> Am Mi., 2. Jan. 2019 um 15:59 Uhr schrieb Mark Struberg
> <st...@yahoo.de.invalid>:
>
> > Yes, most likely the easiest is to move it to Geronimo.It has tons of
> use
> > and it's probably not lively enough to be a good TLP.But it is very
> useful
> > and a good code base.I'd definitely not want to dump it to github.
> > LieGrue,strub
> >
> > On Wednesday, 2 January 2019, 08:05:57 CET, Romain Manni-Bucau <
> > rmannibucau@gmail.com> wrote:
> >
> > Hi guys,
> >
> > I'd like, before we graduate, to take the opportunity to discuss is
> that's
> > what we want.
> >
> > Here a few facts and proposals associated with that statement:
> >
> > I. Facts
> >
> > 1. JBatch is designed to work well with CDI but works smoothly in
> > standalone
> > 2. BatchEE allows to plug another artifact factory (the way you get
> jbatch
> > components) and therefore is compatible with any IoC, including
> > spring/guice/pico etc
> > 3. Originally the goal to make BatchEE a TLP (this is why we went through
> > the incubator) was to ensure anyone (2.) can use BatchEE
> > 4. Today, fact is that EE guys use it but other part of the ecosystem
> don't
> > embrace that for several good and bad reasons (for spring, spring-batch
> is
> > still preferred, some will use spark when not needed, some others will
> just
> > do a main - streams and lambda helped a lot to make this solution used
> more
> > than it should but it is the case)
> >
> > At the end the original bet to embrace all ecosystem and unify the API
> > didn't make it.
> >
> > II. Next steps for us
> >
> > Therefore we have multiple options:
> >
> > 1. Retire and move the project on github somewhere (first proposal cause
> > likely not the one we want ;))
> > 2. Graduate as expected
> > 3. Move the project as a subproject of Geronimo. The rational being
> > Geronimo is an umbrella project for EE stuff @asf so it is a good fit for
> > BatchEE if we don't go TLP.
> >
> >
> > Due to the fact the communities overlap a lot and we kind of fail to do
> the
> > last steps for the graduation since long enough I'm tempted to say that 3
> > is likely the sanest for BatchEE today. I don't expect the BatchEE
> > community to grow a lot in the coming years so 2 will bring us more work
> > with not much gain IMHO.
> >
> > Anyone seeing things differently?
> >
> > Side note: if there is no strong objection this week I will likely call a
> > vote end of the week (friday?) about that.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>
Re: Graduating....or not
Posted by Gerhard Petracek <gp...@apache.org>.
@mark:
+1
regards,
gerhard
Am Mi., 2. Jan. 2019 um 15:59 Uhr schrieb Mark Struberg
<st...@yahoo.de.invalid>:
> Yes, most likely the easiest is to move it to Geronimo.It has tons of use
> and it's probably not lively enough to be a good TLP.But it is very useful
> and a good code base.I'd definitely not want to dump it to github.
> LieGrue,strub
>
> On Wednesday, 2 January 2019, 08:05:57 CET, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
> Hi guys,
>
> I'd like, before we graduate, to take the opportunity to discuss is that's
> what we want.
>
> Here a few facts and proposals associated with that statement:
>
> I. Facts
>
> 1. JBatch is designed to work well with CDI but works smoothly in
> standalone
> 2. BatchEE allows to plug another artifact factory (the way you get jbatch
> components) and therefore is compatible with any IoC, including
> spring/guice/pico etc
> 3. Originally the goal to make BatchEE a TLP (this is why we went through
> the incubator) was to ensure anyone (2.) can use BatchEE
> 4. Today, fact is that EE guys use it but other part of the ecosystem don't
> embrace that for several good and bad reasons (for spring, spring-batch is
> still preferred, some will use spark when not needed, some others will just
> do a main - streams and lambda helped a lot to make this solution used more
> than it should but it is the case)
>
> At the end the original bet to embrace all ecosystem and unify the API
> didn't make it.
>
> II. Next steps for us
>
> Therefore we have multiple options:
>
> 1. Retire and move the project on github somewhere (first proposal cause
> likely not the one we want ;))
> 2. Graduate as expected
> 3. Move the project as a subproject of Geronimo. The rational being
> Geronimo is an umbrella project for EE stuff @asf so it is a good fit for
> BatchEE if we don't go TLP.
>
>
> Due to the fact the communities overlap a lot and we kind of fail to do the
> last steps for the graduation since long enough I'm tempted to say that 3
> is likely the sanest for BatchEE today. I don't expect the BatchEE
> community to grow a lot in the coming years so 2 will bring us more work
> with not much gain IMHO.
>
> Anyone seeing things differently?
>
> Side note: if there is no strong objection this week I will likely call a
> vote end of the week (friday?) about that.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
Re: Graduating....or not
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Yes, most likely the easiest is to move it to Geronimo.It has tons of use and it's probably not lively enough to be a good TLP.But it is very useful and a good code base.I'd definitely not want to dump it to github.
LieGrue,strub
On Wednesday, 2 January 2019, 08:05:57 CET, Romain Manni-Bucau <rm...@gmail.com> wrote:
Hi guys,
I'd like, before we graduate, to take the opportunity to discuss is that's
what we want.
Here a few facts and proposals associated with that statement:
I. Facts
1. JBatch is designed to work well with CDI but works smoothly in standalone
2. BatchEE allows to plug another artifact factory (the way you get jbatch
components) and therefore is compatible with any IoC, including
spring/guice/pico etc
3. Originally the goal to make BatchEE a TLP (this is why we went through
the incubator) was to ensure anyone (2.) can use BatchEE
4. Today, fact is that EE guys use it but other part of the ecosystem don't
embrace that for several good and bad reasons (for spring, spring-batch is
still preferred, some will use spark when not needed, some others will just
do a main - streams and lambda helped a lot to make this solution used more
than it should but it is the case)
At the end the original bet to embrace all ecosystem and unify the API
didn't make it.
II. Next steps for us
Therefore we have multiple options:
1. Retire and move the project on github somewhere (first proposal cause
likely not the one we want ;))
2. Graduate as expected
3. Move the project as a subproject of Geronimo. The rational being
Geronimo is an umbrella project for EE stuff @asf so it is a good fit for
BatchEE if we don't go TLP.
Due to the fact the communities overlap a lot and we kind of fail to do the
last steps for the graduation since long enough I'm tempted to say that 3
is likely the sanest for BatchEE today. I don't expect the BatchEE
community to grow a lot in the coming years so 2 will bring us more work
with not much gain IMHO.
Anyone seeing things differently?
Side note: if there is no strong objection this week I will likely call a
vote end of the week (friday?) about that.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>