I have an Eclipse RCP application that could be updated via a p2 repository.
In the p2.inf file is defined that the eclipsec.exe is copied to a file with another name and after that it is deleted.
units.0.instructions.configure=\
org.eclipse.equinox.p2.touchpoint.natives.remove(path:${installFolder}/readme);\
org.eclipse.equinox.p2.touchpoint.natives.copy(source:${installFolder}/eclipsec.exe,target:${installFolder}/XXX.exe,overwrite:true);\
org.eclipse.equinox.p2.touchpoint.natives.remove(path:${installFolder}/eclipsec.exe);\
org.eclipse.equinox.p2.touchpoint.natives.remove(path:${installFolder}/notice.html);\
org.eclipse.equinox.p2.touchpoint.natives.remove(path:${installFolder}/epl-v10.html);\
org.eclipse.equinox.p2.touchpoint.natives.remove(path:${installFolder}/.eclipseproduct);
When the built application is unzipped/installed, it is visible that eclipsec.exe is correctly renamed to what was expected. After an update via p2 repository it is restored in the installation directory.
Any ideas how to stop it from reappearing after an update?
If it matters, the application is built with Maven Tycho.
Related
Eclipse IDE for Java Developers (includes Incubating components)
Version: 2021-12 (4.22.0)
Windows 10
The structure of my project is as follows: there is a shared folder and there are several maven projects (microservices) in it. I deleted one of the project from workspace.
Now I want to add it back (File->Open Project...),
but I get an error in response:
Select at least one folder to import as project.
As I understand it, the problem is that such a folder is already registered somewhere in the Eclipse settings, because if I change its name, it is added without errors.
Where is this information with the project name stored in Eclipse?
How can I delete it so that I can add a project without changing its name?
I tried to delete all configuration files from the project.
Created a new workspace and switched to it.
Nothing helps
I want to know how and when are the .metadata and .plugins folders created in eclipse.
More specifically when and how does .plugins folder gets created in our workspace.
.metadata/.plugins will be created when any of the installed plugins asks for the plugin's 'state location' using the InternalPlatform.getStateLocation API.
This usually happens as soon as the workspace is created because plugins such as org.eclipse.core.resources and org.eclipse.core.runtime want to store information in the state location immediately.
I am new to Eclipse and was wondering what is the dropins folder? Where exactly is it(I am on Windows 8)?
Basically i wanted to use this dark UI theme Roger Dudler made (https://github.com/eclipse-color-theme/eclipse-ui-themes) for Eclipse Juno. If you see near the bottom of this link, he says to place the zip folder into the "dropins folder". I have no idea :(
Thanks
dropins directory in eclipse (Path is Eclipse_home/dropins, which is at same level as plugins folder is present in eclipse) is a default watched directory.
Instead of installing plugins you simply put them under this folder (in your case com.github.eclipsecolortheme.themes_1.0.0.201207121019.jar) and restart the eclipse they will be picked up automatically on next start.
Please note that the dropins folder is not supported or encouraged in JBoss Developer Studio.
Plugin providers should really create an update site (or update site zip) containing their plugin bundles, and then users can simply do Help > Install new ... to install correctly using the fully supported p2/Install Manager method of installation.
Note too that Tycho now supports creation of update sites from nothing more than a pom.xml and category.xml file, and you don't need to create features anymore toadd your to the category.xml.
So there's really no reason to provide a plugin w/o wrapping it with the correct p2 metadata.
The dropins folder is if not exists it must be created. The location is the same as the executable of the IDE.
I am experiencing a problem with Eclipse's building its projects.
The procedure for setting a dev env is:
Creating a clearcase view.
Opening eclipse.
Importing preferences.
Connecting to clearcase plugin.
Importing a team-set.
Running ant - build.xml
During the build.xml, some files are generated and moved from its working directory into the some projects' lib directories.
After that, there are some eclipse.referesh task and eclipse.incrementalBuild that the build.xml invokes.
Now, the projects the jars (generated during build.xml) were copied into, do get compiled successfully, but other projects depending on them do not.
Even if I try refreshing the entire workspace and clean-building all of its projects manually, this doesn't work.
The problem is resolved only when I close the projects and open them (an eclipse feature).
It is possible that this is happening due to the ClearCase plugin?
Anyway on how to resolve this problem (It causes the build.xml to fail, because of compiler problems)?
With the official IBM ClearCase Eclipse plugin (presented in "What Clearcase eclipse-plugin to use in order to work on both clearcase 6 and 7 projects?"), I don't have that kind of issue if:
the .project and .classpath are within the ClearCase view, alongside the versioned sources
(see "Clearcase plugin for eclipse usage")
In other words, all files (eclipse files, ant files, ...) should be parth of the project directory, outside of the eclipse workspace itself (said eclipse workspace contains only a reference to the project, none of the actual files part of a ClearCase views, and located elsewhere, where the CC view actually is)
If you respect that organization, then the ClearCase plugin should have 0 effect on what your project are doing.
I have a maven web project that imported into eclipse. I have another maven project (generates a jar file) that the web project depends on.
Both of these projects work correctly when executed from the command line. mvn package creates a war file which pulls the jar it depends on from the maven repository for the web project. mvn package creates a valid jar file when run for the library.
When I import the library into Eclipse, m2e recognizes that the web project depends on the library and updates parts of the project to take advantage of the fact that both maven projects are hosted within a single Eclipse workspace. The "Maven Dependencies" section of the "Libraries" tab of the "Java Build Path" preference for the web project removes the library jar file and replaces it with the library project. As the library is updated in Eclipse, the web project recognizes those changes without having to install/deploy the library.
The problem occurs when I attempt to run the web application in Eclipse. Because Eclipse is actually building the Web project against the version of the library in Eclipse, it does not deploy the library file from the maven repository, it creates a new jar file that's a snapshot of the current version of the library in Eclipse. All of this has generally worked well for me, but on the project I'm currently working on there's a problem with the jar file that Eclipse is creating. Instead of inserting the class files for the library, it appears that it's taking the "src" directory of my Maven project and zipping it up as the jar file. The contents of the jar file look something like:
-main
-java
-com
-... *.java
-resources
-...
-test
-java
-com
-... *.java
Where I would expect it to look more like:
-com
-... *.class
Since I have successfully used this type of project before, I'm trying to figure out if there's something I need to configure or if I've just run into a bug.
I'm using the latest update of m2e (1.0.200.20111228-1245) on Eclipse Indigo (Build id: 20120216-1857).
In Eclipse, we can disable the "Workspace Resolution" so that it will use our dependencies directly from the local maven repository as the following steps: -
Disable Workspace Resolution
Right click at the project inside the eclipse
Select "Maven" from the context menu.
If it display "Disable Workspace Resolution" which means it is enable. We click it with purpose to disable it. Please note, after that it will display "Enable Workspace Resolution" which means we have disabled already.
We may need to update the project configuration and other related dependencies as the following steps: -
Update Project Configuration
Right click at the project inside the eclipse
Select "Maven" from the context menu.
Click the "Update Project Configuration..."
The "Update Maven Dependencies" windows will be displayed.
Select the required projects and click "OK".
Update Dependencies
Right click at the project inside the eclipse
Select "Maven" from the context menu.
Click the "*Update Dependencies"
The "Update Maven Dependencies" windows will be displayed.
Select the required projects and click "OK".
Please take a note, since we not use the related dependencies directly from the workspace anymore, It will use directly from our local maven repository. Then all related artifacts should be installed to our local maven repository by using the following command line.
mvn install
Anyhow it can be done by using the context menu inside the Eclipse as the following steps:-
Right click at the project inside the eclipse
Select "Run As" ---> "Maven Install".
Here's the solution that I came up with.
It appears that in my case the rules for the "Deployment Assembly" for the library project are still followed.
To change it go to the library properties->Deployment Assembly
In my case that just contained a mapping from '/src' -> '/'. I removed that entry and replaced it with a mapping from '/target/classes' -> '/' and '/src/main/resources' -> '/'.
Once I had that mapping in place, when the jar file was deployed it contained exactly what I had configured in the Deployment Assembly. That allows Eclipse to continue to be used without explicitly republishing the library for every change. But, it doesn't seem to auto redeploy to tomcat for me when the library is updated -- I still need to manually restart tomcat for library changes to be reflected.
It's still not entirely clear to me what's going on with this project. I do have previous projects that have a similar structure, and in those projects the Deployment Assembly has not been updated to explicitly include the class files and yet the proper jar file is still deployed.