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

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
|
|
Guillermo González de Agüero
toggle quoted messageShow quoted text
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
|
|
|
|
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
toggle quoted messageShow quoted text
|
|
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
toggle quoted messageShow quoted text
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
|
|
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
toggle quoted messageShow quoted text
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
|
|
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:
toggle quoted messageShow quoted text
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
|
|
Guillermo González de Agüero
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
toggle quoted messageShow quoted text
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
|
|
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:
toggle quoted messageShow quoted text
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
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
|
|

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? ;-)
toggle quoted messageShow quoted text
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:
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
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
|
|
Or whatever you guys end up calling it.
Not my problem! :-)
Kevin Sutter wrote on 08/31/2017 02:14 PM:
toggle quoted messageShow quoted text
> 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? ;-)
|
|

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
toggle quoted messageShow quoted text
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:
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
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
|
|
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:
toggle quoted messageShow quoted text
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
|
|
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
toggle quoted messageShow quoted text
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
|
|
Guillermo González de Agüero
I hope we have a chance to decide ;)
toggle quoted messageShow quoted text
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? ;-)
|
|
No, sorry.
Guillermo González de Agüero wrote on 08/31/2017 03:35 PM:
toggle quoted messageShow quoted text
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
|
|
toggle quoted messageShow quoted text
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? ;-)
|
|
toggle quoted messageShow quoted text
On Aug 31, 2017, at 9:02 PM, Jason Greene < jason.greene@...> wrote: JEE ? ;)
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? ;-)
|
|
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:
toggle quoted messageShow quoted text
JEE ? ;)
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? ;-)
|
|