Date   

Re: RMI-IIOP proposed optional

Werner Keil
 

And so does a relatively recent version of WebLogic (12.1.3.x, I know there were a few updates, but the 12.x has not been replaced yet) at least in the German translation of
something like http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=ServicesSummaryPage
There both "Messaging" and "jCOM" still use the term "J2EE".

 @Bill maybe you might like to check with your colleagues, I don't have the time to file a bug for it, just tried at Atlassian for a bad German translation of a new Confluence build...


Re: RMI-IIOP proposed optional

Bill Shannon
 

At least "J2EE" was the correct term at one point, even though it's been obsolete for more than 10 years and we've been calling it "Java EE" longer than it was ever called "J2EE".

Suffering from our own branding success...

Werner Keil wrote on 08/03/2017 04:15 AM:

And so does a relatively recent version of WebLogic (12.1.3.x, I know there were a few updates, but the 12.x has not been replaced yet) at least in the German translation of
something like http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=ServicesSummaryPage
There both "Messaging" and "jCOM" still use the term "J2EE".

 @Bill maybe you might like to check with your colleagues, I don't have the time to file a bug for it, just tried at Atlassian for a bad German translation of a new Confluence build...



Re: RMI-IIOP proposed optional

Jens Engel
 

Hi,

thanks for your replies.

Sorry for the wrong wording. I still remember the rebranding vom J2EE to JEE which took a while to traverse through our company... I will now learn to say Java EE.

It's good to read that

"it just means that application servers won't need to provide remote EJBs based on RMI-IIOP starting from Java EE 8. Remote EJBs will still have the same features, although vendors will be able to base them on another technology." (Guillermo)

and

"While RMI-IIOP might be made optional, support for remote EJB invocations using EJB 3 style EJBs, including transaction support, will still be required.  The protocol used might be RMI-IIOP or it might be a vendor-specific protocol; the spec would no longer require a specific protocol." (Bill).

But where is this aspect expressed in the specification? When reading EE.2.7.4, EE.6.2.3.6 and EE.6.3 one might think remote EJB access might only be guaranteed to be done by protocols that do not suppport transactions. I would appreciate a clarification statement - added for example in section EE.2.7.4.

Although it's not following the latest design principles of microservice achitectures and such, I'm convinced that the support of transactions is one of the key features that helped Java EE Servers compete with established transaction processing systems and enter computing centers. The possibility of doing transactions remotely is then a subsequent requirement since Java EE claims to be decentralized and scalable. If such a basic feature could be removed from the infrastructure technology, decisions which platform to use for future applications might be taken against Java EE.

Regards,
-Jens


Re: RMI-IIOP proposed optional

Bill Shannon
 

Jens Engel wrote on 08/03/2017 06:16 AM:
Hi,

thanks for your replies.

Sorry for the wrong wording. I still remember the rebranding vom J2EE to JEE
which took a while to traverse through our company... I will now learn to say
Java EE.

It's good to read that

"it just means that application servers won't need to provide remote EJBs
based on RMI-IIOP starting from Java EE 8. Remote EJBs will still have the
same features, although vendors will be able to base them on another
technology." (Guillermo)

and

"While RMI-IIOP might be made optional, support for remote EJB invocations
using EJB 3 style EJBs, including transaction support, will still be
required. The protocol used might be RMI-IIOP or it might be a
vendor-specific protocol; the spec would no longer require a specific
protocol." (Bill).

But where is this aspect expressed in the specification? When reading
EE.2.7.4, EE.6.2.3.6 and EE.6.3 one might think remote EJB access might only
be guaranteed to be done by protocols that do not suppport transactions. I
would appreciate a clarification statement - added for example in section
EE.2.7.4.
The EJB spec should have clear functionality requirements that are independent
of the remote protocol being used. If this isn't clear in the EJB spec, we'll
make it clear at the time we remove the RMI-IIOP requirement.

EE.2.7.4 is already clear that EJBs may use other protocols. This section will
be updated and can be clarified when RMI-IIOP is actually made optional. (It's
too late to do anything for Java EE 8 since we've already submitted the
materials for the Final Approval Ballot, to start next week.)

In any event, feel free to file issues against the platform spec or the EJB spec
for sections that you think need to be made more clear.

Although it's not following the latest design principles of microservice
achitectures and such, I'm convinced that the support of transactions is one
of the key features that helped Java EE Servers compete with established
transaction processing systems and enter computing centers. The possibility of
doing transactions remotely is then a subsequent requirement since Java EE
claims to be decentralized and scalable. If such a basic feature could be
removed from the infrastructure technology, decisions which platform to use
for future applications might be taken against Java EE.
This level of transaction support was absolutely key to Java EE's success 18
years ago, but many things have changed since then and distributed transactions
are no longer considered a key technology. We've learned much better approaches
for creating distributed and scalable applications, and Java EE supports these
new approaches very well.


Re: RMI-IIOP proposed optional

Jens Engel
 

Hi Bill,

thanks for your answer.

I know that there are new ways for building applications but - well - there are existing applications which cannot easily be transformed into this direction - and I reckon that there are domains where classical data consistency requirements still apply.

Where do I have to "file this issue" (clarification that declaring RMI-IIOP as optional does not mean dropping requirements for transactional remoting) officially, so it will be considered in the work for future Java EE specs?

Best regards

-Jens


Re: RMI-IIOP proposed optional

Bill Shannon
 

Jens Engel wrote on 08/ 4/17 02:34 AM:
Hi Bill,

thanks for your answer.

I know that there are new ways for building applications but - well - there are existing applications which cannot easily be transformed into this direction - and I reckon that there are domains where classical data consistency requirements still apply.
Right, which is why I expect many Java EE vendors will be supporting these technologies for quite some time, even after they become optional.

Where do I have to "file this issue" (clarification that declaring RMI-IIOP as optional does not mean dropping requirements for transactional remoting) officially, so it will be considered in the work for future Java EE specs?
Java EE issue tracker
EJB issue tracker


Cats out of the bag... impact?

Jeff Genender
 

Any thoughts on impact from this?


What will this potentially do to this group?

Thanks,

Jeff


Re: Cats out of the bag... impact?

Martijn Verburg
 

I'm just amazed Paul Krill wrote an accurate and balanced article :-)


Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

Hi all,

Java EE 8 is near release and I'd like to request a simple change on the artifact layout that is published to Maven central.

Until Java EE 7 the artifact contained all the API classes packaged on it, which doesn't work with Maven dependency exclusions. It is ok when coding against that whole EE version, but becomes problematic when you want to upgrade one dependency API.

For example, I've been using CDI 2.0 on a patched Java EE 7 server.

For that project I need two provided dependencies: Java EE 7 (which bundles CDI 1.2) and CDI 2.0 to get access to the new interfaces. I won't have problems at runtime since the correct classes will be provided by the server, but at compile time the classpath has two versions of the same classes, and I can't easily do nothing to fix it

My request then is, now that we have the missing JPA API on Maven (thanks Lukas for that), could the Java EE 8 artifact just be an aggregator declaring dependencies to all other specs?

Using that approach we could benefit from Maven dependency exclusion mechanism and just exclude the "outdated" version.

This will become more important as side projects like MicroProfile gain momentum, since it also declares dependencies on EE specs and a lot of people will likely combine the two technologies.

Any thoughts?


Regards,

Guillermo González de Agüero



Re: Request for Maven Java EE 8 artifact

Werner Keil
 

Shouldn't there be a snapshot version e.g. in java.net/maven? (java.net still exists at least for that purpose) 

Regards,
Werner


Re: Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

I can't see it on https://maven.java.net/content/repositories/snapshots/javax/ and I haven't heard of any snapshots being published. I thought that would need to wait until all specs were final.


Regards,

Guillermo González de Agüero


El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...> escribió:
Shouldn't there be a snapshot version e.g. in java.net/maven? (java.net still exists at least for that purpose) 

Regards,
Werner


Re: Request for Maven Java EE 8 artifact

Lukas Jungmann
 

On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
I can't see it on https://maven.java.net/content/repositories/snapshots/javax/ and I haven't heard of any snapshots being published. I thought that would need to wait until all specs were final.
try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

Regards,
Guillermo González de Agüero
El mar., 22 de agosto de 2017 11:48, Werner Keil <@wernerkeil <mailto:@wernerkeil>> escribió:
Shouldn't there be a snapshot version e.g. in java.net/maven
<http://java.net/maven>? (java.net <http://java.net> still exists at
least for that purpose)
Regards,
Werner


Re: Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>




Re: Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>




Re: Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>




Re: Request for Maven Java EE 8 artifact

Bill Shannon
 

The Maven project that builds the API jar file does so by recompiling all the javax.* source files.  Because some of these source files have static dependencies on non-javax.* classes, those classes are needed when compiling.  Those other classes are not included in the API jar file.

Is this causing a problem for you, or does it just seem weird?

Guillermo González de Agüero wrote on 08/22/17 08:44 AM:

Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>





Re: Request for Maven Java EE 8 artifact

Guillermo González de Agüero
 

Hi Bill,

Sorry, I wasn't able to look at the JAR contents the other day and I only checked the POM.

What we have now is, as you said, a JAR which contains all the API classes on it. Its pom declares all its dependencies at optional. But those dependencies there are useless for the end user, since they are shaded into the JAR, so I cannot exclude them.

Imagine I'm working on a Java EE 7 application server that I've patched to use CDI 2.0. What I'd like to do is:

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>

            </exclusions>
        </dependency>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>


However, with the CDI 1.2 classes being bundled inside the Java EE API JAR, Maven can't remove them, and the compiler will find two versions of the same classes. If I try to use a method added in 2.0 to an existing class it doesn't compile as it happens to find the 1.2 version first.

The solution would be to remove all content from the Java EE API jar, and just mark all its dependencies as optional=false. That way, any application dependent on it will get all the APIs directly, while being able to exclude specific parts of it. Specific implementations could then be removed since the artifact would only depend on other already compiled artifacts.

This usecase will be more important as we move to more composable and customizable runtimes. Also, it's common for vendors to release beta versions of their server with just a few updated specs. There's an open source application server that is still not Java EE 7 certified as it lacks JPA 2.1 support, but everything else is there. I could exclude the JPA 2.1 API artifact and include the 2.0 one in that case. The way it works now, I'd have to put the Java EE 7 dependency and be careful not to use any JPA 2.1 added methods or classes.

My examples were on Java EE 7 which obviously cannot be changed at this point, but hopefelly we can make it for Java EE 8?


Regards,

Guillermo González de Agüero


El mié., 30 de agosto de 2017 23:46, Bill Shannon <bill.shannon@...> escribió:
The Maven project that builds the API jar file does so by recompiling all the javax.* source files.  Because some of these source files have static dependencies on non-javax.* classes, those classes are needed when compiling.  Those other classes are not included in the API jar file.

Is this causing a problem for you, or does it just seem weird?

Guillermo González de Agüero wrote on 08/22/17 08:44 AM:
Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>





Re: Request for Maven Java EE 8 artifact

Bill Shannon
 

Java EE 8 is essentially done.

Your suggested fix would result in an API jar file that's not usable by people who aren't using Maven.

If some application server provides a beta API that's not exactly Java EE, it should probably provide an API jar file in its own namespace so that users will know that what they're getting is not Java EE.

In any event, I'm going to leave this as an issue to be dealt with for Java EE 9.  Maybe then it will all just be modules and we won't have to worry about this!

Guillermo González de Agüero wrote on 08/31/2017 02:06 AM:

Hi Bill,

Sorry, I wasn't able to look at the JAR contents the other day and I only checked the POM.

What we have now is, as you said, a JAR which contains all the API classes on it. Its pom declares all its dependencies at optional. But those dependencies there are useless for the end user, since they are shaded into the JAR, so I cannot exclude them.

Imagine I'm working on a Java EE 7 application server that I've patched to use CDI 2.0. What I'd like to do is:

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>

            </exclusions>
        </dependency>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>


However, with the CDI 1.2 classes being bundled inside the Java EE API JAR, Maven can't remove them, and the compiler will find two versions of the same classes. If I try to use a method added in 2.0 to an existing class it doesn't compile as it happens to find the 1.2 version first.

The solution would be to remove all content from the Java EE API jar, and just mark all its dependencies as optional=false. That way, any application dependent on it will get all the APIs directly, while being able to exclude specific parts of it. Specific implementations could then be removed since the artifact would only depend on other already compiled artifacts.

This usecase will be more important as we move to more composable and customizable runtimes. Also, it's common for vendors to release beta versions of their server with just a few updated specs. There's an open source application server that is still not Java EE 7 certified as it lacks JPA 2.1 support, but everything else is there. I could exclude the JPA 2.1 API artifact and include the 2.0 one in that case. The way it works now, I'd have to put the Java EE 7 dependency and be careful not to use any JPA 2.1 added methods or classes.

My examples were on Java EE 7 which obviously cannot be changed at this point, but hopefelly we can make it for Java EE 8?


Regards,

Guillermo González de Agüero


El mié., 30 de agosto de 2017 23:46, Bill Shannon <bill.shannon@...> escribió:
The Maven project that builds the API jar file does so by recompiling all the javax.* source files.  Because some of these source files have static dependencies on non-javax.* classes, those classes are needed when compiling.  Those other classes are not included in the API jar file.

Is this causing a problem for you, or does it just seem weird?

Guillermo González de Agüero wrote on 08/22/17 08:44 AM:
Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>






Re: Request for Maven Java EE 8 artifact

Kevin Sutter
 

>  In any event, I'm going to leave this as an issue to be dealt with for Java EE 9.

There's going to be a Java EE 9?  ;-)

On Thu, Aug 31, 2017 at 4:08 PM, Bill Shannon <bill.shannon@...> wrote:
Java EE 8 is essentially done.

Your suggested fix would result in an API jar file that's not usable by people who aren't using Maven.

If some application server provides a beta API that's not exactly Java EE, it should probably provide an API jar file in its own namespace so that users will know that what they're getting is not Java EE.

In any event, I'm going to leave this as an issue to be dealt with for Java EE 9.  Maybe then it will all just be modules and we won't have to worry about this!


Guillermo González de Agüero wrote on 08/31/2017 02:06 AM:
Hi Bill,

Sorry, I wasn't able to look at the JAR contents the other day and I only checked the POM.

What we have now is, as you said, a JAR which contains all the API classes on it. Its pom declares all its dependencies at optional. But those dependencies there are useless for the end user, since they are shaded into the JAR, so I cannot exclude them.

Imagine I'm working on a Java EE 7 application server that I've patched to use CDI 2.0. What I'd like to do is:

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>

            </exclusions>
        </dependency>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>


However, with the CDI 1.2 classes being bundled inside the Java EE API JAR, Maven can't remove them, and the compiler will find two versions of the same classes. If I try to use a method added in 2.0 to an existing class it doesn't compile as it happens to find the 1.2 version first.

The solution would be to remove all content from the Java EE API jar, and just mark all its dependencies as optional=false. That way, any application dependent on it will get all the APIs directly, while being able to exclude specific parts of it. Specific implementations could then be removed since the artifact would only depend on other already compiled artifacts.

This usecase will be more important as we move to more composable and customizable runtimes. Also, it's common for vendors to release beta versions of their server with just a few updated specs. There's an open source application server that is still not Java EE 7 certified as it lacks JPA 2.1 support, but everything else is there. I could exclude the JPA 2.1 API artifact and include the 2.0 one in that case. The way it works now, I'd have to put the Java EE 7 dependency and be careful not to use any JPA 2.1 added methods or classes.

My examples were on Java EE 7 which obviously cannot be changed at this point, but hopefelly we can make it for Java EE 8?


Regards,

Guillermo González de Agüero


El mié., 30 de agosto de 2017 23:46, Bill Shannon <bill.shannon@...> escribió:
The Maven project that builds the API jar file does so by recompiling all the javax.* source files.  Because some of these source files have static dependencies on non-javax.* classes, those classes are needed when compiling.  Those other classes are not included in the API jar file.

Is this causing a problem for you, or does it just seem weird?

Guillermo González de Agüero wrote on 08/22/17 08:44 AM:
Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>







Re: Request for Maven Java EE 8 artifact

Bill Shannon
 

Or whatever you guys end up calling it.

Not my problem!  :-)

Kevin Sutter wrote on 08/31/2017 02:14 PM:

>  In any event, I'm going to leave this as an issue to be dealt with for Java EE 9.

There's going to be a Java EE 9?  ;-)

On Thu, Aug 31, 2017 at 4:08 PM, Bill Shannon <bill.shannon@...> wrote:
Java EE 8 is essentially done.

Your suggested fix would result in an API jar file that's not usable by people who aren't using Maven.

If some application server provides a beta API that's not exactly Java EE, it should probably provide an API jar file in its own namespace so that users will know that what they're getting is not Java EE.

In any event, I'm going to leave this as an issue to be dealt with for Java EE 9.  Maybe then it will all just be modules and we won't have to worry about this!


Guillermo González de Agüero wrote on 08/31/2017 02:06 AM:
Hi Bill,

Sorry, I wasn't able to look at the JAR contents the other day and I only checked the POM.

What we have now is, as you said, a JAR which contains all the API classes on it. Its pom declares all its dependencies at optional. But those dependencies there are useless for the end user, since they are shaded into the JAR, so I cannot exclude them.

Imagine I'm working on a Java EE 7 application server that I've patched to use CDI 2.0. What I'd like to do is:

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>

            </exclusions>
        </dependency>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>


However, with the CDI 1.2 classes being bundled inside the Java EE API JAR, Maven can't remove them, and the compiler will find two versions of the same classes. If I try to use a method added in 2.0 to an existing class it doesn't compile as it happens to find the 1.2 version first.

The solution would be to remove all content from the Java EE API jar, and just mark all its dependencies as optional=false. That way, any application dependent on it will get all the APIs directly, while being able to exclude specific parts of it. Specific implementations could then be removed since the artifact would only depend on other already compiled artifacts.

This usecase will be more important as we move to more composable and customizable runtimes. Also, it's common for vendors to release beta versions of their server with just a few updated specs. There's an open source application server that is still not Java EE 7 certified as it lacks JPA 2.1 support, but everything else is there. I could exclude the JPA 2.1 API artifact and include the 2.0 one in that case. The way it works now, I'd have to put the Java EE 7 dependency and be careful not to use any JPA 2.1 added methods or classes.

My examples were on Java EE 7 which obviously cannot be changed at this point, but hopefelly we can make it for Java EE 8?


Regards,

Guillermo González de Agüero


El mié., 30 de agosto de 2017 23:46, Bill Shannon <bill.shannon@...> escribió:
The Maven project that builds the API jar file does so by recompiling all the javax.* source files.  Because some of these source files have static dependencies on non-javax.* classes, those classes are needed when compiling.  Those other classes are not included in the API jar file.

Is this causing a problem for you, or does it just seem weird?

Guillermo González de Agüero wrote on 08/22/17 08:44 AM:
Excuse me all for flooding.

The JSF dependency I was seeing is Mojarra implementation, which I don't think belongs there:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

That's present in both the web and full poms. I guess that one can be removed and then only a javax.* JavaMail would be needed.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:40, Guillermo González de Agüero <z06.guillermo@...> escribió:
Sorry Lukas, didn't look at the content of the POM. Looks like you already took care of this. That's just great.

I see some implementation APIs there though for JSF and JavaMail. Could that APIs be also uploaded to Maven Central as you did with JPA (btw, that one also needs to be updated on the Pom)?

Thanks a lot for this Lukas.


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:31, Guillermo González de Agüero <z06.guillermo@...> escribió:
Thanks, now I see.

The last one seems to be from June. Could you please consider mi suggestion about the artifact layout?


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 17:11, Lukas Jungmann <lukas.jungmann@...> escribió:
On 8/22/17 12:25 PM, Guillermo González de Agüero wrote:
> I can't see it on
> https://maven.java.net/content/repositories/snapshots/javax/ and I
> haven't heard of any snapshots being published. I thought that would
> need to wait until all specs were final.

try https://maven.java.net/content/repositories/promoted/javax/javaee-api/

thanks,
--lukas

>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 22 de agosto de 2017 11:48, Werner Keil <werner.keil@...
> <mailto:werner.keil@...>> escribió:
>
>     Shouldn't there be a snapshot version e.g. in java.net/maven
>     <http://java.net/maven>? (java.net <http://java.net> still exists at
>     least for that purpose)
>
>     Regards,
>     Werner
>
>