You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Thomas Andraschko <an...@gmail.com> on 2023/04/03 14:08:23 UTC
Jakarta EE / DeltaSpike 2.0 Status
Hi,
last week i had some time and migrated almost all still existing modules to
Jakarta. Only scheduler is currently not migrated.
AFAICS servlet, bean-validation has been removed, also other small pieces
of core.
I would also like to rename jpa and jsf to their new jakarta name
(persistence and faces).
WDYT guys?
After that rename and reintroduce the scheduler module, i would be happy
enough to release a RC1.
AFAICS a big missing part are the tests on real containers?!
Any other topics we need to address?
Best regards,
Thomas
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Thomas Andraschko <an...@gmail.com>.
RAT is fixed now
Only tests needs to be checked now, scheduler module would compile with
commenting 1 line but arquillian doesnt work
as i have absolutely no skill about arquillian, please someone take over
Am Sa., 8. Apr. 2023 um 01:01 Uhr schrieb Gerhard Petracek <
gpetracek@apache.org>:
> @mark: +1
>
> regards,
> gerhard
>
>
>
> Am Fr., 7. Apr. 2023 um 09:45 Uhr schrieb Mark Struberg
> <st...@yahoo.de.invalid>:
> >
> > a) I'd rather keep the current names. Just because of backward compat
> and adoption. Maybe the names are not perfect, but they are rather fine. It
> should really be mostly a package renaming and be done
> >
> > b.) @Romain, there is a HUGE difference between DeltaSpike
> @Transactional and javax.transaction.Transactional:
> > We have a very clear rule when it comes to Exceptions. In DS, if an
> Exception appears we will do a rollback, otherwise we will do a commit.
> > In javax/jakarta @Transactional only RuntimeExceptions and
> ApplicationExceptions with rollback=true will create a rollback, all other
> Exceptions will still cause a commit. This was 1:1 taken from EJB (which is
> imo also rather broken). Most people don't even don't realise that they
> might get a FileNotFoundException in the middle of their business code and
> STILL all the half done changes will be committed.
> >
> > Otoh if you have a RuntimeException in some nested Services ,A.fn()
> calls B.fn(), which is not catched when returning from the EJB 'Business
> Method' B.fn() the whole transaction will get marked as rollbackOnly().
> Even if you would have catched this very Exception in A.fn(). That's
> another major pain.
> >
> > I wrote a lengthy blog post about it many moons ago:
> >
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
> >
> > All this was the reason why we introduced the DeltaSpike @Transactional.
> It has a very clear semantic:
> > On the very layer ('business method' invocation) where the transaction
> got opened we do the check. If there is any Excpetion thrown -> Rollback,
> otherwise -> Commit.
> > Any subsequent nested calls into @Transactional business methods are
> completely transparent.
> >
> > You can also mix this with EJB and leverage any platform provided
> features if you use our TransactionStrategy which uses an injected
> UserTransaction to get the best of both worlds.
> >
> > DeltaSpike @Transactional is btw also used in projects which do not use
> our data module. Thus I'd leave everything in place. Please also think
> about the poor souls which just want to move from javax to jakarta
> *without* having such a deep knowledge about DeltaSpike as we do!
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> > >
> > > Hi,
> > >
> > > Do we have some visibility about the usage?
> > > Think jpa/tx feature tend to disappear in new applications because JTA
> got
> > > it (we like or not the design is another thing but feature is there
> > > built-in now comared to when DS was created).
> > > So for a new major we can aim at dropping it - keeping in 1.x.
> > > About data module I guess the adoption is not that high even if module
> is
> > > really "cool" - guess we miss the jaxrs bridge but we never got any
> request
> > > about it - so not sure its future.
> > > It can likely be the same for almost all core module which is now
> almost
> > > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > > things without added value in time for a new major).
> > >
> > > So overall I wouldnt aim at renaming but more pruning what is built in
> or
> > > will be soon and make DS lighter now resources are very low and the
> need of
> > > the project really less important than years ago.
> > >
> > > Hope it makes sense.
> > >
> > > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> andraschko.thomas@gmail.com>
> > > a écrit :
> > >
> > >> JPA is also about reading the JPA XML descriptors and resolving
> > >> EntityManagers, which is both heavily used in the Data module.
> > >> So its currently much more than TX. I would rename it to
> ds-persistence and
> > >> ds-faces.
> > >>
> > >> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > >> gpetracek@apache.org>:
> > >>
> > >>> hi thomas,
> > >>>
> > >>> we need to fix the rat-check (see [1]).
> > >>>
> > >>> @renaming the modules:
> > >>> the jpa-module was always mainly about the "entitymanager" +
> > >>> "transaction" (see the package-naming)... with the main focus on
> > >>> transactions (see @Transactional and @TransactionScoped as the main
> > >>> api).
> > >>> therefore we almost renamed it to ds-tx (in the beginning). we just
> > >>> kept 'jpa', because it wasn't clear what we might add later on.
> > >>> maybe we should just start a community-poll about it.
> > >>>
> > >>> regards,
> > >>> gerhard
> > >>>
> > >>> [1]
> > >>>
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > >>>
> > >>>
> > >>>
> > >>> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > >>> <an...@gmail.com>:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> last week i had some time and migrated almost all still existing
> > >> modules
> > >>> to
> > >>>> Jakarta. Only scheduler is currently not migrated.
> > >>>> AFAICS servlet, bean-validation has been removed, also other small
> > >> pieces
> > >>>> of core.
> > >>>>
> > >>>> I would also like to rename jpa and jsf to their new jakarta name
> > >>>> (persistence and faces).
> > >>>> WDYT guys?
> > >>>>
> > >>>> After that rename and reintroduce the scheduler module, i would be
> > >> happy
> > >>>> enough to release a RC1.
> > >>>>
> > >>>> AFAICS a big missing part are the tests on real containers?!
> > >>>> Any other topics we need to address?
> > >>>>
> > >>>> Best regards,
> > >>>> Thomas
> > >>>
> > >>
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Gerhard Petracek <gp...@apache.org>.
@mark: +1
regards,
gerhard
Am Fr., 7. Apr. 2023 um 09:45 Uhr schrieb Mark Struberg
<st...@yahoo.de.invalid>:
>
> a) I'd rather keep the current names. Just because of backward compat and adoption. Maybe the names are not perfect, but they are rather fine. It should really be mostly a package renaming and be done
>
> b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional and javax.transaction.Transactional:
> We have a very clear rule when it comes to Exceptions. In DS, if an Exception appears we will do a rollback, otherwise we will do a commit.
> In javax/jakarta @Transactional only RuntimeExceptions and ApplicationExceptions with rollback=true will create a rollback, all other Exceptions will still cause a commit. This was 1:1 taken from EJB (which is imo also rather broken). Most people don't even don't realise that they might get a FileNotFoundException in the middle of their business code and STILL all the half done changes will be committed.
>
> Otoh if you have a RuntimeException in some nested Services ,A.fn() calls B.fn(), which is not catched when returning from the EJB 'Business Method' B.fn() the whole transaction will get marked as rollbackOnly(). Even if you would have catched this very Exception in A.fn(). That's another major pain.
>
> I wrote a lengthy blog post about it many moons ago:
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> All this was the reason why we introduced the DeltaSpike @Transactional. It has a very clear semantic:
> On the very layer ('business method' invocation) where the transaction got opened we do the check. If there is any Excpetion thrown -> Rollback, otherwise -> Commit.
> Any subsequent nested calls into @Transactional business methods are completely transparent.
>
> You can also mix this with EJB and leverage any platform provided features if you use our TransactionStrategy which uses an injected UserTransaction to get the best of both worlds.
>
> DeltaSpike @Transactional is btw also used in projects which do not use our data module. Thus I'd leave everything in place. Please also think about the poor souls which just want to move from javax to jakarta *without* having such a deep knowledge about DeltaSpike as we do!
>
>
> LieGrue,
> strub
>
>
>
> > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> >
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <an...@gmail.com>
> > a écrit :
> >
> >> JPA is also about reading the JPA XML descriptors and resolving
> >> EntityManagers, which is both heavily used in the Data module.
> >> So its currently much more than TX. I would rename it to ds-persistence and
> >> ds-faces.
> >>
> >> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> >> gpetracek@apache.org>:
> >>
> >>> hi thomas,
> >>>
> >>> we need to fix the rat-check (see [1]).
> >>>
> >>> @renaming the modules:
> >>> the jpa-module was always mainly about the "entitymanager" +
> >>> "transaction" (see the package-naming)... with the main focus on
> >>> transactions (see @Transactional and @TransactionScoped as the main
> >>> api).
> >>> therefore we almost renamed it to ds-tx (in the beginning). we just
> >>> kept 'jpa', because it wasn't clear what we might add later on.
> >>> maybe we should just start a community-poll about it.
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>> [1]
> >>> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >>>
> >>>
> >>>
> >>> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> >>> <an...@gmail.com>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> last week i had some time and migrated almost all still existing
> >> modules
> >>> to
> >>>> Jakarta. Only scheduler is currently not migrated.
> >>>> AFAICS servlet, bean-validation has been removed, also other small
> >> pieces
> >>>> of core.
> >>>>
> >>>> I would also like to rename jpa and jsf to their new jakarta name
> >>>> (persistence and faces).
> >>>> WDYT guys?
> >>>>
> >>>> After that rename and reintroduce the scheduler module, i would be
> >> happy
> >>>> enough to release a RC1.
> >>>>
> >>>> AFAICS a big missing part are the tests on real containers?!
> >>>> Any other topics we need to address?
> >>>>
> >>>> Best regards,
> >>>> Thomas
> >>>
> >>
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 7 avr. 2023 à 09:46, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> a) I'd rather keep the current names. Just because of backward compat and
> adoption. Maybe the names are not perfect, but they are rather fine. It
> should really be mostly a package renaming and be done
>
+1
>
> b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional
> and javax.transaction.Transactional:
> We have a very clear rule when it comes to Exceptions. In DS, if an
> Exception appears we will do a rollback, otherwise we will do a commit.
> In javax/jakarta @Transactional only RuntimeExceptions and
> ApplicationExceptions with rollback=true will create a rollback, all other
> Exceptions will still cause a commit. This was 1:1 taken from EJB (which is
> imo also rather broken). Most people don't even don't realise that they
> might get a FileNotFoundException in the middle of their business code and
> STILL all the half done changes will be committed.
>
> Otoh if you have a RuntimeException in some nested Services ,A.fn() calls
> B.fn(), which is not catched when returning from the EJB 'Business Method'
> B.fn() the whole transaction will get marked as rollbackOnly(). Even if you
> would have catched this very Exception in A.fn(). That's another major pain.
>
> I wrote a lengthy blog post about it many moons ago:
>
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> All this was the reason why we introduced the DeltaSpike @Transactional.
> It has a very clear semantic:
> On the very layer ('business method' invocation) where the transaction got
> opened we do the check. If there is any Excpetion thrown -> Rollback,
> otherwise -> Commit.
> Any subsequent nested calls into @Transactional business methods are
> completely transparent.
>
> You can also mix this with EJB and leverage any platform provided features
> if you use our TransactionStrategy which uses an injected UserTransaction
> to get the best of both worlds.
>
> DeltaSpike @Transactional is btw also used in projects which do not use
> our data module. Thus I'd leave everything in place. Please also think
> about the poor souls which just want to move from javax to jakarta
> *without* having such a deep knowledge about DeltaSpike as we do!
>
Exactly, so even if the behavior is not exactly the same than DS - it is
what happens with all specs for impl coming before - it is strictly
equivalent and you can *always* make it work as intended so there is really
no strong point to keep it nowdays except backward compatibility we will
not get anyway since we move to jakarta so it is time to clean up the room
IMHO.
If we don't follow that philosophy we should probably reimplement CDI too,
see the point.
>
>
> LieGrue,
> strub
>
>
>
> > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA
> got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any
> request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need
> of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> andraschko.thomas@gmail.com>
> > a écrit :
> >
> >> JPA is also about reading the JPA XML descriptors and resolving
> >> EntityManagers, which is both heavily used in the Data module.
> >> So its currently much more than TX. I would rename it to ds-persistence
> and
> >> ds-faces.
> >>
> >> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> >> gpetracek@apache.org>:
> >>
> >>> hi thomas,
> >>>
> >>> we need to fix the rat-check (see [1]).
> >>>
> >>> @renaming the modules:
> >>> the jpa-module was always mainly about the "entitymanager" +
> >>> "transaction" (see the package-naming)... with the main focus on
> >>> transactions (see @Transactional and @TransactionScoped as the main
> >>> api).
> >>> therefore we almost renamed it to ds-tx (in the beginning). we just
> >>> kept 'jpa', because it wasn't clear what we might add later on.
> >>> maybe we should just start a community-poll about it.
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>> [1]
> >>>
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >>>
> >>>
> >>>
> >>> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> >>> <an...@gmail.com>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> last week i had some time and migrated almost all still existing
> >> modules
> >>> to
> >>>> Jakarta. Only scheduler is currently not migrated.
> >>>> AFAICS servlet, bean-validation has been removed, also other small
> >> pieces
> >>>> of core.
> >>>>
> >>>> I would also like to rename jpa and jsf to their new jakarta name
> >>>> (persistence and faces).
> >>>> WDYT guys?
> >>>>
> >>>> After that rename and reintroduce the scheduler module, i would be
> >> happy
> >>>> enough to release a RC1.
> >>>>
> >>>> AFAICS a big missing part are the tests on real containers?!
> >>>> Any other topics we need to address?
> >>>>
> >>>> Best regards,
> >>>> Thomas
> >>>
> >>
>
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
a) I'd rather keep the current names. Just because of backward compat and adoption. Maybe the names are not perfect, but they are rather fine. It should really be mostly a package renaming and be done
b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional and javax.transaction.Transactional:
We have a very clear rule when it comes to Exceptions. In DS, if an Exception appears we will do a rollback, otherwise we will do a commit.
In javax/jakarta @Transactional only RuntimeExceptions and ApplicationExceptions with rollback=true will create a rollback, all other Exceptions will still cause a commit. This was 1:1 taken from EJB (which is imo also rather broken). Most people don't even don't realise that they might get a FileNotFoundException in the middle of their business code and STILL all the half done changes will be committed.
Otoh if you have a RuntimeException in some nested Services ,A.fn() calls B.fn(), which is not catched when returning from the EJB 'Business Method' B.fn() the whole transaction will get marked as rollbackOnly(). Even if you would have catched this very Exception in A.fn(). That's another major pain.
I wrote a lengthy blog post about it many moons ago:
https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
All this was the reason why we introduced the DeltaSpike @Transactional. It has a very clear semantic:
On the very layer ('business method' invocation) where the transaction got opened we do the check. If there is any Excpetion thrown -> Rollback, otherwise -> Commit.
Any subsequent nested calls into @Transactional business methods are completely transparent.
You can also mix this with EJB and leverage any platform provided features if you use our TransactionStrategy which uses an injected UserTransaction to get the best of both worlds.
DeltaSpike @Transactional is btw also used in projects which do not use our data module. Thus I'd leave everything in place. Please also think about the poor souls which just want to move from javax to jakarta *without* having such a deep knowledge about DeltaSpike as we do!
LieGrue,
strub
> Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi,
>
> Do we have some visibility about the usage?
> Think jpa/tx feature tend to disappear in new applications because JTA got
> it (we like or not the design is another thing but feature is there
> built-in now comared to when DS was created).
> So for a new major we can aim at dropping it - keeping in 1.x.
> About data module I guess the adoption is not that high even if module is
> really "cool" - guess we miss the jaxrs bridge but we never got any request
> about it - so not sure its future.
> It can likely be the same for almost all core module which is now almost
> standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> things without added value in time for a new major).
>
> So overall I wouldnt aim at renaming but more pruning what is built in or
> will be soon and make DS lighter now resources are very low and the need of
> the project really less important than years ago.
>
> Hope it makes sense.
>
> 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <an...@gmail.com>
> a écrit :
>
>> JPA is also about reading the JPA XML descriptors and resolving
>> EntityManagers, which is both heavily used in the Data module.
>> So its currently much more than TX. I would rename it to ds-persistence and
>> ds-faces.
>>
>> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
>> gpetracek@apache.org>:
>>
>>> hi thomas,
>>>
>>> we need to fix the rat-check (see [1]).
>>>
>>> @renaming the modules:
>>> the jpa-module was always mainly about the "entitymanager" +
>>> "transaction" (see the package-naming)... with the main focus on
>>> transactions (see @Transactional and @TransactionScoped as the main
>>> api).
>>> therefore we almost renamed it to ds-tx (in the beginning). we just
>>> kept 'jpa', because it wasn't clear what we might add later on.
>>> maybe we should just start a community-poll about it.
>>>
>>> regards,
>>> gerhard
>>>
>>> [1]
>>> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
>>>
>>>
>>>
>>> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
>>> <an...@gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> last week i had some time and migrated almost all still existing
>> modules
>>> to
>>>> Jakarta. Only scheduler is currently not migrated.
>>>> AFAICS servlet, bean-validation has been removed, also other small
>> pieces
>>>> of core.
>>>>
>>>> I would also like to rename jpa and jsf to their new jakarta name
>>>> (persistence and faces).
>>>> WDYT guys?
>>>>
>>>> After that rename and reintroduce the scheduler module, i would be
>> happy
>>>> enough to release a RC1.
>>>>
>>>> AFAICS a big missing part are the tests on real containers?!
>>>> Any other topics we need to address?
>>>>
>>>> Best regards,
>>>> Thomas
>>>
>>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Gerhard Petracek <gp...@apache.org>.
EntityManagerResolver isn't really a feature on its own.
it was mainly about a common contract as well as encapsulation (of the
lookup-code) for re-using it across modules.
@goal (you mentioned):
i mentioned almost the same some time ago, however, there isn't/wasn't
an agreement (for that approach).
regards,
gerhard
Am Di., 4. Apr. 2023 um 10:21 Uhr schrieb Thomas Andraschko
<an...@gmail.com>:
>
> In theory we could remove TX (if all cases are handled by JTA) and move the
> EntityManagerResolver + JPA descriptor parsing to Data itself.
>
> In general i think our goal should be to port the DS features, if still not
> existing in EE10, to EE10. Not to remove everything not widely used.
> This allows users to migrate to EE10 with some adjustments.
>
>
> Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
>
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > andraschko.thomas@gmail.com>
> > a écrit :
> >
> > > JPA is also about reading the JPA XML descriptors and resolving
> > > EntityManagers, which is both heavily used in the Data module.
> > > So its currently much more than TX. I would rename it to ds-persistence
> > and
> > > ds-faces.
> > >
> > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > gpetracek@apache.org>:
> > >
> > > > hi thomas,
> > > >
> > > > we need to fix the rat-check (see [1]).
> > > >
> > > > @renaming the modules:
> > > > the jpa-module was always mainly about the "entitymanager" +
> > > > "transaction" (see the package-naming)... with the main focus on
> > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > api).
> > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > maybe we should just start a community-poll about it.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1]
> > > >
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > >
> > > >
> > > >
> > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > <an...@gmail.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > last week i had some time and migrated almost all still existing
> > > modules
> > > > to
> > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > AFAICS servlet, bean-validation has been removed, also other small
> > > pieces
> > > > > of core.
> > > > >
> > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > (persistence and faces).
> > > > > WDYT guys?
> > > > >
> > > > > After that rename and reintroduce the scheduler module, i would be
> > > happy
> > > > > enough to release a RC1.
> > > > >
> > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > Any other topics we need to address?
> > > > >
> > > > > Best regards,
> > > > > Thomas
> > > >
> > >
> >
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 4 avr. 2023 à 11:18, Thomas Andraschko <an...@gmail.com>
a écrit :
> I think the most features and modules are just working fine - normal tests
> are running.
> Just container testing may find weird bugs.
> So its not about the effort of "reimplementing features" vs "dropping
> features", its all already there.
>
I don't get it, there are a few things to consider:
1. we are going major with jakarta so the entry point is >> the one we had
before, for ex, BeanProvider or all bean builders are built in now so why
duplicating?
2. I didn't reall speak about "reimplementing" anything but more about
making it user friendly, if you take deltaspike + the required underlying
container as of today, > 60% overlaps so as an user what should you use? It
is was more obvious if the choice is unique to write clean and portable
code than having iso alternatives in the IDE IMHO.
3. we'll don't maintain the workarounds we have in the code and as you
mention we need some real effort to ensure it is portable (which is not as
of today AFAIK due to last weld updates) so the point of resources is key
from my point of view
So overall converging to the project staff and end users it makes sense to
drop most of what got added to the spec (sometimes thanks to DS :)).
> Am Di., 4. Apr. 2023 um 10:44 Uhr schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
>
> > Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko <
> > andraschko.thomas@gmail.com>
> > a écrit :
> >
> > > In theory we could remove TX (if all cases are handled by JTA) and move
> > the
> > > EntityManagerResolver + JPA descriptor parsing to Data itself.
> > >
> > > In general i think our goal should be to port the DS features, if still
> > not
> > > existing in EE10, to EE10. Not to remove everything not widely used.
> > > This allows users to migrate to EE10 with some adjustments.
> > >
> >
> > This assumes it is used but this is really unsure, stats we have
> (central)
> > are really about CI zone and major is our best chance to drop what is not
> > needed to focus our effort on what is actually used.
> > Indeed not a blocker but my 2cts would be to drop what we can to
> > potentially add it back if we get a lot of demand rather than the
> opposite
> > which means we'll keep dragging things to maintain almost nobody needs.
> >
> >
> > >
> > >
> > > Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> > > rmannibucau@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > Do we have some visibility about the usage?
> > > > Think jpa/tx feature tend to disappear in new applications because
> JTA
> > > got
> > > > it (we like or not the design is another thing but feature is there
> > > > built-in now comared to when DS was created).
> > > > So for a new major we can aim at dropping it - keeping in 1.x.
> > > > About data module I guess the adoption is not that high even if
> module
> > is
> > > > really "cool" - guess we miss the jaxrs bridge but we never got any
> > > request
> > > > about it - so not sure its future.
> > > > It can likely be the same for almost all core module which is now
> > almost
> > > > standard in CDI or Microprofile/coming Jakarta (idea being to not
> bring
> > > > things without added value in time for a new major).
> > > >
> > > > So overall I wouldnt aim at renaming but more pruning what is built
> in
> > or
> > > > will be soon and make DS lighter now resources are very low and the
> > need
> > > of
> > > > the project really less important than years ago.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > > > andraschko.thomas@gmail.com>
> > > > a écrit :
> > > >
> > > > > JPA is also about reading the JPA XML descriptors and resolving
> > > > > EntityManagers, which is both heavily used in the Data module.
> > > > > So its currently much more than TX. I would rename it to
> > ds-persistence
> > > > and
> > > > > ds-faces.
> > > > >
> > > > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > > > gpetracek@apache.org>:
> > > > >
> > > > > > hi thomas,
> > > > > >
> > > > > > we need to fix the rat-check (see [1]).
> > > > > >
> > > > > > @renaming the modules:
> > > > > > the jpa-module was always mainly about the "entitymanager" +
> > > > > > "transaction" (see the package-naming)... with the main focus on
> > > > > > transactions (see @Transactional and @TransactionScoped as the
> main
> > > > > > api).
> > > > > > therefore we almost renamed it to ds-tx (in the beginning). we
> just
> > > > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > > > maybe we should just start a community-poll about it.
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > > > >
> > > > > >
> > > > > >
> > > > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > > > <an...@gmail.com>:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > last week i had some time and migrated almost all still
> existing
> > > > > modules
> > > > > > to
> > > > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > > > AFAICS servlet, bean-validation has been removed, also other
> > small
> > > > > pieces
> > > > > > > of core.
> > > > > > >
> > > > > > > I would also like to rename jpa and jsf to their new jakarta
> name
> > > > > > > (persistence and faces).
> > > > > > > WDYT guys?
> > > > > > >
> > > > > > > After that rename and reintroduce the scheduler module, i would
> > be
> > > > > happy
> > > > > > > enough to release a RC1.
> > > > > > >
> > > > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > > > Any other topics we need to address?
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Thomas
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Thomas Andraschko <an...@gmail.com>.
I think the most features and modules are just working fine - normal tests
are running.
Just container testing may find weird bugs.
So its not about the effort of "reimplementing features" vs "dropping
features", its all already there.
Am Di., 4. Apr. 2023 um 10:44 Uhr schrieb Romain Manni-Bucau <
rmannibucau@gmail.com>:
> Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko <
> andraschko.thomas@gmail.com>
> a écrit :
>
> > In theory we could remove TX (if all cases are handled by JTA) and move
> the
> > EntityManagerResolver + JPA descriptor parsing to Data itself.
> >
> > In general i think our goal should be to port the DS features, if still
> not
> > existing in EE10, to EE10. Not to remove everything not widely used.
> > This allows users to migrate to EE10 with some adjustments.
> >
>
> This assumes it is used but this is really unsure, stats we have (central)
> are really about CI zone and major is our best chance to drop what is not
> needed to focus our effort on what is actually used.
> Indeed not a blocker but my 2cts would be to drop what we can to
> potentially add it back if we get a lot of demand rather than the opposite
> which means we'll keep dragging things to maintain almost nobody needs.
>
>
> >
> >
> > Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> > rmannibucau@gmail.com>:
> >
> > > Hi,
> > >
> > > Do we have some visibility about the usage?
> > > Think jpa/tx feature tend to disappear in new applications because JTA
> > got
> > > it (we like or not the design is another thing but feature is there
> > > built-in now comared to when DS was created).
> > > So for a new major we can aim at dropping it - keeping in 1.x.
> > > About data module I guess the adoption is not that high even if module
> is
> > > really "cool" - guess we miss the jaxrs bridge but we never got any
> > request
> > > about it - so not sure its future.
> > > It can likely be the same for almost all core module which is now
> almost
> > > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > > things without added value in time for a new major).
> > >
> > > So overall I wouldnt aim at renaming but more pruning what is built in
> or
> > > will be soon and make DS lighter now resources are very low and the
> need
> > of
> > > the project really less important than years ago.
> > >
> > > Hope it makes sense.
> > >
> > > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > > andraschko.thomas@gmail.com>
> > > a écrit :
> > >
> > > > JPA is also about reading the JPA XML descriptors and resolving
> > > > EntityManagers, which is both heavily used in the Data module.
> > > > So its currently much more than TX. I would rename it to
> ds-persistence
> > > and
> > > > ds-faces.
> > > >
> > > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > > gpetracek@apache.org>:
> > > >
> > > > > hi thomas,
> > > > >
> > > > > we need to fix the rat-check (see [1]).
> > > > >
> > > > > @renaming the modules:
> > > > > the jpa-module was always mainly about the "entitymanager" +
> > > > > "transaction" (see the package-naming)... with the main focus on
> > > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > > api).
> > > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > > maybe we should just start a community-poll about it.
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > > [1]
> > > > >
> > >
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > > >
> > > > >
> > > > >
> > > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > > <an...@gmail.com>:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > last week i had some time and migrated almost all still existing
> > > > modules
> > > > > to
> > > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > > AFAICS servlet, bean-validation has been removed, also other
> small
> > > > pieces
> > > > > > of core.
> > > > > >
> > > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > > (persistence and faces).
> > > > > > WDYT guys?
> > > > > >
> > > > > > After that rename and reintroduce the scheduler module, i would
> be
> > > > happy
> > > > > > enough to release a RC1.
> > > > > >
> > > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > > Any other topics we need to address?
> > > > > >
> > > > > > Best regards,
> > > > > > Thomas
> > > > >
> > > >
> > >
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko <an...@gmail.com>
a écrit :
> In theory we could remove TX (if all cases are handled by JTA) and move the
> EntityManagerResolver + JPA descriptor parsing to Data itself.
>
> In general i think our goal should be to port the DS features, if still not
> existing in EE10, to EE10. Not to remove everything not widely used.
> This allows users to migrate to EE10 with some adjustments.
>
This assumes it is used but this is really unsure, stats we have (central)
are really about CI zone and major is our best chance to drop what is not
needed to focus our effort on what is actually used.
Indeed not a blocker but my 2cts would be to drop what we can to
potentially add it back if we get a lot of demand rather than the opposite
which means we'll keep dragging things to maintain almost nobody needs.
>
>
> Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
>
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA
> got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any
> request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need
> of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > andraschko.thomas@gmail.com>
> > a écrit :
> >
> > > JPA is also about reading the JPA XML descriptors and resolving
> > > EntityManagers, which is both heavily used in the Data module.
> > > So its currently much more than TX. I would rename it to ds-persistence
> > and
> > > ds-faces.
> > >
> > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > gpetracek@apache.org>:
> > >
> > > > hi thomas,
> > > >
> > > > we need to fix the rat-check (see [1]).
> > > >
> > > > @renaming the modules:
> > > > the jpa-module was always mainly about the "entitymanager" +
> > > > "transaction" (see the package-naming)... with the main focus on
> > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > api).
> > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > maybe we should just start a community-poll about it.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1]
> > > >
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > >
> > > >
> > > >
> > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > <an...@gmail.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > last week i had some time and migrated almost all still existing
> > > modules
> > > > to
> > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > AFAICS servlet, bean-validation has been removed, also other small
> > > pieces
> > > > > of core.
> > > > >
> > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > (persistence and faces).
> > > > > WDYT guys?
> > > > >
> > > > > After that rename and reintroduce the scheduler module, i would be
> > > happy
> > > > > enough to release a RC1.
> > > > >
> > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > Any other topics we need to address?
> > > > >
> > > > > Best regards,
> > > > > Thomas
> > > >
> > >
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Thomas Andraschko <an...@gmail.com>.
In theory we could remove TX (if all cases are handled by JTA) and move the
EntityManagerResolver + JPA descriptor parsing to Data itself.
In general i think our goal should be to port the DS features, if still not
existing in EE10, to EE10. Not to remove everything not widely used.
This allows users to migrate to EE10 with some adjustments.
Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
rmannibucau@gmail.com>:
> Hi,
>
> Do we have some visibility about the usage?
> Think jpa/tx feature tend to disappear in new applications because JTA got
> it (we like or not the design is another thing but feature is there
> built-in now comared to when DS was created).
> So for a new major we can aim at dropping it - keeping in 1.x.
> About data module I guess the adoption is not that high even if module is
> really "cool" - guess we miss the jaxrs bridge but we never got any request
> about it - so not sure its future.
> It can likely be the same for almost all core module which is now almost
> standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> things without added value in time for a new major).
>
> So overall I wouldnt aim at renaming but more pruning what is built in or
> will be soon and make DS lighter now resources are very low and the need of
> the project really less important than years ago.
>
> Hope it makes sense.
>
> 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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> andraschko.thomas@gmail.com>
> a écrit :
>
> > JPA is also about reading the JPA XML descriptors and resolving
> > EntityManagers, which is both heavily used in the Data module.
> > So its currently much more than TX. I would rename it to ds-persistence
> and
> > ds-faces.
> >
> > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > gpetracek@apache.org>:
> >
> > > hi thomas,
> > >
> > > we need to fix the rat-check (see [1]).
> > >
> > > @renaming the modules:
> > > the jpa-module was always mainly about the "entitymanager" +
> > > "transaction" (see the package-naming)... with the main focus on
> > > transactions (see @Transactional and @TransactionScoped as the main
> > > api).
> > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > kept 'jpa', because it wasn't clear what we might add later on.
> > > maybe we should just start a community-poll about it.
> > >
> > > regards,
> > > gerhard
> > >
> > > [1]
> > >
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > >
> > >
> > >
> > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > <an...@gmail.com>:
> > > >
> > > > Hi,
> > > >
> > > > last week i had some time and migrated almost all still existing
> > modules
> > > to
> > > > Jakarta. Only scheduler is currently not migrated.
> > > > AFAICS servlet, bean-validation has been removed, also other small
> > pieces
> > > > of core.
> > > >
> > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > (persistence and faces).
> > > > WDYT guys?
> > > >
> > > > After that rename and reintroduce the scheduler module, i would be
> > happy
> > > > enough to release a RC1.
> > > >
> > > > AFAICS a big missing part are the tests on real containers?!
> > > > Any other topics we need to address?
> > > >
> > > > Best regards,
> > > > Thomas
> > >
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Do we have some visibility about the usage?
Think jpa/tx feature tend to disappear in new applications because JTA got
it (we like or not the design is another thing but feature is there
built-in now comared to when DS was created).
So for a new major we can aim at dropping it - keeping in 1.x.
About data module I guess the adoption is not that high even if module is
really "cool" - guess we miss the jaxrs bridge but we never got any request
about it - so not sure its future.
It can likely be the same for almost all core module which is now almost
standard in CDI or Microprofile/coming Jakarta (idea being to not bring
things without added value in time for a new major).
So overall I wouldnt aim at renaming but more pruning what is built in or
will be soon and make DS lighter now resources are very low and the need of
the project really less important than years ago.
Hope it makes sense.
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 mar. 4 avr. 2023 à 09:57, Thomas Andraschko <an...@gmail.com>
a écrit :
> JPA is also about reading the JPA XML descriptors and resolving
> EntityManagers, which is both heavily used in the Data module.
> So its currently much more than TX. I would rename it to ds-persistence and
> ds-faces.
>
> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> gpetracek@apache.org>:
>
> > hi thomas,
> >
> > we need to fix the rat-check (see [1]).
> >
> > @renaming the modules:
> > the jpa-module was always mainly about the "entitymanager" +
> > "transaction" (see the package-naming)... with the main focus on
> > transactions (see @Transactional and @TransactionScoped as the main
> > api).
> > therefore we almost renamed it to ds-tx (in the beginning). we just
> > kept 'jpa', because it wasn't clear what we might add later on.
> > maybe we should just start a community-poll about it.
> >
> > regards,
> > gerhard
> >
> > [1]
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >
> >
> >
> > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > <an...@gmail.com>:
> > >
> > > Hi,
> > >
> > > last week i had some time and migrated almost all still existing
> modules
> > to
> > > Jakarta. Only scheduler is currently not migrated.
> > > AFAICS servlet, bean-validation has been removed, also other small
> pieces
> > > of core.
> > >
> > > I would also like to rename jpa and jsf to their new jakarta name
> > > (persistence and faces).
> > > WDYT guys?
> > >
> > > After that rename and reintroduce the scheduler module, i would be
> happy
> > > enough to release a RC1.
> > >
> > > AFAICS a big missing part are the tests on real containers?!
> > > Any other topics we need to address?
> > >
> > > Best regards,
> > > Thomas
> >
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Gerhard Petracek <gp...@apache.org>.
hi thomas,
@entity-manager:
i mentioned that, but it (@PersistenceUnitName) was always more like
an optional benefit (depending on your application-setup).
i guess e.g. mark might disagree with that, however, imo the majority
isn't using it (at least once you are using an ee-server).
the rest in that area is mainly integration-code and documentation
about the proper usage
(and nothing ds provides as a feature for users).
@persistence-xml (utils):
i know and you know it, because you promoted it.
however, it isn't that well known (it's "hidden" in the "spi"-package
and not even mentioned in our documentation).
therefore, the main part for users (also if you have a look at the
documentation) is about transactions (and topics related to it).
(if you skip the options for the entity-manager usages which aren't
provided by ds itself.)
regards,
gerhard
Am Di., 4. Apr. 2023 um 09:57 Uhr schrieb Thomas Andraschko
<an...@gmail.com>:
>
> JPA is also about reading the JPA XML descriptors and resolving
> EntityManagers, which is both heavily used in the Data module.
> So its currently much more than TX. I would rename it to ds-persistence and
> ds-faces.
>
> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> gpetracek@apache.org>:
>
> > hi thomas,
> >
> > we need to fix the rat-check (see [1]).
> >
> > @renaming the modules:
> > the jpa-module was always mainly about the "entitymanager" +
> > "transaction" (see the package-naming)... with the main focus on
> > transactions (see @Transactional and @TransactionScoped as the main
> > api).
> > therefore we almost renamed it to ds-tx (in the beginning). we just
> > kept 'jpa', because it wasn't clear what we might add later on.
> > maybe we should just start a community-poll about it.
> >
> > regards,
> > gerhard
> >
> > [1]
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >
> >
> >
> > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > <an...@gmail.com>:
> > >
> > > Hi,
> > >
> > > last week i had some time and migrated almost all still existing modules
> > to
> > > Jakarta. Only scheduler is currently not migrated.
> > > AFAICS servlet, bean-validation has been removed, also other small pieces
> > > of core.
> > >
> > > I would also like to rename jpa and jsf to their new jakarta name
> > > (persistence and faces).
> > > WDYT guys?
> > >
> > > After that rename and reintroduce the scheduler module, i would be happy
> > > enough to release a RC1.
> > >
> > > AFAICS a big missing part are the tests on real containers?!
> > > Any other topics we need to address?
> > >
> > > Best regards,
> > > Thomas
> >
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Thomas Andraschko <an...@gmail.com>.
JPA is also about reading the JPA XML descriptors and resolving
EntityManagers, which is both heavily used in the Data module.
So its currently much more than TX. I would rename it to ds-persistence and
ds-faces.
Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
gpetracek@apache.org>:
> hi thomas,
>
> we need to fix the rat-check (see [1]).
>
> @renaming the modules:
> the jpa-module was always mainly about the "entitymanager" +
> "transaction" (see the package-naming)... with the main focus on
> transactions (see @Transactional and @TransactionScoped as the main
> api).
> therefore we almost renamed it to ds-tx (in the beginning). we just
> kept 'jpa', because it wasn't clear what we might add later on.
> maybe we should just start a community-poll about it.
>
> regards,
> gerhard
>
> [1]
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
>
>
>
> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> <an...@gmail.com>:
> >
> > Hi,
> >
> > last week i had some time and migrated almost all still existing modules
> to
> > Jakarta. Only scheduler is currently not migrated.
> > AFAICS servlet, bean-validation has been removed, also other small pieces
> > of core.
> >
> > I would also like to rename jpa and jsf to their new jakarta name
> > (persistence and faces).
> > WDYT guys?
> >
> > After that rename and reintroduce the scheduler module, i would be happy
> > enough to release a RC1.
> >
> > AFAICS a big missing part are the tests on real containers?!
> > Any other topics we need to address?
> >
> > Best regards,
> > Thomas
>
Re: Jakarta EE / DeltaSpike 2.0 Status
Posted by Gerhard Petracek <gp...@apache.org>.
hi thomas,
we need to fix the rat-check (see [1]).
@renaming the modules:
the jpa-module was always mainly about the "entitymanager" +
"transaction" (see the package-naming)... with the main focus on
transactions (see @Transactional and @TransactionScoped as the main
api).
therefore we almost renamed it to ds-tx (in the beginning). we just
kept 'jpa', because it wasn't clear what we might add later on.
maybe we should just start a community-poll about it.
regards,
gerhard
[1] https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
<an...@gmail.com>:
>
> Hi,
>
> last week i had some time and migrated almost all still existing modules to
> Jakarta. Only scheduler is currently not migrated.
> AFAICS servlet, bean-validation has been removed, also other small pieces
> of core.
>
> I would also like to rename jpa and jsf to their new jakarta name
> (persistence and faces).
> WDYT guys?
>
> After that rename and reintroduce the scheduler module, i would be happy
> enough to release a RC1.
>
> AFAICS a big missing part are the tests on real containers?!
> Any other topics we need to address?
>
> Best regards,
> Thomas