Re: [jakarta.ee-community] Maven Versioning Rules

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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