| Re: [mojarra-dev] Slight code reorg |
Given that The Best solution has been years in the making with little to show for it, is there something Good Enough we can do in the short term? I'd love to be able clean the build up, separating API from impl classes as much as we can. So far, I've experimented with two approaches: 1) Restructure the source tree, or 2) Add a profile (as shown below) to produce a "stripped" jar.
Reorganizing the code seems to be doable, but there's a fair bit of code shared between impl and API that will need to be removed, duplicated, or moved to another module. That last option would add, potentially, an api/ and (say) shared/ modules, increasing the number of artifacts to deploy, etc. I'm not sure that's a real big deal, as transitive deps should make that pretty transparent. Just (maybe) a bit more work at release time (based on my experience publishing jars, it should be mostly transparent).
Adding the extra profile minimizes changes to the repo, but would require more work in the CI and deploy/publish setup, which may not be desirable.
Personally, I prefer the reorg approach, as I think it would produce a cleaner build, and, perhaps, inch us closer to The Best solution that has eluded greater minds than I over the years. :)
Does anybody have a preference or further thoughts? I can produce
PRs for each approach to compare and contrast, if that would help.
Hi,
Partially the Faces API build is already doing something quite like this.
Ultimately, the best course of action would be to create an actual API artefact. There was some discussion about that here: https://github.com/eclipse-ee4j/mojarra/issues/4480
In the 5 or 6 years that this has been discussed only very little progress has been made though.
Kind regards,Arjan Tijms
On Wed, Jun 8, 2022 at 11:02 PM Jason Lee <jason@xxxxxxxxxxxxxxx> wrote:
_______________________________________________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
_______________________________________________ mojarra-dev mailing list mojarra-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mojarra-dev