Community
Participate
Working Groups
I tried to port my GNU ARM Eclipse Plug-in project to 3.7 but either something changed in the way toolchain definitions are parsed, or a bug was introduced on the way. I replaced the references to org.osgi.framework.Version and now the project builds properly. However, when trying to run the plug-in and create a new project based on it, I see the toolchain enumerated, I can select it, but later I get the following error: At least one configuration should be available. Project cannot be created. As expected, there is no Debug/Release configurations presented. According to the SVN, there are no changes in the plugin.xml file. I'm using 3.7 with java 6, on Mac OS X 10.6.8. Any suggestions on how to proceed? Liviu
Related to Bug 356864 maybe?
Sounds like the same issue, please reopen if you have evidence proving otherwise. *** This bug has been marked as a duplicate of bug 356864 ***
I don't think that it is a duplicate of 356864. further more, I heard reports that other plug-ins related to mine do not work on 3.7. please suggest how to proceed, we are almost half year after releasing 3.7, and it is very difficult to explain to my users why they should run 3.6 to use the plug-in.
(In reply to comment #3) > I don't think that it is a duplicate of 356864. Can I ask why? The symptoms are the same, they both result in the message "At least one configuration should be available." > please suggest how to proceed, we are almost half year after releasing 3.7, and > it is very difficult to explain to my users why they should run 3.6 to use the > plug-in. I think we should work on fixing bug 356864. One thing I would try is to revert the change from bug 335338 and see if that fixes the problem for XLC and for your plug-in.
(In reply to comment #4) > Can I ask why? when I said that, I did a shallow check in the logs and could not find the stack trace mentioned in bug 356864. now I realised I'm running with the latest updates applied and I checked further in the logs and in some older attempts to run my plug-in I found the same messages: org.eclipse.core.runtime.CoreException: Cannot create managed project with NULL configuration at org.eclipse.cdt.managedbuilder.ui.wizards.MBSWizardHandler.setProjectDescription(MBSWizardHandler.java:561) at org.eclipse.cdt.managedbuilder.ui.wizards.MBSWizardHandler.createProject(MBSWizardHandler.java:537) > The symptoms are the same, they both result in the message "At > least one configuration should be available." you're probably right > I think we should work on fixing bug 356864. One thing I would try is to revert > the change from bug 335338 and see if that fixes the problem for XLC and for > your plug-in. ok, it's fine with me. should I checkout the full CDT from the repo in order to test? any advice will be highly appreciated. Liviu
I also checked org.eclipse.ui.workbench/log and found new info: !SESSION 2011-11-17 00:13:19.537 ----------------------------------------------- eclipse.buildId=M20110909-1335 java.version=1.6.0_26 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_GB Framework arguments: -product org.eclipse.epp.package.cpp.product -keyring /Users/ilg/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.cpp.product -keyring /Users/ilg/.eclipse_keyring -showlocation This is a continuation of log file /Users/ilg/My Files/MacBookPro Vault/Projects/Eclipse Workspaces/37 Mac/gnuarmeclipse-test/.metadata/.bak_0.log Created Time: 2011-11-17 00:13:38.556 !ENTRY org.eclipse.osgi 2 0 2011-11-17 00:13:38.556 !MESSAGE The activator org.eclipse.cdt.cross.arm.gnu.ARMPlugin for bundle org.eclipse.cdt.cross.arm.gnu is invalid !STACK 0 org.osgi.framework.BundleException: The activator org.eclipse.cdt.cross.arm.gnu.ARMPlugin for bundle org.eclipse.cdt.cross.arm.gnu is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:171) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:679) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:236) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1207) org.eclipse.cdt.cross.arm.gnu.ARMPlugin is obviously there, but I do not know why it is not recognised.
(In reply to comment #6) > org.eclipse.cdt.cross.arm.gnu.ARMPlugin is obviously there, but I do not know > why it is not recognised. I downloaded the latest source for your plug-in and it loads the plug-in correctly for me. Maybe double check the plug-ins with the Validate button in the Plug-ins tab in the Run or Debug configuration?
(In reply to comment #7) > (In reply to comment #6) > > org.eclipse.cdt.cross.arm.gnu.ARMPlugin is obviously there, but I do not know > > why it is not recognised. > > I downloaded the latest source for your plug-in and it loads the plug-in > correctly for me. Maybe double check the plug-ins with the Validate button in > the Plug-ins tab in the Run or Debug configuration? did that and only the linux/solaris/win32 plug-ins complain (I'm on Mac). my test environment is currently the latest Eclipse 3.7 RCP with all updates, and in the workspace I have the entire CDT repo, with some projects closed (see http://wiki.eclipse.org/Talk:CDT/git for details), plus my 3 plug-in projects. if I run everything via the embedded Eclipse Application configuration, I do not get any errors in the console, or exceptions in the log, the plug-in is loaded, and it seems I can create the new C++ ARM applications, but later I get the famous "At least one configuration should be available" error and the project is not created. Liviu
> I think we should work on fixing bug 356864. One thing I would try is to revert > the change from bug 335338 and see if that fixes the problem for XLC and for > your plug-in. any other suggestions? if not, I'll try to revert these changes and see if the problem is fixed for my plug-in. Liviu
(In reply to comment #9) > ... I'll try to revert these changes and see if the problem is fixed for my > plug-in. I confirm that reverting CDTConfigWizardPage.java from e7395 to previous 7220a fixes the problem I experienced with my plug-in. James & team, can we decide on how to proceed? Is this patch to be reverted? Should I work on my plug-in to meet the additional requirements of this patch? Liviu
(In reply to comment #10) > Should I work on my plug-in to meet the additional requirements of this patch? further investigations revealed that this additional requirement is to remove the "name" filed of the "projectType" element. according to the "Managed Build System Extensibility Document", 3.2 ProjectType, "You must also provide a meaningful name that will be displayed to the user in the UI and new project wizards" also the Schema in the 3.2.1 table lists the "name" attribute as Required. I don't know what "old style project types" are and I'm not able to follow the reasons behind this additional requirement, but in principle I think that removing the name of an element to mark it somehow different from other elements is not a very fortunate decision. unless very good reasons to not do so, my suggestion is to revert to previous 7220a version and increase the version of org.eclipse.cdt.managedbuilder.ui from 8.1.0 to 8.1.1 so I can check if my plug-in is running in the proper environment. Liviu
