|
|
Thanks Ramsey. You’re a scholar and a gentleman. I’ll ask the PHB if I can have some leeway to try that Maven structure :-) Thanks for these tips!
If you have an Eclipse with m2e installed (I think it's preinstalled these days), maven should mostly "just work." I found
Very helpful in making maven accommodate the fuzzy bunny layout. I would suggest continued use of fuzzy bunny as the WOLips plugin is a little rough around the edges when it comes to trying to use a standard maven project layout.
The pom.xml file in the wodocker project might be instructive too. Specifically, the <repositories> part. If you do that, you don't need to muck around with ~/.m2/settings.xml at all or even bother to install WebObjects with the WOInstaller.jar anymore. WOLips can now find all the wojars via maven and you can just ignore the WORoot/System Root/User Root/etc settings in the wolips plugin preferences altogether.
WOLips itself is also easier to develop/contribute now in this regard. No WO installation is necessary to do that anymore either.
I mostly use maven via eclipse, I don't really use the command line unless there is not another nice way to do something ��
Hi Ramsey and thank you! That’s some good information. Thanks for taking the time to try that. You make it sound easy but I was coming up empty :-)
So basically you said “forget JavaXML” framework and completely avoided it. Then you deleted some source files that dealt with Axis which came from JavaXML because… well… it was a neat concept back in the day but we aren’t really using it. I assume you added the javax.servlet and xerces because they were needed and used to be accessed from JavaXML. Ok… I get the idea. Creative :-) Not really that straightforward but makes sense after you figured it out and shared with us.
I think maybe I should move our build to Maven and start there first and then maybe modernize our apps as best as I can while getting rid of certain dependencies like JavaXML.framework like you had done. In other words… I should probably do Maven first and then Java 17 second. I’ll maybe compile the WOnder files in java 1.8 compliance mode (at least for now).
Is this the best primer on getting Maven working in Eclipse?
It's got a note from Ray Kiddy on 2022 06-24 that at least part of it doesn’t work.
It also talks about three ways… mvn eclipse:eclipse, m2eclipse, and q4e…. which of the three is best? perhaps m2eclipse?
Thank you, — Aaron
I'm not totally sure, because I haven't tried to migrate wonder to 17 yet, but I think it's possible. With regards to compiling ERExtensions with Java 17, I did that, saw your error, and corrected it on ERExtensions:
I updated the /pom.xml file to source/target 17 instead of 1.8.
I added an exclusion to JavaWebObjects in the same file, excluding com.webobjects/JavaXML.
I deleted the WOWebServicePatch.java, because I don't want to drag in Apache Axis with all its vulns for something nobody uses anyway. I removed the reference to it in ERXApplication.
In ERExtensions/pom.xml, I added dependencies for javax.servlet/servlet-api/2.5 and xerces/xerces/2.4.0. I would probably do this in the parent IRL and manage the dependencies there, but for this quick test, that's what I did.
And now ERExtensions compiles without error in eclipse. There are a few other projects that have compile errors and need some repair for a full Java 17 patch to be attained. Some are really old and I don't know if anyone even cares about them anymore.
Thanks Ramsey but now I’m more confused.
Can we compile for Java 17 compliance or not? Before it sounded like you said it wasn’t possible but now it sounds like you are saying it is possible.
I tried to take one WOnder project, ERExtensions, and make it compile for java 17 but I couldn’t get it to work in Eclipse. Files like ERXApplication.java complain: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml
I’m not adding a module-info.java or trying to force it in any way to have extra jigsaw JMPS bells and whistles. If I make it compile for java 1.8 (like the .project file does in WOnder) then it’s happy. Change it to java 17 compliance and it fails.
In our own app, where we include things like “com.webobjects.eoaccess.EOAttribute” I get: The package com.webobjects.eoaccess is accessible from more than one module: ERExtensions, javaeoaccess
I only tried creating a module-info.java to see if that could buy us anything but I don’t think it can.
I’m looking at your docker project right now. You mentioned it earlier but I didn’t understand and still don’t really. I’m not wanting to use docker right now… but maybe your point is that this is a simple WO app using Java 17 that happens to be in docker. I’m looking around the project in GitHub that you made and see that it is pretty simple, like a proof of concept. Thank you. Is it possible that it’s so simple that there aren’t any conflicts with duplicate package definitions in different jars? Have you been able to do this with an large/real project?
If Java 17 compliance is possible, what am I missing to be able to do it in Eclipse?
Did you have a chance to look at
It uses Java 17, and it works
I think the main confusion is thinking we have to use jigsaw post-java 8, but that's not a requirement. There's no module-info.java in that project, but it still works like WO always did.
Wonder can probably be updated similarly, but I see no need to cut off anyone still using 8 just so one of the three patches received a year can use a switch expression or something like that :) Maybe when JEP 182 kicks in and Java 8 can no longer compile with latest JDK, then there is more reason to update it. That said, I'm also not against updating to 17 or whatever the latest LTS happens to be if everyone loves that idea.
Thanks Ramsey,
To be clear, your situation is that you develop and deploy on a Java 17 VM but you compile for Java 8 (1.8). This affords you a modern VM with any of the latest security and timestamp updates. It also affords you the use of Apple WebObjects and WOnder with little effort (besides the ALL-UNNAMED tweak).
Did I get that correct (at least roughly?)
I want to be clear about it because it’s easy for someone to say or hear “They are on Java 17” and not fully interpret what it means. I think all of us, if we are “on Java 17” are running in 1.8 compliance mode.
>If we are targeting Java 17 compliance
I don't really see any need for WOnder to go java 17 in source. There's not a lot of active development happening in Wonder, so it would be unnecessary work to do that and limit backward compatibility with those still using 8. I just care that it continues to build without errors using the latest java. That's what origin/master should do now.
As you pointed out, without access to source, it is getting harder and harder to drag WebObjects into the future.
[You don't often get email from aaron@chatnbike.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] The package com.webobjects.eoaccess is defined in both: ERExtensions, javaeoaccess javaeoaccess is a framework from NeXT/Apple. I believe ERExtensions recreated a distinctly apple package name so that we could replace Apple's _EOExpressionArray with a new one from Wonder. This worked because if we load ERExtensions before JavaEOAccess.framework… in the class path, the first one wins. Old JVMs would happily take the first. While this is risky, it worked as long as we were careful (and sort of knew what Apple was doing). We did things like this because we didn’t own JavaEOAccess and basically “patched it” because we wanted an improvement that Apple didn’t provide. We could do better than Apple and this is how we did it, while letting the rest of the Apple plumbing continue working with particular object replacements. This cannot work past Java 1.8 can it? If we are targeting Java 17 compliance, we are then using JPMS (Java Package Module System) aka “Java Modules” which won’t accept this type of patch. In my application project, I created a module-info.java and placed these lines in it: requires ERExtensions; requires javaeoaccess; We need both lines right? But this results in the the following unsurprising error: The package com.webobjects.eoaccess is accessible from more than one module: ERExtensions, javaeoaccess What am I missing? Are we stuck? Without being able to update the Apple jars directly, the old hacks cannot work in the new word of Java Modules. We’ve done this in many places including NSArray. Are we stuck living in Java 1.8 compliance with Java 17? ############################################################# This message is sent to you because you are subscribed to the mailing list < webobjects-dev@wocommunity.org>. To unsubscribe, E-mail to: < webobjects-dev-off@wocommunity.org> To switch to the DIGEST mode, E-mail to < webobjects-dev-digest@wocommunity.org> To switch to the INDEX mode, E-mail to < webobjects-dev-index@wocommunity.org> Send administrative queries to < webobjects-dev-request@wocommunity.org>
Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
|
|