Le sam. 29 févr. 2020 à 16:58, Mark Struberg <strub...@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 <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 :))
> >>>>
> >>
>
>

Reply via email to