| Re: [mojarra-dev] Slight code reorg |
_______________________________________________I got to discussing this with some other WildFly engineers, and Farah (thanks! :) suggested just using a separate profile. That would leave the code base as it (there's a fair bit of util code shared between impl and API class, which doesn't feel right to me, fwiw), and require only a simple build change, which would look a lot like this:
diff --git a/impl/pom.xml b/impl/pom.xml
index 26f6700860..4b5b74d412 100644
--- a/impl/pom.xml
+++ b/impl/pom.xml
@@ -442,4 +442,72 @@
</plugin>
</plugins>
</build>
+ <profiles>
+ <profile>
+ <id>stripped-jar</id>
+ <build>
+ <finalName>${project.artifactId}-${project.version}-stripped</finalName>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-jar-plugin</artifactId>
+ <version>3.2.2</version>
+ <configuration>
+ <archive>
+ <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
+ </archive>
+ <excludes>
+ <exclude>**/*.java</exclude>
+ <exclude>**/*.html</exclude>
+ <exclude>jakarta/**</exclude>
+ <exclude>META-INF/services/com.sun.faces.spi.injectionprovider</exclude>
+ <exclude>META-INF/mojarra-jsf-api-probe-provider.xml</exclude>
+ </excludes>
+ </configuration>
+ </plugin>
+ <!-- Creates the source jar -->
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-source-plugin</artifactId>
+ <version>3.2.1</version>
+ <configuration>
+ <excludes>
+ <exclude>jakarta/**</exclude>
+ <exclude>META-INF/services/com.sun.faces.spi.injectionprovider</exclude>
+ <exclude>META-INF/mojarra-jsf-api-probe-provider.xml</exclude>
+ </excludes>
+ </configuration>
+ <executions>
+ <execution>
+ <id>attach-sources</id>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+
+ <!--
+ Create Javadoc for API jar
+ -->
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-javadoc-plugin</artifactId>
+ <version>3.3.1</version>
+ <executions>
+ <execution>
+ <id>attach-javadocs</id>
+ <configuration>
+ <excludePackageNames>jakarta</excludePackageNames>
+ </configuration>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+ </build>
+ </profile>
+ </profiles>
</project>
Thoughts on either approach? I can go either way, so I hope at least one is acceptable. :)
On 6/8/22 6:37 AM, Jason Lee wrote:
Currently for WildFly, we maintain a fork of the Mojarra code base. There are some historical reasons for that that are no longer relevant, so I'd like to transition us to using the upstream Mojarra artifacts directly. One of things we do as part of our build and packaging step, though, is to exclude the API classes (javax.*/jakarta.*), which we include via jakarta.faces:jakarta.faces-api. As things stand now, we will need to continue maintaining our fork to continue the exclusions from the impl archive (I believe we separate the API classes so that we can prevent exposing impl classes to deployments, fwiw).
What I would like to propose and get some feedback on is creating a new module in https://github.com/eclipse-ee4j/mojarra/ to move the jakarta.* classes to a new module (e.g., api) and add a dependency on that to impl. I think that would also require some sort of change in jakarta.faces:jakarta.faces-api to adapt to that (unless this new module simply published under that G:A if Central would allow it).
Does anyone see a reason for NOT doing that? Things usually have a reason for being the way the are, so if I'm missing something, please educate me before I put the work in to create a PR. :P
Thanks!
_______________________________________________ mojarra-dev mailing list mojarra-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mojarra-dev
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mojarra-dev