> 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 <rmannibu...@gmail.com>: > > Le sam. 29 févr. 2020 à 16:17, Mark Struberg <strub...@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 <strub...@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 <solomax...@gmail.com>: >>>> >>>> You are right >>>> this change breaks java8 build >>>> OK, my PR will stay the same :)) >>>> >>
