You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2020/02/29 15:09:01 UTC
Re: geronimo_jpa dependency and java11
Sorry that this slipped. This imo needs further discussion.
The license aspect is not clear imo.
We also break many downstream openjpa users which had their whole toolset tailored for geronimo-specs.
I'm +1 for a revert and cleanup of geronimo-jpa-spec.
LieGrue,
strub
> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
>
> You are right
> this change breaks java8 build
> OK, my PR will stay the same :))
>
> On Wed, 25 Dec 2019 at 16:14, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>> Does not change the fact it is a j11 feature and our compile baseline is j8
>> so nogo until it is a profile ;).
>>
>> Side note: dont think we must compile with j11, just run.
>>
>> Le mer. 25 déc. 2019 à 09:57, Maxim Solodovnik <so...@gmail.com> a
>> écrit :
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8212636
>>>
>>> On Wed, 25 Dec 2019 at 15:56, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>> Release? Source=target=8 should be enough otherwise you will not build on
>>>> java 8.
>>>>
>>>> Le mer. 25 déc. 2019 à 09:48, Maxim Solodovnik <so...@gmail.com> a
>>>> écrit :
>>>>
>>>>> It seems adding
>>>>> <release>8</release>
>>>>> to maven-compiler-plugin config seems to fix java11 build for me
>>>>> Will add this change to PR as soon build will be successful
>>>>>
>>>>> On Wed, 25 Dec 2019 at 15:22, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Le mer. 25 déc. 2019 à 06:17, Maxim Solodovnik <so...@gmail.com>
>>> a
>>>>>> écrit :
>>>>>>
>>>>>>> Can I merge this PR?
>>>>>>> I can additionally check compilation issues under java11 ....
>>>>>>>
>>>>>>> On Tue, 17 Dec 2019 at 14:29, Maxim Solodovnik <
>>> solomax666@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Both fixed :)
>>>>>>>>
>>>>>>>> On Tue, 17 Dec 2019 at 13:53, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Except one missing indent and probably the move from "stats" to
>>>>>>>>> "statistics" it looks good to me, wdyt @Mark Struberg <
>>>>>>> struberg@yahoo.de> ?
>>>>>>>>>
>>>>>>>>> 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. 17 déc. 2019 à 07:49, Maxim Solodovnik <
>>>>> solomax666@gmail.com>
>>>>>>> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>>> https://github.com/apache/openjpa/pull/57
>>>>>>>>>>
>>>>>>>>>> On Tue, 17 Dec 2019 at 13:19, Maxim Solodovnik <
>>>>> solomax666@gmail.com
>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Great,
>>>>>>>>>>>
>>>>>>>>>>> will do
>>>>>>>>>>> I'm going to add Automatic-Module-Name
>>>>>>>>>>>
>>>>> `org.apache.openja.<module-name-with-dashes-replaced-with-dots>`
>>>>>>>>>>> And we can discuss changes in "review" mode :)
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 17 Dec 2019 at 13:13, Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm, not exactly what i expected but it should work, not
>>>>> just as
>>>>>>>>>>>> transparent and integrated as i thought.
>>>>>>>>>>>>
>>>>>>>>>>>> The end of the dependency mess is still key for me and
>>> only
>>>>> this
>>>>>>> jar
>>>>>>>>>> can
>>>>>>>>>>>> justify the scope compile you spoke about, all G one
>>> should
>>>>> be
>>>>>>> provides
>>>>>>>>>>>> IMHO.
>>>>>>>>>>>>
>>>>>>>>>>>> Dont think osgi is a blocker while you dont put it in the
>>>>> karaf
>>>>>>>>>> feature.
>>>>>>>>>>>>
>>>>>>>>>>>> So tempted to say you can finish the pr.
>>>>>>>>>>>>
>>>>>>>>>>>> Le mar. 17 déc. 2019 à 07:06, Maxim Solodovnik <
>>>>>>> solomax666@gmail.com>
>>>>>>>>>> a
>>>>>>>>>>>> écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> This is part of MANIFEST.MF
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bundle-ManifestVersion: 2
>>>>>>>>>>>>> Bundle-Vendor: Eclipse.org - EclipseLink Project
>>>>>>>>>>>>> Require-Capability: osgi.ee; filter:="(&(osgi.ee
>>>>>>>>>> =JavaSE)(version>=1.8)
>>>>>>>>>>>>> )"
>>>>>>>>>>>>> Import-Package:
>>>>>>>>>> javax.sql;resolution:=optional,org.osgi.framework;reso
>>>>>>>>>>>>> lution:=optional,org.osgi.service.jpa;version="1.1.0"
>>>>>>>>>>>>> Implementation-Vendor: Eclipse.org - EclipseLink
>>> Project
>>>>>>>>>>>>> Export-Package:
>>>>>>>>>> javax.persistence;jpa="2.2";version="2.2.3",javax.pers
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>> istence.criteria;jpa="2.2";version="2.2.3",javax.persistence.metamode
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>> l;jpa="2.2";version="2.2.3",javax.persistence.spi;jpa="2.2";version="
>>>>>>>>>>>>> 2.2.3",org.osgi.service.jpa;version="1.1.0"
>>>>>>>>>>>>> Bundle-Name: Jakarta Persistence API 2.2
>>>>>>>>>>>>> Bundle-Version: 2.2.3
>>>>>>>>>>>>> Bundle-ClassPath: .
>>>>>>>>>>>>> Bundle-Activator:
>>>>>>>>>> org.eclipse.persistence.javax.persistence.osgi.Activ
>>>>>>>>>>>>> ator
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was unable to find "Provide-Capability" in the jar
>>> (but
>>>>>>> maybe I was
>>>>>>>>>>>>> looking in wrong place ...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 17 Dec 2019 at 12:58, Romain Manni-Bucau <
>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hmmm, looks like old style, doesnt it have
>>>>> Provide-Capability
>>>>>>>>>> somewhere
>>>>>>>>>>>>>> (sorry i dont have a computer handy right now)?
>>>>>>>>>>>>>> Maybe reopen a thread @g Mark if you want to do that,
>>>>> but we
>>>>>>>>>> should also
>>>>>>>>>>>>>> include micrporofile in that thread to enforce our
>>>>>>> consistence
>>>>>>>>>> IMHO.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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. 17 déc. 2019 à 06:56, Maxim Solodovnik <
>>>>>>>>>> solomax666@gmail.com> a
>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not familiar with OSGI
>>>>>>>>>>>>>>> jakarta.jas has `Activator implements
>>>>>>>>>>>>> org.osgi.framework.BundleActivator`
>>>>>>>>>>>>>>> and `OSGiProviderResolver implements
>>>>>>> PersistenceProviderResolver,
>>>>>>>>>>>>>>> PersistenceProvider`
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please let me know if I should proceed with my PR,
>>> or
>>>>> if it
>>>>>>>>>> would be
>>>>>>>>>>>>>>> better to dismiss it :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, 17 Dec 2019 at 04:42, Romain Manni-Bucau <
>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le lun. 16 déc. 2019 à 22:13, Mark Struberg
>>>>>>>>>>>>> <st...@yahoo.de.invalid>
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> jakarta persistence is EPL. It's not a problem
>>> to
>>>>> add
>>>>>>> it but
>>>>>>>>>> would
>>>>>>>>>>>>>>> love to
>>>>>>>>>>>>>>>>> avoid it.
>>>>>>>>>>>>>>>>> The simplest way would be to add those module
>>>>>>> information to
>>>>>>>>>>>>>>> Geronimo-jpa.
>>>>>>>>>>>>>>>>> Could do a mass release of those specs then.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We should stick to a single strategy for all spec
>>>>> jars
>>>>>>> with a
>>>>>>>>>>>>> compatible
>>>>>>>>>>>>>>>> license IMHO.
>>>>>>>>>>>>>>>> I dont care which way we go but I dont want a
>>> case by
>>>>>>> case
>>>>>>>>>> choice
>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> would be hard to support.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also having jakarta deps will reduce dependency
>>>>>>> management for
>>>>>>>>>> post
>>>>>>>>>>>>> users
>>>>>>>>>>>>>>>> so i see it as a 60-40 for jakata.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Am 16.12.2019 um 14:39 schrieb Maxim
>>> Solodovnik <
>>>>>>>>>>>>>>> solomax666@gmail.com>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here is the diff
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>> https://github.com/apache/openjpa/compare/OPENJPA-2798-java11-friendly
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:38, Maxim
>>> Solodovnik <
>>>>>>>>>>>>> solomax666@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Current status: In my branch I have changed
>>>>>>> jpa_spec with
>>>>>>>>>>>>>>>>>>> jakarta.persistence and the build is green
>>>>>>>>>>>>>>>>>>> I can drop this branch if there is better
>>> way to
>>>>>>> achieve
>>>>>>>>>> java11
>>>>>>>>>>>>>>>>> compatibility :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I always thought modules is like
>>> dependencies
>>>>>>>>>>>>>>>>>>> I only have openjpa dependency right now
>>> and do
>>>>>>> have all
>>>>>>>>>>>>> transitive
>>>>>>>>>>>>>>>>>>> jars available, so my pom is cleaner ...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:32, Mark Struberg
>>>>>>>>>>>>>>> <st...@yahoo.de.invalid>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm not sure what the status is right now.
>>> But
>>>>> one
>>>>>>> of
>>>>>>>>>> the big
>>>>>>>>>>>>> pros
>>>>>>>>>>>>>>>>> over the standard jpa api has always been that
>>> it
>>>>>>> works even
>>>>>>>>>> with
>>>>>>>>>>>>> OSGi.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Am 16.12.2019 um 14:24 schrieb Romain
>>>>> Manni-Bucau
>>>>>>> <
>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Not "compile time dependencies" but "spec
>>>>> jars".
>>>>>>> Mainly
>>>>>>>>>>>>> because
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>> must import it himself (this is what he
>>> use to
>>>>>>> code so
>>>>>>>>>> it
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>>>>>>> level dep + to avoid the exclusion mess
>>> since
>>>>>>> there are
>>>>>>>>>> like
>>>>>>>>>>>>> 6-7
>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>> jars
>>>>>>>>>>>>>>>>>>>>> libs use and conflict).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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 lun. 16 déc. 2019 à 14:15, Maxim
>>>>> Solodovnik <
>>>>>>>>>>>>>>> solomax666@gmail.com>
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> BTW why compile time dependency should't
>>> be
>>>>>>> transitive?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:12, Maxim
>>>>> Solodovnik <
>>>>>>>>>>>>>>> solomax666@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I can create PR in a minute (based on
>>>>>>>>>>>>>>> OPENJPA-2798-java11-friendly
>>>>>>>>>>>>>>>>>>>>>> branch)
>>>>>>>>>>>>>>>>>>>>>>> Was planning to add
>>>>> "Automatic-Module-Name"s to
>>>>>>>>>> manifest
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:03, Romain
>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nobody uses it but adding them breaks
>>> apps
>>>>> ;),
>>>>>>> yeah.
>>>>>>>>>>>>>>>>>>>>>>>> Anyway openjpa shouldnt have jpa api
>>>>> transitive
>>>>>>>>>> anyway
>>>>>>>>>>>>> IMHO so
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> big
>>>>>>>>>>>>>>>>>>>>>>>> deal while we dont break OSGi case in
>>> the
>>>>>>>>>> feature.xml.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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 lun. 16 déc. 2019 à 13:52, Mark
>>> Struberg
>>>>>>>>>>>>>>>>> <st...@yahoo.de.invalid>
>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I'd go with fixing our module info in
>>>>>>> geronimo-jpa.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> But otoh nobody is using modules
>>> anyway it
>>>>>>> seems ...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Am 11.12.2019 um 06:39 schrieb Romain
>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Yes this one
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> For openjpa the challenge will
>>> likely to
>>>>> not
>>>>>>> have
>>>>>>>>>>>>>>> module-info in
>>>>>>>>>>>>>>>>>>>>>> main
>>>>>>>>>>>>>>>>>>>>>>>>>> artifacts - guess we can duplicate
>>>>> artifacts
>>>>>>> with a
>>>>>>>>>>>>>>> classifier
>>>>>>>>>>>>>>>>>>>>>> jpms or
>>>>>>>>>>>>>>>>>>>>>>>>> so -
>>>>>>>>>>>>>>>>>>>>>>>>>> to avoid to break some servers and
>>> env.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Last thing to take care: all osgi
>>>>>>> integration, i
>>>>>>>>>> didnt
>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>>>> jakarta jar
>>>>>>>>>>>>>>>>>>>>>>>>>> supports it as well as our spec jar.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So likely some validation work to do
>>> but
>>>>> yes
>>>>>>> it
>>>>>>>>>> sounds
>>>>>>>>>>>>> like
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> plan.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hope it helps even if not a straight
>>>>> "yes".
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Le mer. 11 déc. 2019 à 03:57, Maxim
>>>>>>> Solodovnik <
>>>>>>>>>>>>>>>>>>>>>> solomax666@gmail.com> a
>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you mean this one:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> <dependency>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> <groupId>org.eclipse.persistence</groupId>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> <artifactId>jakarta.persistence</artifactId>
>>>>>>>>>>>>>>>>>>>>>>>>>>> <version>2.2.2</version>
>>>>>>>>>>>>>>>>>>>>>>>>>>> </dependency>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Looks good to me!
>>>>>>>>>>>>>>>>>>>>>>>>>>> Shall I create PR? (the task seems
>>> to be
>>>>>>> doable
>>>>>>>>>> for me
>>>>>>>>>>>>> :)))
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, 11 Dec 2019 at 01:03, Romain
>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I proposed some time ago to rename
>>> them
>>>>>>> all but
>>>>>>>>>> since
>>>>>>>>>>>>>>> jakarta
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>>>>>> eclipse
>>>>>>>>>>>>>>>>>>>>>>>>>>>> now, i guess well more move to
>>> their
>>>>>>> bundles.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Wdyt?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 10 déc. 2019 à 18:18, Maxim
>>>>>>> Solodovnik <
>>>>>>>>>>>>>>>>>>>>>> solomax666@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not sure which list should I ask,
>>> so
>>>>> will
>>>>>>> start
>>>>>>>>>> here
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have started to add module-info
>>> to
>>>>> our
>>>>>>> project
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue I found is:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> openjpa depends on "Apache
>>> Geronimo
>>>>> JPA
>>>>>>> Spec
>>>>>>>>>> 2.2"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> geronimo jpa doesn't have
>>> automatic
>>>>>>> module name
>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> automatically
>>>>>>>>>>>>>>>>>>>>>>>>> being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolved as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> geronimo.jpa.2.2.spec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which is invalid java identifier
>>> :(((
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe it would be possible to
>>> release
>>>>> same
>>>>>>>>>> artifact
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> module name for ex.
>>>>>>> `geronimo.jpa_2_2.spec` and
>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>> incremented micro
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> version?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Or maybe there are other options
>>> I\,
>>>>> not
>>>>>>> aware
>>>>>>>>>> of?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WBR
>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>
>
>
> --
> WBR
> Maxim aka solomax
Re: geronimo_jpa dependency and java11
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 29 févr. 2020 à 16:58, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> > 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> > comply with it today
>
> Yes, we should just pimp all our specs to also include module names.
> But please no module-info class which kills Java8 projects.
>
> An easy way to resolve this is to have this 1 out of 1000 (rather 10.000)
> users just exclude geronimo-jpa and add their own (compatible) eclipse jpa
> jar. Better than to break existing projects (that's how I found out...).
>
Factually not a single spec impl should be broken by any change in that
area since we shouldnt provide any spec api in user land, so for anyone it
must stay a noop.
>
> And no, we should not could on adding the 'official' Eclipse JARs in the
> future. We first need to look how they handle licensing.
> If they are still EPL then probably ok. If they really switch to the
> Eclipse Specification License and Eclipse TCK License, then it might become
> an issue.
> The new Eclipse Specification License and TCK license are not even Open
> Source Licenses.
> Once it hits the road I'm sure it will be classified as Cat-X even.
>
Agree.
>
> EPLv2 is Cat-B, thus we must label it's inclusion and notify downstream
> users. That's not per se bad, but annoying.
> People often confuse EPLv2 with EPL-1.0 which was essentially a BSD
> derivative. EPLv2 is a mixture between BSD with some GPL aspects.
>
Agree.
>
> I really do see no reason to ship anything if we have a proper
> implementation ourselves.
>
Simplify the exclusions.
Today, all projects tend to move to eclipse bundles (read it as "gav") so
exclusions are finally almost unified (unique) and pointless (yeah), if we
keep using org.apache.geronimo.specs, we don't help in that area but this
is ok while we are not transitive I guess.
> Yes, this is a mere legal problem. Not unimportant nonetheless.
>
> LieGrue,
> strub
>
> > Am 29.02.2020 um 16:23 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid>
> a
> > écrit :
> >
> >> Btw, the whole module system is a big fail.
> >> There are right now discussions in BIG projects to skip all that and
> >> revert to just plain jars again.
> >>
> >> The point is that we right now have our own sources and are fine with
> it.
> >> I really don't understand the point of changing this in a minor version.
> >>
> >
> > There are a few thgs to consider I think:
> >
> > 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> > comply with it today
> > 2. We must ensure to have the same name than the official spec jar
> > otherwise your link descriptor - module info - looses its portability
> > 3. We must not deliver the spec jar transitively so the one we build
> > against must not be important except for the assembly (if no more
> relevant
> > we can drop it IMHO)
> >
> > Now, if the action is to rerelease jpa geronimo jar with the official
> > mofule name, lets just do it if jakarta jar license is not asf friendly -
> > will be needed for asf projects delivering it anyway.
> >
> > Hope it makes sense.
> >
> >
> >
> >> LieGrue,
> >> strub
> >>
> >>> Am 29.02.2020 um 16:09 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >>> :
> >>>
> >>> Sorry that this slipped. This imo needs further discussion.
> >>> The license aspect is not clear imo.
> >>> We also break many downstream openjpa users which had their whole
> >> toolset tailored for geronimo-specs.
> >>>
> >>> I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <solomax666@gmail.com
> >:
> >>>>
> >>>> You are right
> >>>> this change breaks java8 build
> >>>> OK, my PR will stay the same :))
> >>>>
> >>
>
>
Re: geronimo_jpa dependency and java11
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> comply with it today
Yes, we should just pimp all our specs to also include module names.
But please no module-info class which kills Java8 projects.
An easy way to resolve this is to have this 1 out of 1000 (rather 10.000) users just exclude geronimo-jpa and add their own (compatible) eclipse jpa jar. Better than to break existing projects (that's how I found out...).
And no, we should not could on adding the 'official' Eclipse JARs in the future. We first need to look how they handle licensing.
If they are still EPL then probably ok. If they really switch to the Eclipse Specification License and Eclipse TCK License, then it might become an issue.
The new Eclipse Specification License and TCK license are not even Open Source Licenses.
Once it hits the road I'm sure it will be classified as Cat-X even.
EPLv2 is Cat-B, thus we must label it's inclusion and notify downstream users. That's not per se bad, but annoying.
People often confuse EPLv2 with EPL-1.0 which was essentially a BSD derivative. EPLv2 is a mixture between BSD with some GPL aspects.
I really do see no reason to ship anything if we have a proper implementation ourselves.
Yes, this is a mere legal problem. Not unimportant nonetheless.
LieGrue,
strub
> Am 29.02.2020 um 16:23 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> Btw, the whole module system is a big fail.
>> There are right now discussions in BIG projects to skip all that and
>> revert to just plain jars again.
>>
>> The point is that we right now have our own sources and are fine with it.
>> I really don't understand the point of changing this in a minor version.
>>
>
> There are a few thgs to consider I think:
>
> 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> comply with it today
> 2. We must ensure to have the same name than the official spec jar
> otherwise your link descriptor - module info - looses its portability
> 3. We must not deliver the spec jar transitively so the one we build
> against must not be important except for the assembly (if no more relevant
> we can drop it IMHO)
>
> Now, if the action is to rerelease jpa geronimo jar with the official
> mofule name, lets just do it if jakarta jar license is not asf friendly -
> will be needed for asf projects delivering it anyway.
>
> Hope it makes sense.
>
>
>
>> LieGrue,
>> strub
>>
>>> Am 29.02.2020 um 16:09 schrieb Mark Struberg <struberg@yahoo.de.INVALID
>>> :
>>>
>>> Sorry that this slipped. This imo needs further discussion.
>>> The license aspect is not clear imo.
>>> We also break many downstream openjpa users which had their whole
>> toolset tailored for geronimo-specs.
>>>
>>> I'm +1 for a revert and cleanup of geronimo-jpa-spec.
>>>
>>> LieGrue,
>>> strub
>>>
>>>> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
>>>>
>>>> You are right
>>>> this change breaks java8 build
>>>> OK, my PR will stay the same :))
>>>>
>>
Re: geronimo_jpa dependency and java11
Posted by Romain Manni-Bucau <rm...@gmail.com>.
package means folders in which classes are, not jar.
For ref: https://github.com/apache/tomcat/tree/master/java/jakarta
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 sam. 29 févr. 2020 à 16:53, Maxim Solodovnik <so...@gmail.com> a
écrit :
> This is from tomcat.apache.org
>
> Users of Tomcat 10 onwards should be aware that, as a result of the
> move from Java EE to Jakarta EE as part of the transfer of Java EE to
> the Eclipse Foundation, the primary package for all implemented APIs
> has changed from javax.* to jakarta.*. This will almost certainly
> require code changes to enable applications to migrate from Tomcat 9
> and earlier to Tomcat 10 and later. A migration tool is under
> development to aid this process.
>
> On Sat, 29 Feb 2020 at 22:52, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le sam. 29 févr. 2020 à 16:48, Maxim Solodovnik <so...@gmail.com> a
> > écrit :
> >
> > > I'm OK with reverting if Automatic-Module-Name will be specified
> > >
> > > What is wrong with Jakarta licensing?
> > > Tomcat-10-M1 was just released with jakarta jars ....
> > >
> >
> > Dont think, they host the code as geronimo does.
> >
> >
> >
> > > On Sat, 29 Feb 2020 at 22:23, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > > wrote:
> > > >
> > > > Le sam. 29 févr. 2020 à 16:17, Mark Struberg
> <st...@yahoo.de.invalid>
> > > a
> > > > écrit :
> > > >
> > > > > Btw, the whole module system is a big fail.
> > > > > There are right now discussions in BIG projects to skip all that
> and
> > > > > revert to just plain jars again.
> > > > >
> > > > > The point is that we right now have our own sources and are fine
> with
> > > it.
> > > > > I really don't understand the point of changing this in a minor
> > > version.
> > > > >
> > > >
> > > > There are a few thgs to consider I think:
> > > >
> > > > 1. There is this 1 for 1000 users of jpms so even if a failure, we
> should
> > > > comply with it today
> > > > 2. We must ensure to have the same name than the official spec jar
> > > > otherwise your link descriptor - module info - looses its portability
> > > > 3. We must not deliver the spec jar transitively so the one we build
> > > > against must not be important except for the assembly (if no more
> > > relevant
> > > > we can drop it IMHO)
> > > >
> > > > Now, if the action is to rerelease jpa geronimo jar with the official
> > > > mofule name, lets just do it if jakarta jar license is not asf
> friendly -
> > > > will be needed for asf projects delivering it anyway.
> > > >
> > > > Hope it makes sense.
> > > >
> > > >
> > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > > > Am 29.02.2020 um 16:09 schrieb Mark Struberg
> > > <struberg@yahoo.de.INVALID
> > > > > >:
> > > > > >
> > > > > > Sorry that this slipped. This imo needs further discussion.
> > > > > > The license aspect is not clear imo.
> > > > > > We also break many downstream openjpa users which had their whole
> > > > > toolset tailored for geronimo-specs.
> > > > > >
> > > > > > I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > >> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <
> > > solomax666@gmail.com>:
> > > > > >>
> > > > > >> You are right
> > > > > >> this change breaks java8 build
> > > > > >> OK, my PR will stay the same :))
> > > > > >>
> > > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: geronimo_jpa dependency and java11
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Tomcat still has an ancient code structure. They still use ant. And they still have all the stuff checked in to their own project
https://github.com/apache/tomcat/tree/master/java/jakarta <https://github.com/apache/tomcat/tree/master/java/jakarta>
So they just renamed the package, but the sources are still all ASF with full ALv2 and no single line taken from Eclipse.
https://github.com/apache/tomcat/blob/master/java/jakarta/servlet/Filter.java <https://github.com/apache/tomcat/blob/master/java/jakarta/servlet/Filter.java>
So they are basically doing what we do at geronimo.
Parts of the specs are even 1:1 copied over from geronimo-specs.
And the servlet-api in geronimo is otoh copied over from tomcat.
LieGrue,
strub
> Am 29.02.2020 um 16:53 schrieb Maxim Solodovnik <so...@gmail.com>:
>
> This is from tomcat.apache.org
>
> Users of Tomcat 10 onwards should be aware that, as a result of the
> move from Java EE to Jakarta EE as part of the transfer of Java EE to
> the Eclipse Foundation, the primary package for all implemented APIs
> has changed from javax.* to jakarta.*. This will almost certainly
> require code changes to enable applications to migrate from Tomcat 9
> and earlier to Tomcat 10 and later. A migration tool is under
> development to aid this process.
>
> On Sat, 29 Feb 2020 at 22:52, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>> Le sam. 29 févr. 2020 à 16:48, Maxim Solodovnik <so...@gmail.com> a
>> écrit :
>>
>>> I'm OK with reverting if Automatic-Module-Name will be specified
>>>
>>> What is wrong with Jakarta licensing?
>>> Tomcat-10-M1 was just released with jakarta jars ....
>>>
>>
>> Dont think, they host the code as geronimo does.
>>
>>
>>
>>> On Sat, 29 Feb 2020 at 22:23, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>> Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid>
>>> a
>>>> écrit :
>>>>
>>>>> Btw, the whole module system is a big fail.
>>>>> There are right now discussions in BIG projects to skip all that and
>>>>> revert to just plain jars again.
>>>>>
>>>>> The point is that we right now have our own sources and are fine with
>>> it.
>>>>> I really don't understand the point of changing this in a minor
>>> version.
>>>>>
>>>>
>>>> There are a few thgs to consider I think:
>>>>
>>>> 1. There is this 1 for 1000 users of jpms so even if a failure, we should
>>>> comply with it today
>>>> 2. We must ensure to have the same name than the official spec jar
>>>> otherwise your link descriptor - module info - looses its portability
>>>> 3. We must not deliver the spec jar transitively so the one we build
>>>> against must not be important except for the assembly (if no more
>>> relevant
>>>> we can drop it IMHO)
>>>>
>>>> Now, if the action is to rerelease jpa geronimo jar with the official
>>>> mofule name, lets just do it if jakarta jar license is not asf friendly -
>>>> will be needed for asf projects delivering it anyway.
>>>>
>>>> Hope it makes sense.
>>>>
>>>>
>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>> Am 29.02.2020 um 16:09 schrieb Mark Struberg
>>> <struberg@yahoo.de.INVALID
>>>>>> :
>>>>>>
>>>>>> Sorry that this slipped. This imo needs further discussion.
>>>>>> The license aspect is not clear imo.
>>>>>> We also break many downstream openjpa users which had their whole
>>>>> toolset tailored for geronimo-specs.
>>>>>>
>>>>>> I'm +1 for a revert and cleanup of geronimo-jpa-spec.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <
>>> solomax666@gmail.com>:
>>>>>>>
>>>>>>> You are right
>>>>>>> this change breaks java8 build
>>>>>>> OK, my PR will stay the same :))
>>>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>
>
>
> --
> WBR
> Maxim aka solomax
Re: geronimo_jpa dependency and java11
Posted by Maxim Solodovnik <so...@gmail.com>.
This is from tomcat.apache.org
Users of Tomcat 10 onwards should be aware that, as a result of the
move from Java EE to Jakarta EE as part of the transfer of Java EE to
the Eclipse Foundation, the primary package for all implemented APIs
has changed from javax.* to jakarta.*. This will almost certainly
require code changes to enable applications to migrate from Tomcat 9
and earlier to Tomcat 10 and later. A migration tool is under
development to aid this process.
On Sat, 29 Feb 2020 at 22:52, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le sam. 29 févr. 2020 à 16:48, Maxim Solodovnik <so...@gmail.com> a
> écrit :
>
> > I'm OK with reverting if Automatic-Module-Name will be specified
> >
> > What is wrong with Jakarta licensing?
> > Tomcat-10-M1 was just released with jakarta jars ....
> >
>
> Dont think, they host the code as geronimo does.
>
>
>
> > On Sat, 29 Feb 2020 at 22:23, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> > >
> > > Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid>
> > a
> > > écrit :
> > >
> > > > Btw, the whole module system is a big fail.
> > > > There are right now discussions in BIG projects to skip all that and
> > > > revert to just plain jars again.
> > > >
> > > > The point is that we right now have our own sources and are fine with
> > it.
> > > > I really don't understand the point of changing this in a minor
> > version.
> > > >
> > >
> > > There are a few thgs to consider I think:
> > >
> > > 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> > > comply with it today
> > > 2. We must ensure to have the same name than the official spec jar
> > > otherwise your link descriptor - module info - looses its portability
> > > 3. We must not deliver the spec jar transitively so the one we build
> > > against must not be important except for the assembly (if no more
> > relevant
> > > we can drop it IMHO)
> > >
> > > Now, if the action is to rerelease jpa geronimo jar with the official
> > > mofule name, lets just do it if jakarta jar license is not asf friendly -
> > > will be needed for asf projects delivering it anyway.
> > >
> > > Hope it makes sense.
> > >
> > >
> > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > > Am 29.02.2020 um 16:09 schrieb Mark Struberg
> > <struberg@yahoo.de.INVALID
> > > > >:
> > > > >
> > > > > Sorry that this slipped. This imo needs further discussion.
> > > > > The license aspect is not clear imo.
> > > > > We also break many downstream openjpa users which had their whole
> > > > toolset tailored for geronimo-specs.
> > > > >
> > > > > I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > >> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <
> > solomax666@gmail.com>:
> > > > >>
> > > > >> You are right
> > > > >> this change breaks java8 build
> > > > >> OK, my PR will stay the same :))
> > > > >>
> > > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
--
WBR
Maxim aka solomax
Re: geronimo_jpa dependency and java11
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 29 févr. 2020 à 16:48, Maxim Solodovnik <so...@gmail.com> a
écrit :
> I'm OK with reverting if Automatic-Module-Name will be specified
>
> What is wrong with Jakarta licensing?
> Tomcat-10-M1 was just released with jakarta jars ....
>
Dont think, they host the code as geronimo does.
> On Sat, 29 Feb 2020 at 22:23, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid>
> a
> > écrit :
> >
> > > Btw, the whole module system is a big fail.
> > > There are right now discussions in BIG projects to skip all that and
> > > revert to just plain jars again.
> > >
> > > The point is that we right now have our own sources and are fine with
> it.
> > > I really don't understand the point of changing this in a minor
> version.
> > >
> >
> > There are a few thgs to consider I think:
> >
> > 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> > comply with it today
> > 2. We must ensure to have the same name than the official spec jar
> > otherwise your link descriptor - module info - looses its portability
> > 3. We must not deliver the spec jar transitively so the one we build
> > against must not be important except for the assembly (if no more
> relevant
> > we can drop it IMHO)
> >
> > Now, if the action is to rerelease jpa geronimo jar with the official
> > mofule name, lets just do it if jakarta jar license is not asf friendly -
> > will be needed for asf projects delivering it anyway.
> >
> > Hope it makes sense.
> >
> >
> >
> > > LieGrue,
> > > strub
> > >
> > > > Am 29.02.2020 um 16:09 schrieb Mark Struberg
> <struberg@yahoo.de.INVALID
> > > >:
> > > >
> > > > Sorry that this slipped. This imo needs further discussion.
> > > > The license aspect is not clear imo.
> > > > We also break many downstream openjpa users which had their whole
> > > toolset tailored for geronimo-specs.
> > > >
> > > > I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <
> solomax666@gmail.com>:
> > > >>
> > > >> You are right
> > > >> this change breaks java8 build
> > > >> OK, my PR will stay the same :))
> > > >>
> > >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: geronimo_jpa dependency and java11
Posted by Maxim Solodovnik <so...@gmail.com>.
I'm OK with reverting if Automatic-Module-Name will be specified
What is wrong with Jakarta licensing?
Tomcat-10-M1 was just released with jakarta jars ....
On Sat, 29 Feb 2020 at 22:23, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
> > Btw, the whole module system is a big fail.
> > There are right now discussions in BIG projects to skip all that and
> > revert to just plain jars again.
> >
> > The point is that we right now have our own sources and are fine with it.
> > I really don't understand the point of changing this in a minor version.
> >
>
> There are a few thgs to consider I think:
>
> 1. There is this 1 for 1000 users of jpms so even if a failure, we should
> comply with it today
> 2. We must ensure to have the same name than the official spec jar
> otherwise your link descriptor - module info - looses its portability
> 3. We must not deliver the spec jar transitively so the one we build
> against must not be important except for the assembly (if no more relevant
> we can drop it IMHO)
>
> Now, if the action is to rerelease jpa geronimo jar with the official
> mofule name, lets just do it if jakarta jar license is not asf friendly -
> will be needed for asf projects delivering it anyway.
>
> Hope it makes sense.
>
>
>
> > LieGrue,
> > strub
> >
> > > Am 29.02.2020 um 16:09 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> > >:
> > >
> > > Sorry that this slipped. This imo needs further discussion.
> > > The license aspect is not clear imo.
> > > We also break many downstream openjpa users which had their whole
> > toolset tailored for geronimo-specs.
> > >
> > > I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> > >
> > > LieGrue,
> > > strub
> > >
> > >> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
> > >>
> > >> You are right
> > >> this change breaks java8 build
> > >> OK, my PR will stay the same :))
> > >>
> >
--
WBR
Maxim aka solomax
Re: geronimo_jpa dependency and java11
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 29 févr. 2020 à 16:17, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> Btw, the whole module system is a big fail.
> There are right now discussions in BIG projects to skip all that and
> revert to just plain jars again.
>
> The point is that we right now have our own sources and are fine with it.
> I really don't understand the point of changing this in a minor version.
>
There are a few thgs to consider I think:
1. There is this 1 for 1000 users of jpms so even if a failure, we should
comply with it today
2. We must ensure to have the same name than the official spec jar
otherwise your link descriptor - module info - looses its portability
3. We must not deliver the spec jar transitively so the one we build
against must not be important except for the assembly (if no more relevant
we can drop it IMHO)
Now, if the action is to rerelease jpa geronimo jar with the official
mofule name, lets just do it if jakarta jar license is not asf friendly -
will be needed for asf projects delivering it anyway.
Hope it makes sense.
> LieGrue,
> strub
>
> > Am 29.02.2020 um 16:09 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >
> > Sorry that this slipped. This imo needs further discussion.
> > The license aspect is not clear imo.
> > We also break many downstream openjpa users which had their whole
> toolset tailored for geronimo-specs.
> >
> > I'm +1 for a revert and cleanup of geronimo-jpa-spec.
> >
> > LieGrue,
> > strub
> >
> >> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
> >>
> >> You are right
> >> this change breaks java8 build
> >> OK, my PR will stay the same :))
> >>
>
Re: geronimo_jpa dependency and java11
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Btw, the whole module system is a big fail.
There are right now discussions in BIG projects to skip all that and revert to just plain jars again.
The point is that we right now have our own sources and are fine with it.
I really don't understand the point of changing this in a minor version.
LieGrue,
strub
> Am 29.02.2020 um 16:09 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>
> Sorry that this slipped. This imo needs further discussion.
> The license aspect is not clear imo.
> We also break many downstream openjpa users which had their whole toolset tailored for geronimo-specs.
>
> I'm +1 for a revert and cleanup of geronimo-jpa-spec.
>
> LieGrue,
> strub
>
>> Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
>>
>> You are right
>> this change breaks java8 build
>> OK, my PR will stay the same :))
>>
Re: geronimo_jpa dependency and java11
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 29 févr. 2020 à 16:09, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> Sorry that this slipped. This imo needs further discussion.
> The license aspect is not clear imo.
> We also break many downstream openjpa users which had their whole toolset
> tailored for geronimo-specs.
>
Hmm, should not, concretely spec jar must not be transitive imho. If still
the case lets make it provided with a 3.2. having spec jar transitive is
too easy to break today with spring, ee stacks etc... and require 100% of
the time exclusions anyway (even just tomee requires it....).
> I'm +1 for a revert and cleanup of geronimo-jpa-spec.
>
+0 while assembly does not embed an eclipse jar Im happy and all jars of
the stack have a valid jpms name without breaking osgi meta.
> LieGrue,
> strub
>
> > Am 25.12.2019 um 12:40 schrieb Maxim Solodovnik <so...@gmail.com>:
> >
> > You are right
> > this change breaks java8 build
> > OK, my PR will stay the same :))
> >
> > On Wed, 25 Dec 2019 at 16:14, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >>
> >> Does not change the fact it is a j11 feature and our compile baseline
> is j8
> >> so nogo until it is a profile ;).
> >>
> >> Side note: dont think we must compile with j11, just run.
> >>
> >> Le mer. 25 déc. 2019 à 09:57, Maxim Solodovnik <so...@gmail.com> a
> >> écrit :
> >>
> >>> https://bugs.openjdk.java.net/browse/JDK-8212636
> >>>
> >>> On Wed, 25 Dec 2019 at 15:56, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>> wrote:
> >>>>
> >>>> Release? Source=target=8 should be enough otherwise you will not
> build on
> >>>> java 8.
> >>>>
> >>>> Le mer. 25 déc. 2019 à 09:48, Maxim Solodovnik <so...@gmail.com>
> a
> >>>> écrit :
> >>>>
> >>>>> It seems adding
> >>>>> <release>8</release>
> >>>>> to maven-compiler-plugin config seems to fix java11 build for me
> >>>>> Will add this change to PR as soon build will be successful
> >>>>>
> >>>>> On Wed, 25 Dec 2019 at 15:22, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> Le mer. 25 déc. 2019 à 06:17, Maxim Solodovnik <
> solomax666@gmail.com>
> >>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> Can I merge this PR?
> >>>>>>> I can additionally check compilation issues under java11 ....
> >>>>>>>
> >>>>>>> On Tue, 17 Dec 2019 at 14:29, Maxim Solodovnik <
> >>> solomax666@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Both fixed :)
> >>>>>>>>
> >>>>>>>> On Tue, 17 Dec 2019 at 13:53, Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Except one missing indent and probably the move from "stats" to
> >>>>>>>>> "statistics" it looks good to me, wdyt @Mark Struberg <
> >>>>>>> struberg@yahoo.de> ?
> >>>>>>>>>
> >>>>>>>>> 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. 17 déc. 2019 à 07:49, Maxim Solodovnik <
> >>>>> solomax666@gmail.com>
> >>>>>>> a
> >>>>>>>>> écrit :
> >>>>>>>>>
> >>>>>>>>>> https://github.com/apache/openjpa/pull/57
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 17 Dec 2019 at 13:19, Maxim Solodovnik <
> >>>>> solomax666@gmail.com
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Great,
> >>>>>>>>>>>
> >>>>>>>>>>> will do
> >>>>>>>>>>> I'm going to add Automatic-Module-Name
> >>>>>>>>>>>
> >>>>> `org.apache.openja.<module-name-with-dashes-replaced-with-dots>`
> >>>>>>>>>>> And we can discuss changes in "review" mode :)
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, 17 Dec 2019 at 13:13, Romain Manni-Bucau <
> >>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hmm, not exactly what i expected but it should work, not
> >>>>> just as
> >>>>>>>>>>>> transparent and integrated as i thought.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The end of the dependency mess is still key for me and
> >>> only
> >>>>> this
> >>>>>>> jar
> >>>>>>>>>> can
> >>>>>>>>>>>> justify the scope compile you spoke about, all G one
> >>> should
> >>>>> be
> >>>>>>> provides
> >>>>>>>>>>>> IMHO.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Dont think osgi is a blocker while you dont put it in the
> >>>>> karaf
> >>>>>>>>>> feature.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So tempted to say you can finish the pr.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Le mar. 17 déc. 2019 à 07:06, Maxim Solodovnik <
> >>>>>>> solomax666@gmail.com>
> >>>>>>>>>> a
> >>>>>>>>>>>> écrit :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> This is part of MANIFEST.MF
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Bundle-ManifestVersion: 2
> >>>>>>>>>>>>> Bundle-Vendor: Eclipse.org - EclipseLink Project
> >>>>>>>>>>>>> Require-Capability: osgi.ee; filter:="(&(osgi.ee
> >>>>>>>>>> =JavaSE)(version>=1.8)
> >>>>>>>>>>>>> )"
> >>>>>>>>>>>>> Import-Package:
> >>>>>>>>>> javax.sql;resolution:=optional,org.osgi.framework;reso
> >>>>>>>>>>>>> lution:=optional,org.osgi.service.jpa;version="1.1.0"
> >>>>>>>>>>>>> Implementation-Vendor: Eclipse.org - EclipseLink
> >>> Project
> >>>>>>>>>>>>> Export-Package:
> >>>>>>>>>> javax.persistence;jpa="2.2";version="2.2.3",javax.pers
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>> istence.criteria;jpa="2.2";version="2.2.3",javax.persistence.metamode
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>> l;jpa="2.2";version="2.2.3",javax.persistence.spi;jpa="2.2";version="
> >>>>>>>>>>>>> 2.2.3",org.osgi.service.jpa;version="1.1.0"
> >>>>>>>>>>>>> Bundle-Name: Jakarta Persistence API 2.2
> >>>>>>>>>>>>> Bundle-Version: 2.2.3
> >>>>>>>>>>>>> Bundle-ClassPath: .
> >>>>>>>>>>>>> Bundle-Activator:
> >>>>>>>>>> org.eclipse.persistence.javax.persistence.osgi.Activ
> >>>>>>>>>>>>> ator
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I was unable to find "Provide-Capability" in the jar
> >>> (but
> >>>>>>> maybe I was
> >>>>>>>>>>>>> looking in wrong place ...)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, 17 Dec 2019 at 12:58, Romain Manni-Bucau <
> >>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hmmm, looks like old style, doesnt it have
> >>>>> Provide-Capability
> >>>>>>>>>> somewhere
> >>>>>>>>>>>>>> (sorry i dont have a computer handy right now)?
> >>>>>>>>>>>>>> Maybe reopen a thread @g Mark if you want to do that,
> >>>>> but we
> >>>>>>>>>> should also
> >>>>>>>>>>>>>> include micrporofile in that thread to enforce our
> >>>>>>> consistence
> >>>>>>>>>> IMHO.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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. 17 déc. 2019 à 06:56, Maxim Solodovnik <
> >>>>>>>>>> solomax666@gmail.com> a
> >>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm not familiar with OSGI
> >>>>>>>>>>>>>>> jakarta.jas has `Activator implements
> >>>>>>>>>>>>> org.osgi.framework.BundleActivator`
> >>>>>>>>>>>>>>> and `OSGiProviderResolver implements
> >>>>>>> PersistenceProviderResolver,
> >>>>>>>>>>>>>>> PersistenceProvider`
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please let me know if I should proceed with my PR,
> >>> or
> >>>>> if it
> >>>>>>>>>> would be
> >>>>>>>>>>>>>>> better to dismiss it :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, 17 Dec 2019 at 04:42, Romain Manni-Bucau <
> >>>>>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Le lun. 16 déc. 2019 à 22:13, Mark Struberg
> >>>>>>>>>>>>> <st...@yahoo.de.invalid>
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> jakarta persistence is EPL. It's not a problem
> >>> to
> >>>>> add
> >>>>>>> it but
> >>>>>>>>>> would
> >>>>>>>>>>>>>>> love to
> >>>>>>>>>>>>>>>>> avoid it.
> >>>>>>>>>>>>>>>>> The simplest way would be to add those module
> >>>>>>> information to
> >>>>>>>>>>>>>>> Geronimo-jpa.
> >>>>>>>>>>>>>>>>> Could do a mass release of those specs then.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should stick to a single strategy for all spec
> >>>>> jars
> >>>>>>> with a
> >>>>>>>>>>>>> compatible
> >>>>>>>>>>>>>>>> license IMHO.
> >>>>>>>>>>>>>>>> I dont care which way we go but I dont want a
> >>> case by
> >>>>>>> case
> >>>>>>>>>> choice
> >>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>> would be hard to support.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also having jakarta deps will reduce dependency
> >>>>>>> management for
> >>>>>>>>>> post
> >>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>> so i see it as a 60-40 for jakata.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Am 16.12.2019 um 14:39 schrieb Maxim
> >>> Solodovnik <
> >>>>>>>>>>>>>>> solomax666@gmail.com>:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Here is the diff
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>> https://github.com/apache/openjpa/compare/OPENJPA-2798-java11-friendly
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:38, Maxim
> >>> Solodovnik <
> >>>>>>>>>>>>> solomax666@gmail.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Current status: In my branch I have changed
> >>>>>>> jpa_spec with
> >>>>>>>>>>>>>>>>>>> jakarta.persistence and the build is green
> >>>>>>>>>>>>>>>>>>> I can drop this branch if there is better
> >>> way to
> >>>>>>> achieve
> >>>>>>>>>> java11
> >>>>>>>>>>>>>>>>> compatibility :)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I always thought modules is like
> >>> dependencies
> >>>>>>>>>>>>>>>>>>> I only have openjpa dependency right now
> >>> and do
> >>>>>>> have all
> >>>>>>>>>>>>> transitive
> >>>>>>>>>>>>>>>>>>> jars available, so my pom is cleaner ...
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:32, Mark Struberg
> >>>>>>>>>>>>>>> <st...@yahoo.de.invalid>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I'm not sure what the status is right now.
> >>> But
> >>>>> one
> >>>>>>> of
> >>>>>>>>>> the big
> >>>>>>>>>>>>> pros
> >>>>>>>>>>>>>>>>> over the standard jpa api has always been that
> >>> it
> >>>>>>> works even
> >>>>>>>>>> with
> >>>>>>>>>>>>> OSGi.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Am 16.12.2019 um 14:24 schrieb Romain
> >>>>> Manni-Bucau
> >>>>>>> <
> >>>>>>>>>>>>>>>>> rmannibucau@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Not "compile time dependencies" but "spec
> >>>>> jars".
> >>>>>>> Mainly
> >>>>>>>>>>>>> because
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> user
> >>>>>>>>>>>>>>>>>>>>> must import it himself (this is what he
> >>> use to
> >>>>>>> code so
> >>>>>>>>>> it
> >>>>>>>>>>>>> should
> >>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>> first
> >>>>>>>>>>>>>>>>>>>>> level dep + to avoid the exclusion mess
> >>> since
> >>>>>>> there are
> >>>>>>>>>> like
> >>>>>>>>>>>>> 6-7
> >>>>>>>>>>>>>>> spec
> >>>>>>>>>>>>>>>>> jars
> >>>>>>>>>>>>>>>>>>>>> libs use and conflict).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 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 lun. 16 déc. 2019 à 14:15, Maxim
> >>>>> Solodovnik <
> >>>>>>>>>>>>>>> solomax666@gmail.com>
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> BTW why compile time dependency should't
> >>> be
> >>>>>>> transitive?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:12, Maxim
> >>>>> Solodovnik <
> >>>>>>>>>>>>>>> solomax666@gmail.com
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I can create PR in a minute (based on
> >>>>>>>>>>>>>>> OPENJPA-2798-java11-friendly
> >>>>>>>>>>>>>>>>>>>>>> branch)
> >>>>>>>>>>>>>>>>>>>>>>> Was planning to add
> >>>>> "Automatic-Module-Name"s to
> >>>>>>>>>> manifest
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Mon, 16 Dec 2019 at 20:03, Romain
> >>>>>>> Manni-Bucau <
> >>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Nobody uses it but adding them breaks
> >>> apps
> >>>>> ;),
> >>>>>>> yeah.
> >>>>>>>>>>>>>>>>>>>>>>>> Anyway openjpa shouldnt have jpa api
> >>>>> transitive
> >>>>>>>>>> anyway
> >>>>>>>>>>>>> IMHO so
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>> big
> >>>>>>>>>>>>>>>>>>>>>>>> deal while we dont break OSGi case in
> >>> the
> >>>>>>>>>> feature.xml.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 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 lun. 16 déc. 2019 à 13:52, Mark
> >>> Struberg
> >>>>>>>>>>>>>>>>> <st...@yahoo.de.invalid>
> >>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I'd go with fixing our module info in
> >>>>>>> geronimo-jpa.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> But otoh nobody is using modules
> >>> anyway it
> >>>>>>> seems ...
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Am 11.12.2019 um 06:39 schrieb Romain
> >>>>>>> Manni-Bucau <
> >>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes this one
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> For openjpa the challenge will
> >>> likely to
> >>>>> not
> >>>>>>> have
> >>>>>>>>>>>>>>> module-info in
> >>>>>>>>>>>>>>>>>>>>>> main
> >>>>>>>>>>>>>>>>>>>>>>>>>> artifacts - guess we can duplicate
> >>>>> artifacts
> >>>>>>> with a
> >>>>>>>>>>>>>>> classifier
> >>>>>>>>>>>>>>>>>>>>>> jpms or
> >>>>>>>>>>>>>>>>>>>>>>>>> so -
> >>>>>>>>>>>>>>>>>>>>>>>>>> to avoid to break some servers and
> >>> env.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Last thing to take care: all osgi
> >>>>>>> integration, i
> >>>>>>>>>> didnt
> >>>>>>>>>>>>> check
> >>>>>>>>>>>>>>>>>>>>>> jakarta jar
> >>>>>>>>>>>>>>>>>>>>>>>>>> supports it as well as our spec jar.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> So likely some validation work to do
> >>> but
> >>>>> yes
> >>>>>>> it
> >>>>>>>>>> sounds
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>> plan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Hope it helps even if not a straight
> >>>>> "yes".
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Le mer. 11 déc. 2019 à 03:57, Maxim
> >>>>>>> Solodovnik <
> >>>>>>>>>>>>>>>>>>>>>> solomax666@gmail.com> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Do you mean this one:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> <dependency>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>> <groupId>org.eclipse.persistence</groupId>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>> <artifactId>jakarta.persistence</artifactId>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> <version>2.2.2</version>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> </dependency>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Looks good to me!
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Shall I create PR? (the task seems
> >>> to be
> >>>>>>> doable
> >>>>>>>>>> for me
> >>>>>>>>>>>>> :)))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, 11 Dec 2019 at 01:03, Romain
> >>>>>>> Manni-Bucau <
> >>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I proposed some time ago to rename
> >>> them
> >>>>>>> all but
> >>>>>>>>>> since
> >>>>>>>>>>>>>>> jakarta
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>>>>>>>> eclipse
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> now, i guess well more move to
> >>> their
> >>>>>>> bundles.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Wdyt?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 10 déc. 2019 à 18:18, Maxim
> >>>>>>> Solodovnik <
> >>>>>>>>>>>>>>>>>>>>>> solomax666@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello All,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> not sure which list should I ask,
> >>> so
> >>>>> will
> >>>>>>> start
> >>>>>>>>>> here
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have started to add module-info
> >>> to
> >>>>> our
> >>>>>>> project
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue I found is:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> openjpa depends on "Apache
> >>> Geronimo
> >>>>> JPA
> >>>>>>> Spec
> >>>>>>>>>> 2.2"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> geronimo jpa doesn't have
> >>> automatic
> >>>>>>> module name
> >>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> automatically
> >>>>>>>>>>>>>>>>>>>>>>>>> being
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolved as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> geronimo.jpa.2.2.spec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which is invalid java identifier
> >>> :(((
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe it would be possible to
> >>> release
> >>>>> same
> >>>>>>>>>> artifact
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>> correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> module name for ex.
> >>>>>>> `geronimo.jpa_2_2.spec` and
> >>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>> incremented micro
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> version?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Or maybe there are other options
> >>> I\,
> >>>>> not
> >>>>>>> aware
> >>>>>>>>>> of?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> WBR
> >>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> WBR
> >>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> WBR
> >>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> WBR
> >>>>>>>> Maxim aka solomax
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> WBR
> >>>>>>> Maxim aka solomax
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> WBR
> >>>>> Maxim aka solomax
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> WBR
> >>> Maxim aka solomax
> >>>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>