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
