Using Eclipse Che 7.0.0-RC-1.0 on OpenShift.io.
Created a java workspace from det default stack (java, tomcat), but gets the message :
This workspace is using old definition format which is not compatible anymore. Please follow the documentation to update the definition of the workspace and benefits from the latest capabilities.
The problem is that the link to the documentation does not address this.
How can I solve that ?
== UPDATE (21.06.2019)
che.openshift.io has been updated to 7.0.0-RC-1.1 version and now it is possible to start existing Che 6 workspaces again
== Original Answer
This is a UX issue we are having on che.openshift.io after update to the 7.0.0-beta-5.0 upstream version. Basically, it is still possible to create and run a brand-new Che 6 workspace, but not possible to start an existing one from the User Dashboard. In reality, one can still run an existing Che 6 workspace by navigating to the workspace links directly from the browser (even though, Run / Open buttons are disabled navigation to the direct workspace link will start an existing workspace):
We are going to address this UX issue in the 7.0.0-RC-1.1 release #13553.
"Migrating an old Che 6 workspace to Che 7" docs will be provided by the GA release as part of the - #12974.
The dedicated section in the che.openshift.io FAQ - https://github.com/redhat-developer/rh-che/blob/master/FAQ.adoc#can-not-start-an-existing-che-6-workspace-this-workspace-is-using-old-definition-format-which-is-not-compatible-anymore
Related
I downloaded the newest version of Eclipse on an M1 Macbook Pro.
I downloaded the plugin from the Eclipse Marketplace. It's version 6.0
I made a new project, and when I get to the "finish" screen, I get this error:
Then, if I click finish again I get this error, which is the error that keeps showing up no matter how many times I click finish:
Some stuff ends up actually getting built in the project:
My professor doesn't know how to fix it, and there's nothing on Google. How can I make this work normally like it's supposed to? Thanks :)
The plugin is no longer supported for newer versions of Eclipse as we migrated to maven a while back.
You have two options
Use an old Intel version of Eclipse that predated the change to work with a legacy project.
Migrate the project to a Maven project which will work with all IDEs and doesn't use the plugin at all.
I was ordered to deliver an app in 2 versions : one demo/light (limitted features) the other full (all features). I have a boolean in code which tells which one is running. They both run as expected in the simulator or on a test device (iOS and Android).
Now I want to distribute them. So I read that it was possible with XCode to define different targets corresponding to the light / full versions and with Eclipse it was possible to define the base project as a library and then create 2 projects also corresponding to the light / full versions.
Before I start messing around with my app project, is there a recommended way to achieve my goal with CodenameOne maybe via build hints that would change the app name and the boolean inside the code depending on a build hint value ?
EDIT 19/09/2016 (working methodology)
Following Shai's advices here are the steps I followed to generate a light version based on the full one (in case someone encounters the same case) :
Under your IDE (Eclipse or whathever) copy and paste the base package in the src folder and rename it com.packageLIGHT.appName (simply append LIGHT to the package name, don't use underscore or space since it will be considered as an illegal character later by Apple)
=> So now in src folder you should have
src
|- com.packageLIGHT.appName
|- com.package.appName
Then in com.packageLIGHT.appName remove all files except MyApp.java (aka the main file). In this file add import com.package.myApp.*;
3.1. (ECLIPSE) In "Run/Run Configurations" menu copy the existing config and paste it as Simulator_MyAppLIGHT and in arguments change it to "com.packageLIGHT.myApp.MyApp".
3.2. (NETBEANS) The "Run/Set Project Configuration" does not seem to work as expected since any configuration that might be selected leads to the same default behaviour. However applying step 6. and running the project in the simulator afterward has the expected result.
Now you should be able to run both versions by running the different configurations.
For iOS (not sure if it is also needed for Android) you have to generate another pair of provisioning files. So move the existing ones in iosCerts/FULL and use CN1 wizard to generate the "light" version provisioning files where you'll adapt the package name to match "com.packageLIGHT.myApp". Store the generated files in iosCerts/LIGHT. There is no need to overwrite the existing certificates (more on certificate here).
Finally replace in "codenameone_settings.properties" the original package name with the "light" one for the lines codename1.ios.appid and codename1.packageName. Also change the iOS provisioning files to iosCerts/LIGHT or FULL depending of what you want to build.
Now when you send the Android / iOS build to CN1 server it will build either the "light" version or the full one depending on what package is written in "codenameone_settings.properties".
Please note : if at step 6. you get NullPointerException on build.xml on line 469 (android build) or 344 (iOS build) which deals with certPassword="${codename1.android.keystorePassword} (android build) or appid="${codename1.ios.appid}" (iOS build) and you're using CN1 plugin version 1.0.0 20160812 under Eclipse then Shai's comment below may be worth it
If you want 2 distinct versions of the same app then you need 2 distinct packages since the thing that defines the app uniquely in the store is the app package. There are two common ways to do it:
Place functionality in cn1lib and build two apps
Build one app and just swap the codenameone_settings.properties file
The first one should be pretty clear but might be a bit painful to work with as you can't run the cn1lib and might run into issues debugging it.
The second one is actually rather simple. Create the main version of the app then add the package to the demo version and copy the main file there.
To run the demo version just change the package in the IDE "run settings".
Copy your codenameone_settings.properties to a separate file and just replace all the regular package names to the demo package names. When you want to build the "demo" version replace the codenameone_settings.propeties files with one another, you can automate that with a script obviously.
I'm a totally blind developer who is looking at Eclipse Che. While I'm able to create a project the web interface is mostly inaccessible, I can not run an app, view console output, etc. Is there a way to access an Eclipse Che server through a standard desktop install of Eclipse?
You can actually use the Eclipse Che workspaces with a desktop editor/IDE. There are instructions on setting that up in the docs: https://eclipse-che.readme.io/docs/desktop-ide-mounting
Personally I like the mount-and-sync option for times when I don't use the Che browser IDE.
New install of Eclipse Mars.1, install codename one from market place, new install of Java 1.8 running on OSX 10.9.4.
Eclipse and the project itself are set to use Java 1.8 for all compilations, I also changed the settings in the build.xml to set 1.8 as the version to use.
When I try to add a gui builder page by right clicking on the project title and selecting "New/Other" and selecting Gui Builder, then next & finish I get the error.... '<>' operator is not allowed for source level below 1.7.
Searched Google for the error and nothing related to Codename one.
Any help would be greatly appreciated.
Open build.xml and do find and replace to replace all 1.7 with 1.8.
Open project properties (You will find it under File), and switch to Sources tab, make sure that Source/Binary Format is set to JDK 8.
Switch to CodenameOne tab and select Build Hints, now add java.version key and give it a value of 8, if it's not already added.
The latest plugin v 1.0.0.201606211322 resolves this issue
Since I installed XCode 4.6, it keeps on downloading the Doc Set each and every time I open it. I've seen a lot of threads talking about this topic, so I tried to manually install the doc set in the Developper/Shared/Documenation/Docsets folder. But even with that, I opened XCode this morning and.... it started downloading the thing again. What can I do to make it stop ?
Click the link under Xcode->Preferences Click on Xcode 4.6 doc set you will see an installed location. click on that link and delete the file. In my case there was another Xcode 4.6 file I think it was called Xcode 4.6 Documentation set I deleted that as well.
I closed XCode and opened up again the told it to download it again and it took.
You should only have one Xcode 4.6 file in your list I had two and I don't know why. Might be something left over from the 4.6 beta.
Hope it help
Go to the "Xcode->Preferences->Downoloads" and unselect the check mark under "Check for and install updates automatically" in the "Documlentation" tab.
Downloading Fresh Doc
As the other answers suggest, Xcode is merely detecting, downloading, and installing new versions of the documentation available on the Apple servers.
Disable Auto-Download
As pablok said, if you don't like this behavior, disable the behavior by unchecking Xcode > Preferences > Downloads > Documentation > Check for and install updates automatically.
Fresh Doc Stored Outside App
One interesting twist is that the old versions are stored inside Xcode.app while the fresh downloaded versions are stored outside the app.
For example, in Xcode 4.6.3 on Mountain Lion obtained from the developer.apple.com iOS Dev Center, the Xcode 4.6 doc set is bundled with the Xcode app. That bundled doc set, according to the Finder, is:
Version: 509.12
Size: 268.4 MB
Location: …/Xcode.app/Contents/Developer/Documentation/DocSets
The newly downloaded doc set is:
Version: 511.5
Size: 286.8 MB
Location: ~/Library/Developer/Shared/Documentation/DocSets
So, two mysteries:
Why does Apple bundle doc inside the app but download new doc somewhere else?
After doing so, why does Apple leave the old doc in place? Why not delete it?
As an experiment, someday I will delete the original ones inside the app. I'm not suggesting any benefit (other than recovering storage space) nor am I saying there is no adverse effect.