| Re: [jakarta.ee-community] Maven Versioning Rules |
Shoot! As you can see, we were also talking with Ray and our wires got crossed as to who was going to post... :-) I'll let Ray and Tom drive this conversation going forward... :-)
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Kevin Sutter/Rochester/IBM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Cc: arjan tijms <arjan.tijms@xxxxxxxxx>, Thomas Watson/Austin/IBM@IBMUS
Date: 11/30/2018 11:11 AM
Subject: Re: [jakarta.ee-community] Maven Versioning Rules
I'm not going to pretend to be a JPMS expert, but I've been discussing this thread with our resident expert (Tom on copy). He's also been following the conversation. So, here's how we are approaching the problem...
Let's work through the potential mechanics.
1) Jakarta will add module names to spec APIs at some point, some already have them.
2) Developers will implement modules against the spec API modules and their modules will require spec API by module name.
This means that at runtime, the module name of the spec API MUST be identical to match their "requires" module-info keyword.
Any impl that also provides the API, in order to work against the application code MUST not only provide the same package, it MUST also use the module name of the spec API.
This is different from the past, because in the past the only contract was the packages exported by the API and imported by the impl. It did not matter where the packages came from on the classpath.
However, in JPMS the packages of the API are fundamentally tied to the module name of the API, they are a sealed unit.
To recap, any module that provides both the API and an IMPL MUST use the spec module name.
This clearly adds some key constraints going forward:
- API modules have to be assumed to be re-usable at runtime.
- Implementations that package the API MUST adopt the module name of the spec API, AND they must NOT remove any part of the spec's defined module-info, they can only add, otherwise they break the module's contract.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>, arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 11/29/2018 06:54 PM
Subject: Re: [jakarta.ee-community] Maven Versioning Rules
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
Perhaps there's someone in the community who understands all these constraints, and understands the Java Platform Module System, and can suggest the best approach going forward?
arjan tijms wrote on 11/29/18 2:57 AM:
Hi,
Currently Mojarra and EL-RI are two other projects that combine API and IMPL in a single jar.
In JSF/Mojarra there's an historic impediment where API classes contain large, even huge, amounts of implementation specific code.
See e.g. https://github.com/eclipse-ee4j/mojarra/blob/master/impl/src/main/java/javax/faces/component/UIData.java
It's almost an oxymoron, but it currently is what it is. It would be great to one day be able to split off a more pure API artefact, but it's far from trivial.
Kind regards,
Arjan
On Thu, Nov 29, 2018 at 8:56 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
All,
If course it is possible to work around having classes in two different jars. Tools can be changed, we can compile against different classes than we run against, tests can be changed etc.
But these don't change the fact that generally speaking it is a bad idea to package the same class into two different jars/modules. We might be able to make it workable in this specific case, but I'd much rather we had policy settings that avoided the need for such work arounds.
For many projects the API is an artifact produced entirely separately from the implementation and it is thus really bad practise to repackage the artifacts into a single artifacts. It can obscure copyright, and licensing, it can encourage alternate potentially different APIs, and it is going to make modules more difficult. Let's just stop doing it generally.
If there are specific projects where it makes sense, let's have a specific convention for combining API and implementation into a single "runtime" jar.
Cheers
On Thu., 29 Nov. 2018, 07:49 arjan tijms <arjan.tijms@xxxxxxxxxwrote:
Hi,
Well, not just like that of course, but there is a major new Maven version upcoming (Maven 4), and this could be a proposal for that.
On Thursday, November 29, 2018, Romain Grecourt <romain.grecourt@xxxxxxxxxx> wrote:
On 11/28/18 2:20 PM, arjan tijms wrote:
Hi,
On Wed, Nov 28, 2018 at 10:22 PM Romain Grecourt <romain.grecourt@xxxxxxxxxx> wrote:
Unfortunately there is no compile-only scope with Maven.
The closest thing is provided, however provided scope goes into the test classpath.
Isn't this something we can propose to Maven to add, potentially together with a well prepared pull request?
Adding a new scope to Maven would be a major change, I'm a little pessimistic that we'd be able to get that in with a nice PR ;)
Kind regards,
Arjan
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community