Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta nam

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Nice summary, Lilian.
 Thank you.

We do have to
keep in mind that Jakarta is producing standardized APIs, not a standardized
implementation.  Yes, Eclipse Glassfish will continue to exist.  But,
that is just one of, hopefully, many Compatible Implementations.  Knowing
and understanding the various dependencies among the various Jakarta EE
APIs will be quite helpful as we continue to discern the Big Bang vs Incremental
approaches.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta 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:
       Lilian
BENOIT <lilian.benoit@xxxxxxxxxx>
To:
       Jan
Supol <jan.supol@xxxxxxxxxx>
Cc:
       jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
       06/21/2019
07:19 AM
Subject:
       [EXTERNAL]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Sent
by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

Hi Jan,

Dependency graph is a view for helping, I hope. But it's don't say that
transition will be simple.
Goal is to have global picture for dependency view (API only, i agree)

Following dependencies are visible on graph :
   javax.activation.DataSource (dependency javax.xml.bind -> 
javax.activation)
   javax.xml.bind.JAXBElement

Following dependencies aren't visible on graph :
   javax.validation.ValidationException
   javax.xml.ws.Provider
But these are constraints for implementation.

This graph concern API only, you are right, the task is more complex for
implementation  of each specifications.
But Users concerns must be to front. Because success of this transition
is adoption for developers, customers and community.

Regard,
Lilian.

Le 20/06/2019 10:24, Jan Supol a écrit :
> Hi,
> I am afraid the transition would be more complex than what the graph
> shows. I assume the dependencies are taken from the APIs in the graph.
> The Specification is more than just the API, however, it is the
> Specification document, too. For instance, JAX-RS Spec document
> mentions the following dependencies:
> |javax.activation.DataSource|
> |javax.xml.bind.JAXBElement|
> |javax.validation.ValidationException|
> |javax.xml.ws.Provider|
> 
> These should be taken into an account as well.
> Best,
> Jan
> 
> On 20.06.2019 2:02, Lilian BENOIT wrote:
>> Hi,
>> 
>> I have generated dependency graph from your program with plantuml.
>> I think that it's more explicit than text only
>> 
>> I added also color to distinguish simple or complex case.
>>  - green  - simple case
>>  - yellow - complex case
>> 
>> The image is accessed at 
>> https://raw.githubusercontent.com/lilian-benoit/jkta/master/src/main/resources/depends.png
>> 
>> I have realized PR pour add this functionality 
>> https://github.com/tomitribe/jkta/pull/1
>> 
>> Currently, i generated text file. This file is passed as argument
to 
>> program plantuml.jar
>> 
>> 
>> Best regards,
>> Lilian.
>> 
>> 
>> Le 17/06/2019 07:08, David Blevins a écrit :
>>> Ok folks, more data for us to look at.
>>> 
>>> I've created a report of transitive dependents to answer the
>>> question,
>>> "if we rename api foo, what else has to be renamed?"
>>> 
>>>   -
>>> https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/transitive.adoc 
>>> Note we did have a report that showed maven dependencies. 
This is 
>>> the
>>> logical inverse of a maven dependency graph.  It's the
incoming
>>> dependencies, transitively walked backwards.
>>> 
>>> An example of why this is important.
>>> 
>>>   - fact: javax.ejb has a maven dependency on javax.transaction,
>>> javax.xml.rpc and javax.xml.rpc.soap
>>>   - question: Does renaming javax.ejb cause javax.transaction,
>>> javax.xml.rpc and avax.xml.rpc.soap to be renamed?
>>>   - answer: No. These apis do not have a reference to
javax.ejb and
>>> therefore could stay in javax even if javax.ejb is renamed
>>> 
>>> This graph was created by collecting all the jars published
to Maven
>>> central in the jakarta groupId, parsing them with ASM to collect
any
>>> form of "import", then chopping them up by logical
api package.
>>> 
>>> If you want to play with the code, you can find it here. 
I apologize
>>> in advance for the relative mess -- the code wasn't really
created 
>>> for
>>> sharing and therefore will be hard to follow.
>>> 
>>>   - https://github.com/tomitribe/jkta
>>> 
>>> 
>>> -David
>>> 
>>> _______________________________________________
>>> jakartaee-platform-dev mailing list
>>> jakartaee-platform-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or 
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev