On 11/08/2021 09:06, Adam Jack wrote:
I am traveling home from abroad right now but I can look into things when I
get settled back. That said, I am sure others are far less rusty than me on
this. That said, from my rusty/simplistic perspective:
Would the best case be that the whole stack be built with one
compiler/language version, the newest supported, so we uncover any build
issues and then mail them to teams? Would that be helpful to getting those
build issues resolved, or are such notifications going unanswered? Meaning
do we change the Java version and then wait, rather than work around things?
Sorry if that is missing something obvious (I haven’t touched Java in well
over a decade.)
Thanks. Additional eyes on this would be good.
I agree that in an ideal world, everything would build with the latest
version of Java. Switching from Java 8 to Java 11 was a step in that
direction.
The complicating factor is that the chain of dependencies leads back to
(branches of) projects that are no longer maintained and don't build
with Java >8. In some cases, updating the dependencies to newer branches
is an option. I managed to remove Commons Lang 2.x from the dependency
chain that way. However, there are some dependency chains where that
does not appear to be an option. Maybe the right answer is that we
should just provide JARs for such projects rather than trying to build them.
Also, there are potentially some dependencies where we aren't building
from source and perhaps should be such as the Eclipse JDT JAR.
Given that Tomcat is the only project really using Gump right now, I
think I am going to start there and work backwards checking dependencies
as I suspect some of those may be rather out of date. It might be that
the problem will turn out to be a lot simpler than it appears, once the
dependencies are tidied up.
Mark
Regards,
Adam
On Tue, Aug 10, 2021 at 11:15 PM Mark Thomas <ma...@apache.org> wrote:
On 10/08/2021 21:38, Mark Thomas wrote:
On 10/08/2021 21:17, Adam Jack wrote:
Thanks for the update. Good luck.
Thanks. I think I am going to need it. This is going to be *far* from
simple.
There is lots of code currently being built by Gump that needs changes
to build with Java 9+.
You will have seen I started to try and hack around the issues with
Commons Lang 2.4 (it was using source=1.4) but forcing source to 1.6
(the minimum Java 11 supports) just creates a different problem - the
source using "enum" as an identifier but it is a reserved word from Java
5 onwards.
I don't see a simple or quick solution for this.
Is there a way in Gump to get just some projects to build with a
different JAVA_HOME? Switching just the Tomcat 10.1.x builds to Java 11
is the minimum requirement. We can then take a harder look at the
dependency chains and see what we can do to update versions / trim
things down.
On the topic of dependency chains, log4j 1.2.x is currently blocking
progress.
I need to set the source and target to 1.6 (local testing on vmgump
suggests this will then work) but I don't know how to do that.
I see "POM overrides" in a few places But I can't figure out how to use
them. Is there a way to copy the log4j POM, store it somewhere in Gump
and then tweak it (essentially change "1.4" to "1.6")?
Mark
Mark
Adam
On Tue, Aug 10, 2021, 15:57 Mark Thomas <ma...@apache.org> wrote:
All,
Since Tomcat's main development branch now requires Java 11, I have
started the process of moving Gump over to Java 11.
So far, I have added Java 11 to the packages installed by Puppet.
I want to confirm that Java 11 has been installed, then I'll switch
JAVA_HOME to point to Java 11 rather than Java 8. In theory that should
'just work'. When it doesn't (optimistic soul that I am), we'll have to
see what fails and figure out the best way to deal with each issue.
Once everything is running smoothly on Java 11, then I'll remove Java
8.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
--
Sent from Mobile
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
