Date   

Platform wide guideline for build-in annotation literals?

Arjan Tijms
 

Hi,

CDI 2.0 introduced a number of very convenient build-in annotation literals, for many of the annotations it owns and for some it doesn't own (JSR 330).

See: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals

I think something like this would be a prime candidate for an umbrella spec guideline so:

1. All specs do this for their relevant annotations (e.g. @Transactional in JTA, @ViewScoped in JSF, @RememberMe in Security, @Named in AtInject, etc)
2. All specs do this in a consistent way

Thoughts?

Kind regards,
Arjan Tijms


Re: Request for Maven Java EE 8 artifact

Bill Shannon
 

That's it!  Clearly you guys don't appreciate what we're giving you!  The deal is off!!!

:-)

Jeff Genender wrote on 08/31/2017 09:13 PM:

Love it!!

Jeff


On Aug 31, 2017, at 9:02 PM, Jason Greene <jason.greene@...> wrote:

JEE ? ;)

On Aug 31, 2017, at 4:30 PM, Bill Shannon <bill.shannon@...> wrote:

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
>
>









Re: Request for Maven Java EE 8 artifact

Jeff Genender
 

Love it!!

Jeff


On Aug 31, 2017, at 9:02 PM, Jason Greene <jason.greene@...> wrote:

JEE ? ;)

On Aug 31, 2017, at 4:30 PM, Bill Shannon <bill.shannon@...> wrote:

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
>
>








Re: Request for Maven Java EE 8 artifact

Jason Greene
 

JEE ? ;)

On Aug 31, 2017, at 4:30 PM, Bill Shannon <bill.shannon@...> wrote:

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
>
>








Re: Request for Maven Java EE 8 artifact

Bill Shannon
 

No, sorry.

Guillermo González de Agüero wrote on 08/31/2017 03:35 PM:

I can imagine the answer, but is there a possibility that we could provide a pull request for this now?


Regards,

Guillermo González de Agüero

El vie., 1 de septiembre de 2017 0:20, Bill Shannon <bill.shannon@...> escribió:
I think you should take this up with the owners of the next release.


Ondrej Mihályi wrote on 08/31/2017 03:10 PM:
Hi Bill,

Since the API artifact is distributed as a maven artifact, does it make sense to consider non-maven scenarios? It shouldn't be a problem to configure the Java EE maven project to produce both a lightweight artifact without dependencies and a fat shaded JAR, which would be distributed for people not using maven.

From a maven user's perspective, it's always been very weird to depend on a single shaded JAR artifact, without an option to depend on a non-shaded JAR that pulls in transitive dependencies. Most other projects provide both types of artifacts, the shaded fat one usually suffixed with -with-dependencies, e.g. javaee-api-with-dependencies.jar

I would strongly recommend going in line with the common practice of delivering both types of API artifacts. Of course, vendors can provide their own non-shaded API artifacts, but having a standard one would make life a lot easier for maven users.

Ondro

2017-08-31 23:08 GMT+02:00 Bill Shannon <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

Guillermo González de Agüero
 

I hope we have a chance to decide ;)


El jue., 31 de agosto de 2017 23:15, Kevin Sutter <kwsutter@...> escribió:
>  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

Guillermo González de Agüero
 

I can imagine the answer, but is there a possibility that we could provide a pull request for this now?


Regards,

Guillermo González de Agüero


El vie., 1 de septiembre de 2017 0:20, Bill Shannon <bill.shannon@...> escribió:
I think you should take this up with the owners of the next release.


Ondrej Mihályi wrote on 08/31/2017 03:10 PM:
Hi Bill,

Since the API artifact is distributed as a maven artifact, does it make sense to consider non-maven scenarios? It shouldn't be a problem to configure the Java EE maven project to produce both a lightweight artifact without dependencies and a fat shaded JAR, which would be distributed for people not using maven.

From a maven user's perspective, it's always been very weird to depend on a single shaded JAR artifact, without an option to depend on a non-shaded JAR that pulls in transitive dependencies. Most other projects provide both types of artifacts, the shaded fat one usually suffixed with -with-dependencies, e.g. javaee-api-with-dependencies.jar

I would strongly recommend going in line with the common practice of delivering both types of API artifacts. Of course, vendors can provide their own non-shaded API artifacts, but having a standard one would make life a lot easier for maven users.

Ondro

2017-08-31 23:08 GMT+02:00 Bill Shannon <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

Bill Shannon
 

I think you should take this up with the owners of the next release.

Ondrej Mihályi wrote on 08/31/2017 03:10 PM:

Hi Bill,

Since the API artifact is distributed as a maven artifact, does it make sense to consider non-maven scenarios? It shouldn't be a problem to configure the Java EE maven project to produce both a lightweight artifact without dependencies and a fat shaded JAR, which would be distributed for people not using maven.

From a maven user's perspective, it's always been very weird to depend on a single shaded JAR artifact, without an option to depend on a non-shaded JAR that pulls in transitive dependencies. Most other projects provide both types of artifacts, the shaded fat one usually suffixed with -with-dependencies, e.g. javaee-api-with-dependencies.jar

I would strongly recommend going in line with the common practice of delivering both types of API artifacts. Of course, vendors can provide their own non-shaded API artifacts, but having a standard one would make life a lot easier for maven users.

Ondro

2017-08-31 23:08 GMT+02:00 Bill Shannon <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

Ondrej Mihályi
 

Hi Bill,

Since the API artifact is distributed as a maven artifact, does it make sense to consider non-maven scenarios? It shouldn't be a problem to configure the Java EE maven project to produce both a lightweight artifact without dependencies and a fat shaded JAR, which would be distributed for people not using maven.

From a maven user's perspective, it's always been very weird to depend on a single shaded JAR artifact, without an option to depend on a non-shaded JAR that pulls in transitive dependencies. Most other projects provide both types of artifacts, the shaded fat one usually suffixed with -with-dependencies, e.g. javaee-api-with-dependencies.jar

I would strongly recommend going in line with the common practice of delivering both types of API artifacts. Of course, vendors can provide their own non-shaded API artifacts, but having a standard one would make life a lot easier for maven users.

Ondro

2017-08-31 23:08 GMT+02:00 Bill Shannon <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

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
>
>








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
 

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

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
 

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
 

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
 

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
 

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

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
 

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

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