Re: issues building 3.8.1 from source

Rene Cordier <[email protected]> Mon, 24 Jun 2024 10:55:02 +0700
Newsgroups gmane.comp.jakarta.james.user
Message-ID <[email protected]>
Hello Matt,

Interesting feedback.

For the docs part I guess you could potentially open a JIRA ticket 
making that proposition, kinda agree with you, would make sense it's 
disabled by default and that we build it explicitly with the CI in the 
Jenkinsfile instead for example.

Though 3.8.1 is still targeting the jdk 11, not 17. Better to build it 
with java 11 to be honest. The project has been upgraded to java 21 for 
3.9.0 though, so you know :)

Regarding -DskipTests and -Dmaven.test.skip=true quirk, it's 
interesting. Could also maybe open a ticket, I know that dependencies 
with maven in James are sometimes a bit too entangled and maybe it would 
make sense that you can compile the code source of the project without 
compiling the tests, might be healthier. I'm not sure if it's an easy 
win though, but worth taking a look.

Don't hesitate as well to open an other ticket for the warnings and 
errors popping up during the build despite it being successful. I 
noticed that as well, I think more specifically on the scala code part 
for example. Maybe could take time to take a look as well at some point.

Anyways thanks again for the constructive return of dev experience!

Cheers,

Rene.


On 6/9/24 11:41 PM, cryptearth wrote:
> 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 
>> <[email protected]>
>> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>