I recreated the same project multiple times, previously deleting it from disk.
Now the 'Open existing app...' is populated with inexistent projects and Typesafe Activator is adding an incremental suffix to them project-name-1, project-name-2, project-name-n.
How do I remove or delete an application from 'Open existing app...' list?
It's not implemented yet. However, you can look under ~/.activator/<version>/config.json and directly remove the application there. If you want to remove all the applications either delete the file or set to {"applications":[]} We haven't documented the config.json format, because we haven't locked on a stable config file there yet, hence why it's under a versioned directory.
I believe there's already a ticket for the feature: https://github.com/typesafehub/activator/issues/17
The current version of activator has a delete button!
Related
When you start a new Eclipse IDE and create a new MWE2 workflow you can reference workflows from plugins in the target environment or workspace (within new RCP)
component = #foo.MyWorkflow {}
But this doesn't works for all workflows, some aren't resolvable:
Couldn't resolve reference to Module 'OtherWorkflow'.
Even when copying MyWorkflow, renaming to MyWorkflow2 and restarting the RCP: MyWorkflow2 isn't resolvable.
edit: must be some kind of problem of the xtext referencer, after some time without any changes, also other workflows can be resolved, but after deleting the workspace of the RCP they re-disappear
edit2: appears like a bug in 2.3.1, with latest nightly (pre 2.4) all workflows can be resolved
First: The # notation does not require a second eclipse instance. The editor and tooling also resolves in the same instance.
Second: The mwe2 builder is not very reliable. Have a look at the hidden bin folder within your project space. The builder should copy and update your mwe2 files in this location. It will only reference files that are present and up-to-date here. I found that I often had to touch the source files to force a rebuild, or to delete the target files to get rid of a stale state that was not recognized.
Otherwise mwe2 is a sparsely charted meta-black hole. You have your wits. Good luck.
Is it possible to deliver an update which contains only the updated libraries and not the whole package of data. in our application only a few files are updates regularly. The other ones never. With Auto update over the net this would result in a much smaller package...
Is such a setup possible and how?
Thank you.
You can do this by saving your project to a different file (keeing the application ID) and removing the unnecessary files from the distribution tree. When you compile that project, an updates.xml file is created as usual. Use that updates.xml file for auto-updates instead of the updates.xml file from the standalone installer project.
In our Eclipse plugin are we managing some resources using navigator. For every folder in the navigator Eclipse is creating an .project file which leads to some problem in the code under resource management.
One way is to filter .project file pragmatically. But I wonder if there is a configuration or setting in Eclipse to prevent creation of .project files for the maps under navigator?
.project files created by Eclipse IDE is essential cannot be prevented from generation.
For Further information please refer to documentation at Eclipse Documentation.
EDIT:
The workaround would be to create a project in your workspace and then create a linked folder to the resources you want to scan that are somewhere else on the file system.
Don't try to delete the project meta data. That will lead to more trouble afterwards than simply configuring the team API to ignore the .project files during all version control operations. That .project file contains meta information from all plugins, not only from yours.
Depending on the VCS used, you should just create a default .gitignore, svn:ignore, or whatever you need.
Besides that, I would simply call it a bug in your plugin that it tries to do something with that file. It simply should not do that. Other plugins will create other files in the projects and you should not try to handle each and every file, if they don't belong to your plugin. The JDT plugin also knows which files to compile and which to ignore.
I'm working with an open source library that's made available as a git repository (XML-RPC) and I'd like to use it in an iPad application. As I understand it, iOS applications should use static libraries for their linking.
Since this comes as a dynamic library, how can I convert it to something I can link with my app and use?
Maybe naive answer but why not just add all the relevent files in the repository to your app and just build it?
Put the files in a seperate folder obviously so you can update them to a newer version if you need to etc. Lots of projects I've done have an 'external' folder that just contains codethat I use from 3rd party sources. I've usually got the source so just compile it into my app and don't bother with making it a library.
Or are there tricky conditions that need to be met to compile this code?
I ended up doing this in several steps:
First, I opened the library project in Xcode and created a new target for the static library. I then made a directory in the project folder called "XMLRPC" and moved all the header files to it. I deleted the now-red invalid references to the header files, and re-added them (but kept the box for copying them to the current folder unchecked).
I added this Xcode project to my main project with a relative reference. I opened my main app's target and added the library project as a direct dependency, and checked the "Always search user paths" option on my main app's target settings.
Lastly, I modified the general Xcode preferences to use a shared build directory. I haven't tried it without that since it was something I wanted anyways; it might not be necessary.
My revision control has two folders in it: one's my project, and the other's the library. The library is still under git control within mercurial; I'm hoping this doesn't cause any issues.
I am using Eclipse Ganymede.
I have a project open and call a static method of a class in another project, which the current one references.
I close the current project, open the referenced library's project, change the method return type, and rebuild its jar. (It's set to build automatically, but I tried explicitly rebuilding all anyway.)
When I go back to the original project, it still thinks that the static method returns the old type. What am I doing wrong?
P.S., "refresh" on the context menu doesn't fix it either.
The problem may depend on how the first project references the class file in the second. If it has a hard-coded classpath to a jar produced by the second project, you'll need to make sure that jar file is properly updated where it is linked from.
Since you control both projects, ideally the first project would be dependent on the second project as a "project dependency", not as a jar dependency (then it would automatically sync changes between the two)
You can find a list of those projects (and add to them) by right-clicking on the project, selecting Build Path -> Configure Build Path, and switching to the Project tab.
I think the jar file was out of date. I ended up deleting the old one, selecting the project to be referenced, and clicking "Export". At that point, I was able to indicate that all classes and resources in the project should be exported to a jar in the folder I specified.