Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Maven Versioning Rules
On 11/28/18 2:51 AM, Marcel Schutte wrote:
Two points: first a +1 for Greg Wilkin's point and secondly an objection against the following section: 
	An extreme example of an API jar file is the "jakartaee.jar"
	file that we produce, which contains *no* code at all for
	any of the classes, and is not a valid class file for use
	at runtime.  It is suitable only for reference by the compiler.
	Most other API jar files will not take this extreme approach.
This disregards the use case of unit tests as is explained in Adam Bien's article [1]

This applies only to the EE6 API JAR (javax:javaee-api:6.0), it has been fixed since EE7 (javax:javaee-api:7.0)
We should probably remove the "no code" part of this section.

On Wed, Nov 28, 2018 at 10:38 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
Bill et al,

I disagree with the following section:
	The implementation jar file typically includes all the classes from
	the API jar file, plus whatever implementation classes are needed
	to produce a complete runtime.

	In some cases the implementation jar file might contain only
	the implementation artifacts, and depend on the API jar file
	for the API definitions, although this is discouraged for
	standalone implementations.

Having API classes in implementation jars just invites duplicate classes and reduces flexibility.  A jar that is "standalone" in one deployment may well be used as component in another, plus there is no general reason that multiple versions of an API cannot be deployed in the same classloader scope.    These issues have always existed, but will only be made more acute by JPMS.

The policy should default to having separate jars for API and implementation, with perhaps a naming convention for aggregating both if a single jar is really needed.

regards





On Wed, 28 Nov 2018 at 01:57, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
I sent this to the Specification Committee a few weeks ago and got no feedback,
which I assume means general support.  This seems like a good time to open up
the discussion in case there's anything we missed.

I've updated my Java EE "Maven Versioning Rules" document [1] to use the naming
scheme proposed by David Blevins [2].

Please review the Jakarta EE version [3] and send me feedback.

I'm primarily interested in whether I accurately represented the change from
the old naming rules to the new rules.  I'd prefer not to reopen the entire
discussion that led to the original set of rules.  However, there's lots of
other advice in the document that may need further updating for Jakarta EE
and we could discuss some of those issues.

Finally, while this is represented as "rules", these would clearly be guidelines
as far as EE4J projects are concerned, at least until any aspect of this becomes
a required part of a Jakarta EE specification.

Thanks.


[1] https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html
[2]
https://docs.google.com/document/d/1pm8fjNusxxecoI-9M-eYvnoTkmZTMraQETN7OeVyMnA/edit#heading=h.ma7xbsxflh33
[3] https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
_______________________________________________
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


--
Fotografie
http://schutte.name/

_______________________________________________
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

Back to the top