Hello Tuna,
thanks for your reply.
Although skipping the docs is an option for a successful build I see an
issue upstream:
1) docs should only be done if explicitly enabled - so they should be
disabled by default anyway
2) as building tools already make excessive use of reflections it would
be easy just to read java.home instead of require an environment to be
set - although I admit it can be expected from a dev system having such
environment set
Another quirk happens between -DskipTests and -Dmaven.test.skip=true:
while skipTests still compiles the test classes but just prevents the
tests from getting actually run the property flag also prevents the test
classes from being compiled. In case of James for a long time now in the
3.x branch this always causes the build to fail because something later
in the chain depends on some test classes to got built before. Looks
like a bad dependency to me: building of runtime code should not depend
on test code.
I also did a rerun using -T for multi threading - and although quite a
lot of warnings and even errors pop up during the build it still
finishes successful. I don't know if it would be worth to take a further
look into these issues if they don't cause any problems at runtime.
Greetings
Matt
Am 09.06.24 um 08:13 schrieb Tung Tran Van:
Hello Matt,
About JAVA_HOME, I think it is related to the maven javadoc plugin, which
requires JAVA_HOME to be set. In my development environment, I often use
the command: mvn clean package -DskipTests -Dmaven.javadoc.skip=true.
Tung,
Greetings from Vietnam
On Sun, Jun 9, 2024 at 7:29 AM cryptearth <cryptea...@cryptearth.de.invalid>
wrote:
Hello everyone,
just did a build of 3.8.1 from source and ran into a few quirks:
1) JAVA_HOME has to be set
As many of you know I use OpenSuSE as my main server OS (although from
day to day I reevaluate to stick to it) and until now I used the fresh
system to also compile James from source. Funny enough with all its
quirks I encountered of the years it worked fine with the usual "mvn
clean package -DskipTests".
But as I also did a run on my main system running Arch I ran into an
error due to I had not set JAVA_HOME explicitly.
Guess that's just another one of those "yea, suse does something
different than everyone else". Maybe this could added into the docs if
it isn't already?
2) 3.8.1 requires Java17 to build
Another issue on my Arch system happened due to its way newer Java
version 22. The build fails rather early on within the first few
sub-packages with something related to Scala. I'm not sure how this is
related to each other but as the error also had some lines in it with
"reflections" - well, as a Java dev I know: "When you think about using
reflections you don't need them as you do something way wrong!". So I
guess some changes between Java17 and Java22 lets the Scala compiler
fail fatal.
If someone wants to reproduce:
- set up two VMs: one with OpenSuSE LEAP15.5, the other one with Arch
- clone james-project with branch 3.8.1
- run: mvn clean package -DskipTests
With Java17 suse will build fine, Arch using Java22 fails rather early -
switching to Java17 on Arch gets the build quite far but then fails with
"JAVA_HOME not set" - after setting JAVA_HOME Arch also gets the build
done.
So long,
have a nice weekend everyone.
Matt
Greetings from Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
