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 <rmannibu...@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.tho...@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 < >> gpetra...@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 >>> <andraschko.tho...@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 >>> >>
