WebObjects Unsupported major.minor version 49.0 error - webobjects

I have been asked to update some old code I worked on years ago. All in xCode no eclipse and the change is needed urgently so do not have time to migrate away from xCode ATM.
I got my hands on a OS 10.5.8 box installed xcode 3.1.4 and the code compiled fine locally.
Tried to deploy never worked " Unsupported major.minor version 49.0 error" seems the server is running JVM 1.4.2 I have 1.6 locally. I followed some instructions on how to downgrade my local machine to java 1.4.2 without success.
So I gave up and put an old copy of the site back on the server. But now ALL the sites on the server get that same error message and none of them will start even though they have not been touched in 3-4 years. Not sure what happened? my only logically explanation is i accidentally did one action on the server instead of locally? Either way I have no idea what is wrong or how to fix it?
Where do I start trying to debug this?
Can I install a new version of java 1.5 or 1.6 on the server (OS 10.3.9) and have it work ok with webobjects?

Was this project a framework or an Application? If it is a framework that is depended-on by the other WebObjects projects, that would explain why everything started failing when you updated this project.
By default, Xcode did not include (or "embed") any depended-upon libraries or frameworks in the Project.woa bundle. Apps built this way depend upon any required resources being available in a few specific locations and then load them at launch. If they all now link to a framework or library that is incompatible, then they'll all stop working.
As far as the actual "Unsupported major.minor version" error goes, you do not need to downgrade the version of Java on your Mac, you can simply tell the compiler to target an older version of Java.
I can't remember if Xcode used Ant to do its Java compiling, but if it did and you are using Ant 1.7 or later, you can force Ant to compile 1.4-compatible binaries with Java 1.6 by editing the build.xml file so the javac tag includes a "target" parameter such as: <javac target="1.4" ... /> or by passing in the ant.build.javac.target property when you call Ant, either via command line or by modifying a properties file that Ant will load. I believe build.properties still existed in Xcode-based WebObjects projects. If it does this would be a good place for the property.
The basics are covered by this stackoverflow question: How to compile classes to JDK1.5 when ant is running in JDK1.6

Related

Google Cloud SDK-based Maven plugin is forcing itself to update and then failing, when cloud sdk is up to date

I'm making a Java program which will be deployed to the Google App Engine and I'm using the Cloud SDK maven plugin version 2.4.0 to deploy to the GAE. However when I run mvn package appengine:deploy the cloud SDK will say its current version is 321.0.0 and needs to update to 327.0.0. The update will then fail with the error:
ERROR: (gcloud.components.update) Access is denied: [C:\Users\jamie\AppData\Local\Google\ct4j-cloud-sdk\LATEST\google-cloud-sdk.staging\platform\kuberun_licenses\LICENSES.txt]
However when I just run gcloud components update I get the result of All components are up to date.
Anyone know why this may be happening or how to fix it?
EDIT: As a work-around I found you can force the maven plugin to use a specific version of the sdk by using <cloudSdkVersion>321.0.0</cloudSdkVersion>. I'm still very curious to know why this occurred though
Manged to fix this by deleted the whole C:\Users\jamie\AppData\Local\Google\ct4j-cloud-sdk folder as this forces the plugin to redownload a fresh SDK.
The error occurs as the plugin uses its onw auto managed SDK rather than the one which is user managed.

Why is Android Studio failing to build, with an AAPT2 error on images?

After a recent update, Android Studio fails to build an unmodified project with errors along these lines:
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> AAPT2 aapt2-4.1.1-6503028-linux Daemon #0: Unexpected error during compile '/path/to/app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png', attempting to stop daemon.
This should not happen under normal circumstances, please file an issue if it does.
Notice that it's failing on an image supplied by Android Studio itself!
What can I do to fix it?
This seems to be an error in the newest (newer?) Gradle plugin(s) when it comes to PNG images; Google's IssueTracker lists several newly reported bugs along these lines. One of them mentions that it's a Gradle issue; I made mine work by reverting to a previous version: Gradle Plugin 4.0.1 and Gradle version 6.1.1 work fine.
It will be necessary to ignore AS' nagging about a newer version until this gets fixed.
[Added at the request of #YinOrYan]
To revert to an older version of Gradle:
In the menu, select "Files", then "Project Structure..."
In the dialog that pops up, select "Project" (first item in my version).
You can select the desired versions of the Gradle plugin and of Gradle from the drop-down menus.
This should not lose any system calls, as this is different from the SDK or API versions. However, it's not independent of them, so there is probably a limit to where you can set them.
As usual you will want to be online when you first build, or whenever you have to import a dependency, but otherwise it should be possible to work offline.
Sadly, it looks like an issue with older architectures. While the team at Google is looking into fixing it, in the meanwhile you can still use the new Android Studio and AGP, but temporarily revert to using an older version of AAPT2:
Try locating the old aapt2 executable in your gradle cache, e.g.:
~/.gradle/caches/<subdirectories, hashes
etc>/aapt2-4.1.0-alpha03-6246747-/aapt2(.exe)
Once you have the path you can add to your gradle.properties file:
android.aapt2FromMavenOverride=path/to/old/aapt2
To make this a little bit more robust you can actually copy that executable to a non-cache location, in case you clean your caches and it dissapears.
Hope this helps! Keep an eye on the Issue Tracker bug for updates.
I also had the same problem with AAPT2 errors and I have got over it.
First, downgrades Gradle to version 4.0.1, or
Second, I have done is upgrading the AMD Athlon processor to AMD FX-4300 without downgrading the gradle plugin version.
Wow, that's a real show-stopper! Can you explain how you reverted to an older gradle in Android Studio. Is it possible to work offline after doing this. And, did you lose any of the new system calls as a result? All this going on after finally getting my code working with the new AR Core stuff...

Gradle compatibility between Android Studio 4.0.1 and IntelliJ 2020.2 IDE

Just an observation that AS4.0.1 no longer clobbers IntelliJ (2020.2) initiated project settings any more, and merely complains of 'unsupported Modules' being detected(Note *).
Is this the beginning of Détente with peaceful co-existence (I wouldn't want to be unhappily surprised in future)?
Just to give specific context, here is what I refer to: (both reject the last configuration - a failed hack) and utilise their preferred first or second one respectively: This is a GOOD thing)
From IDEA 2020.2:
Unsupported Modules Detected: Compilation is not supported for following modules: CalibSense.app.
Unfortunately you can't have non-Gradle Java modules and Android-Gradle modules in one project.
The IDE modules below were removed by the Gradle project reload:
app
You can open DIALOG to select the ones you need to restore.
DIALOG LIST:
Android App:
[x]app
[v]Badroid.CalibSense.app (level: WORKSPACE)
[x]CalibSense.app (level: WORKSPACE)
From AndroidStudio 4.0.1(somewhere between IDEA 2019.2 and 2019.3):
Unsupported Modules Detected: Compilation is not supported for following modules: CalibSense.app.
Unfortunately you can't have non-Gradle Java modules and Android-Gradle modules in one project.
DIALOG LIST:
Android App:
[v]app
[x]Badroid.CalibSense.app (level: WORKSPACE)
[x]CalibSense.app (level: WORKSPACE)
Suggested Update AS 4.1 (including - All improvements from IntelliJ IDEA 2020.1.4)
Note *: It turns out they both complain of an illegal configuration, not of each others working configuration.
Nope.
The problem is in a different version of the IntelliJ Platform. Android Studio and IntelliJ Idea is developing separately because it's different products of different companies.
Google adopts the IntelliJ Platform in Android Studio - so we can think about it as about hacked IDEA.
So usually backward compatibility exists - it means that I can open in a new version of IntelliJ IDEA my older projects, but not vice versa.
So if look at AS 4.0 release notes we can mention that it is based on IntelliJ IDEA 2019.3.3 (https://developer.android.com/studio/releases#4.0-idea-2019-3-3). But your try to open a project of newer version IntelliJ Platform (2020.2). So it fails because your try to open a newer project version (2020.2) by old IDEA (2019.3.3)
But you can without issues open a project of AS 4.0 with IDEA 2020.2 - it will simply convert older project layout to new.

OSGI plugin development with Domino Designer 10

Up to date I was using IBM Domino Designer V9.0.1 FP8 to develop an OSGI plugin. With this version everything was working as intended. I've created a plugin project, a feature project and an update site project. Selecting "Build all" in the update site project created all the the corresponding jar files.
Today I've installed IBM (HCL) Domino Desinger V10 FP2 (fresh install i.e. I've deinstalled V9.0.1 and deleted the old "workspace" directory in NotesData, but I kept the NotesData itself).
Now if I open my plugin projects, I can edit the plugin, save the Java classes without any errors. Up to this point everything is working as usual. But now, if I use "Build all" in the update site project I see a screen with "generating ant script" and then the build process is finished, but no jar files are generated.
Any ideas why this is happening? Am I missing some files? Am I missing some configurations?
BTW: if I use standard eclipse to build the plugin all jar files are generated.
Domino Designer is a customised version of Eclipse. 9.0.1 FP9 and lower is a very old version of Eclipse, 9.0.1 FP10+ is a much newer version, so not comparable to what was happening before. It's possible there are differences in the customisation of Eclipse that are affecting it. But every Domino OSGi plugin developer I'm aware of uses standard Eclipse.
Follow the steps for setting up your environment here https://github.com/OpenNTF/XPagesExtensionLibrary/wiki/Development-Environment. In the documentation there I've tried to document why steps are done and what they achieve, as well as just the steps themselves. The intention is to pass on understanding to a broader set of developers, for future proofing.

IntelliJ forcing me to restart my app on every code change

I am on Grails 1.3.5 and IntelliJ 9.0.4 on a Mac with the latest JDK
I have the simplest of Grails projects: a helloworld that simply renders a string directly from a controller. I created it through the New Project wizard in IntelliJ. That went fine and IntelliJ picks up the correct grails SDK.
The problem is that IntelliJ makes me restart the app to see any changes I make to my code, (e.g. changing the "hello world" string.
If I edit the same controller with a text editor (eg TextMate) and run the app from the command line with grails run-app I do get hot code replacement, which is obviously what I want...
Anyone got a clue?
Some points:
I strongly recommend using the latest IntelliJ X EAP (http://confluence.jetbrains.net/display/IDEADEV/IDEA+X+EAP) since Grails support has been improved a lot since 9.0.x
If your IntelliJ config files got messed up, you can easily recreate them with 'grails integrate-with --intellij'. N.B. this recreates the config files in and old format and IntelliJ suggest to upgrade them - follow this procedure
Make sure your run configuration has uses at least the same memory settings than Grails uses when run from the command line, I'm fine with setting the 'VM parameters' field to '-XX:MaxPermSize=256m -Xmx1G'
If build problems occur (in rare cases the IntelliJ's internal compiler is more strict than plain Groovy), disable the 'Make' checkbox in the run config dialog.
If the problem persists, paste a screenshot of the run configuration you're using.

Resources