With the p2 ant tasks, it's pretty simple to mirror the plugins for a feature.
But how do I mirror everything necessary to install a feature?
Couldn't get p2.mirror working; the task either mirrors too much (like all versions of a feature even if you're only interested in the last or a specific one) and/or too little (like just the feature but none of the dependencies).
My solution was like this:
Unpack Eclipse to eclipse-template
Create a copy as eclipse-install
Install the feature in eclipse-install
Delete any file in the copy which exists in the version from step #1 (cd eclipse-template ; find . -type f -exec rm "../eclipse-install/{}").
That leaves you with the feature and plugin files. Use org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher to turn that into a p2 repo (see the docs for details).
[UPDATE 2011-11-01] There is another solution if you don't need to run this from the command line.
Create a "Target Definition" in an Eclipse project (create a new one or use an existing one, doesn't matter)
Add update sites to this *.target file
Select the features you want
Click on the tiny "Export" button in the top right corner of the Target Definition Editor (next to "Set as Target Platform")
That will export all the selected features with the exact version that you selected plus all dependencies in a folder of your choice.
The target editor is a bit clumsy and slow but it works.
Keep the file under version control because the target editor sometimes messes up.
I am using the following Ant code to mirror 2 features in a single repository:
<!-- Creates single p2 repo from 2 repos -->
<p2.mirror>
<repository location="file:///${DESTINATION}/repo-name" append="false"/>
<source>
<repository location="file:///${feature1-repo}/feature1"/>
<repository location="file:///${feature2-repo}/feature2"/>
</source>
</p2.mirror>
Moreover you can use the <iu> and the feature's id to specify the feature to be mirrored. Features id must be specified in the following way:
your.feature.id.group.group.group
If you have specific plateform configurations for your feature, then the IU becomes
your.feature.id.win32.win32.x86 (OS, Widget system, Architecture)
Related
I have an autotools project that references an external directory containing build output of a different project (headers, libs, etc...). configuring and building via command line works fine. After importing via eclipse as an existing autotools project, none of the headers/references in that second project are found by eclipse.
Eclipse also fails to find a few libraries/headers that are in non-standard system locations like /opt, etc... Thus, autocomplete, ctrl+click, etc... doesn't work on a lot of things.
Both the second project and the non-standard libraries are correctly referenced when building/compiling and are found properly by configure
I'm able to manually add the necessary paths in the C/C++ build settings to get all of the includes resolved, but I was under the impression that importing an autotools project should automatically find these references. Am I incorrect in that assumption?
An additional note, our configure script requires the use of --prefix to know where to find the second project. when importing the project the first time, it of course tries to autoconf everything without --prefix set and subsequently fails. I then go back in and modify eclipse to use the appropriate prefix OR manually re-run autogen and configure with --prefix=/some/path. Then re-index the project. so everything should be setup fine at this point.
The actual question seems to be this:
I'm able to manually add the necessary paths in the C/C++ build
settings to get all of the includes resolved, but I was under the
impression that importing an autotools project should automatically
find these references. Am I incorrect in that assumption?
Your own experience tells you otherwise, notwithstanding your prior expectation.
In an Eclipse Autotools project, an Autotools build system is used to (configure and) build the project instead of any of Eclipse's built-in builders. To the extent that there is a data flow between components, it is from Eclipse to the project, not the other way around. The distributed Autotools artifacts (Makefile.am, configure.ac, etc.) are opaque to Eclipse, except inasmuch as it has content highlighting for those file types (IIRC). Artifacts built by configuring the project are not only opaque, but also ignored by policy.
We have some Maven modules shared between several teams, with the mandate to share the source code even though our projects use different dependencies and resources. To accomplish this, we have our modules set up as recommended in Using Maven When You Can't Use the Conventions under "Producing Multiple Unique JARs from a Single Source Directory." Specifically, we have a shared parent module containing the src directory but whose pom declares <packaging>pom</packaging> and only builds the two submodules. Each submodule inherits from this parent and refers to the shared src directory using this:
<build>
<sourceDirectory>../src/main/java</sourceDirectory>
</build>
The two submodules have different artifact ids, allowing dependent modules and projects to specify which version and dependency set they need. It also upholds the Maven principle of "one module, one output."
This all works great in Maven-land: compilation, installation, deployments, etc. What doesn't work well is Eclipse integration. Some things work fine: building the modules, deploying to our Maven repo, pulling in dependencies to build our project. But things such as code completion and jumping to class/method definitions do not work at all. It's as though Eclipse doesn't recognize the source at all.
If we just check out a module from SVN, Eclipse doesn't know about the classes but instead uses jars from the repo. If we then import the modules as Maven modules, they show up in package explorer and the project build path. However, all references to those classes and methods are now flagged as errors by Eclipse. And we still do not have code completion or navigation.
So my questions are these: How can we get Eclipse to recognize the code and do its normal code navigation while still satisfying our varying project requirements? Am I missing some simple Eclipse configuration? Do we need to rework our Maven module structure, and if so, how?
Some additional context: The different dependencies for the projects are rather large, including different major versions for things such as Weblogic and Spring. The Weblogic versions will converge some time next year, but the other dependencies will be slower (and some resource files will likely always remain distinct). So for the near- to mid-future, we have to account for different dependencies between the projects.
We are using profiles to allow our Jenkins server to build both submodules while allowing individual developers to build only the submodule their project needs. Using profiles to manage the dependencies is problematic because we lose transitivity of dependencies.
Update (12/8/15)
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, but Link Source let me assign an arbitrary directory to use. It's not ideal, but it seems to be working.
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, which derailed me for a while. However,Link Source let me assign an arbitrary directory to use.
It's not ideal, but it seems to be working. We can now jump to definitions with F3, and errors are now highlighted correctly. It's good enough that I don't feel bad recommending it to the other team. I wish Eclipse would automatically allow a parent source directory to be referenced, but at least the manual intervention worked right.
I am new to eclipse. Where can I find the org.eclipse.jdt.core version (e.g., [3.10.0,4.0.0) bundled with each official eclipse release. it would be tedious to find out by installing each eclipse version
I don't know of a versions list. You can download just the 'JDT Runtime Binary' for the various releases from the Eclipse Projects Archives. This is about 27Mb per release. This is just a zip file, you don't need to install it, just examine the contents.
I would recommend a tool like p2-browser. It will allow you to examine the contents of Eclipse P2 Update sites by just downloading the meta data.
Using p2browser
Once you have started p2browser (see below), you should have a screen like this:
Add 1 or more p2 sites to consider and allow the tool to download the metadata.
Press Add
Put the p2 site (e.g. for Mars: http://download.eclipse.org/releases/mars)
Press OK and wait for download
Repeat until you have all the versions you are interested in.
You should now have your added p2 sites listed in the tree viewer:
Now you can add your plug-in or feature you are interested in, e.g. in your case org.eclipse.jdt.core in the filter box:
Another example of what you can filter on, e.g. org.eclipse.jdt.feature.group for the JDT Feature
Download/Install/Build
Java Web Start
To use the p2 browser you may like to simply use Java Web Start, Run:
javaws http://ifedorenko.github.com/p2-browser/javaws/com.ifedorenko.p2browser.jnlp
Or click this link, as docs show, results for using java web start may vary because of tightening security considerations of running arbitrary java downloaded from the web.
Build and Run with Maven
You can build it with maven, as per the docs. These are simplified instructions:
git clone git#github.com:ifedorenko/p2-browser.git
cd p2-browser/
mvn clean package
cd com.ifedorenko.p2browser.rcp/target/products/com.ifedorenko.p2browser.rcp
Linux x64: linux/gtk/x86_64, other platforms, choose the correct directory.
./p2browser
We have a RCP application which includes domain specific configuration files(properties file, and few folders containing xml's) in its installation directory. We have provided update support through P2 framework which works for plug-ins and features, But now we are planning to provide update support for the configuration files as well.
Is it possible to update the configuration files with P2 framework?
Any link to do the same would be helpful.
What you need is the so-called "root files" (do not mix up with "root IU").
An example of those is org.eclipse.equinox.executable feature which includes the .exe/.so files which are installed to the root directory of your product.
There are several ways to achieve it, here the simplest one:
create a feature project named xyz.feature
place all files you want to have in the root of your product into the /xyz.feature/root.files/ directory
create the following entry in the /xyz.feature/build.properties:
root=root.files
Include this feature in your main feature / product configuration
Export the feature/product into a p2 repository
You can examine the resulting p2 repo to see what p2 does exactly with this magic "root=" property key on export.
A plug-in that I want to install provides an update site for installation. However, the Eclipse installation that I want to install it to is on a machine that is not connected to the Internet. Is there a way for me to access the site (HTTP, FTP, etc.) to download the files in it for offline installation?
Eclipse offers a way of mirroring these sites automatically, either through the command line or through ant tasks.
Mirror based on p2 information
$eclipse_home/eclipse -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication -source $1 -destination $2
$eclipse_home/eclipse -application org.eclipse.equinox.p2.metadata.repository.mirrorApplication -source $1 -destination $2
Reference: Equinox p2 repository mirroring
Mirror based on site.xml information
java -jar $eclipse_home/plugins/org.eclipse.equinox.launcher_*.jar -application org.eclipse.update.core.standaloneUpdate -command mirror -from $from -to $to
Reference: Running the update manager from the command line
You can follow the evolution of these scripts in my script repository.
After struggling with mirroring for some time, I realized that it is much easier (at least, for me) to use "wget" instead.
In short:
Download the site:
wget --recursive --no-parent http://url.of/updatesite
Take the content of the downloaded update site and move it to your offline environment
Add your offline update site directory to the list of available software sites via "Local..." button.
You can read about it with more details here.
Most Eclipse plug-ins can be installed without the Eclipse updater, by copying the required JARs available at the update site, into the plugins and features directories of the Eclipse installation.
In certain cases, it is necessary to start Eclipse with a -clean switch.
Here's an example of how to do this for the m2eclipse plugin:
The m2eclipse update site is http://m2eclipse.sonatype.org/update. Identifying the list of JARs required is the first step. This is normally found in the site.xml file; in this case, you'll find it in http://m2eclipse.sonatype.org/update/site.xml.
Filter the list of JARs to be downloaded to the version of the plugin that you intend to use. This can be determined by the version attribute for each "feature". If you are lucky, you'll find the description of the JAR in the category node.
Note the url attribute of each JAR that needs to be downloaded. This will include the subdirectory on the server where the JAR is available, and also the directory in the Eclipse installation where they need to be placed.
PS: This method is a bit hackish, but it is based off the site-map reference. But do refer to the update
Update
I haven't attempted this, but you can create a local mirror site, from where everyone else can pickup the Eclipse plug-ins. In Galileo, this can be done by running the Eclipse updater in the standalone mode via the mirror command.
You can mirror p2 sites using Ant tasks:
<target name="springide">
<echo>springide</echo>
<p2.mirror verbose="true">
<repository location="${REPO_HOME}/springide" name="springide" append="true"/>
<source>
<repository location="http://springide.org/updatesite" />
</source>
<iu id="Core / Spring IDE" version="" />
<iu id="Extensions / Spring IDE" version="" />
<iu id="Integrations / Spring IDE" version="" />
<iu id="Resources / Spring IDE" version="" />
</p2.mirror>
</target>
or findbugs:
<target name="findbugs">
<echo>findbugs</echo>
<p2.mirror verbose="true">
<repository location="${REPO_HOME}/findbugs" name="findbugs" append="true"/>
<source>
<repository location="http://findbugs.cs.umd.edu/eclipse/" />
</source>
<iu id="edu.umd.cs.findbugs.plugin.eclipse.feature.group" version="" />
</p2.mirror>
</target>
In order for this to work you have to run ant tasks in the same JVM as eclipse.
You can find IU ID:s by opening "Software Updates" and copy it from there. In Eclipse 3.5 there should be a More... button, in 3.4 you have to click on properties button.
Eclipse plugins usually depend on other plugins. It's kind of hard to trace the dependencies. It's better to download all dependencies using update site once, and you can distribute to other Eclipse dropins. For Eclipse 3.4 or newer, you can use dropins which is an Eclipse feature. This way you don’t have to install plugin from update site every time you have to re-install your Eclipse. Read on http://michsan.web.id/content/how-install-eclipse-plugins-offline
If you can't see the web, I'll give you some description
Prepare directory for external plugins
Create special directory to hold our beloved plugins, e.g. in /home/ichsan/eclipse-dropins we will install Maven plugin: m2eclipse.
mkdir /home/ichsan/eclipse-dropins
For now on, we'll call this directory as DROPINS
Preparing sandbox
Next, by using Git we'll create an Eclipse sandbox. The point is to install one plugin on a fresh Eclipse. Instead of installing fresh Eclipse every time we want to install a new plugin, we'd better use Git to create new branch of fresh Eclipse.
First, extract/install new Eclipse to a directory e.g. /home/ichsan/eclipse-sandbox (so that we'll find /home/ichsan/eclipse-sandbox/eclipse.ini). We call the directory as ECLIPSE_SANDBOX.
Next, commit the fresh installation. This step should be done once only.
cd $ECLIPSE_SANDBOX
git init
git add .
git commit -am "Fresh Eclipse"
Install plugin on sandbox
Now is the interesting part. Supposed we have to install m2eclipse plugin. We will install this on new Git branch so that the master branch will stay clean or stay intact.
cd $ECLIPSE_SANDBOX
git checkout -b "m2eclipse"
Now, we start the Eclipse of the ECLIPSE_SANDBOX and download the plugin. Once we're done, we shut the Eclipse down and check what new directories or files have been created (using Git). Remember that, we only care about new plugins and features directories and the contents inside them. So, we won't copy the rest into dropins.
# Prepare the m2eclipse plugin directories
mkdir -p $DROPINS/m2eclipse/eclipse/plugins
mkdir -p $DROPINS/m2eclipse/eclipse/features
cd $ECLIPSE_SANDBOX
for f in $(git status | sed "s/#\t//g" | grep -P "^plugins" ); do cp -R $f $DROPINS/m2eclipse/eclipse/plugins; done
for f in $(git status | sed "s/#\t//g" | grep -P "^features"); do cp -R $f $DROPINS/m2eclipse/eclipse/features; done
# Make the directory read only
chmod -R -w $DROPINS/m2eclipse
# Commit changes
git add .
git add -u
git commit -am "M2Eclipse plugin installed"
# Back to master branch to make Eclipse clean again and ready for other plugin installations
git checkout master
Installing the plugin
Just copy the directory of DROPINS/m2eclipse into ECLIPSE_HOME/dropins or create a symbolic link. And we're done!
cd $ECLIPSE_HOME/dropins ln -s $DROPINS/m2eclipse
Another way is to backup differences between fresh-Eclipse commit and after-plugin-installation commit.
for i in `git diff hashFreshEclipse hashPluginInstall --name-only`;do
if [ -f $i ]; then
tar -r -f m2e-android.tar $i
fi
done
gzip m2e-android.tar
You can get it from here https://repository.sonatype.org/content/repositories/forge-sites/m2e/1.3.0/N/1.3.0.20121023-1108/
Download all files drilling down into plugins and features. Store in a directory on your machine keeping everything in the same directory structure. Move it to a folder on your dev machine.
In Eclipse go to Help | Intall New Software...
Hit the 'Add' button
Hit the 'Local...' button
Browse for the directory you dropped the files into. Follow the on screen instructions.
I found that the p2 mirrorApplication did not work very well on some sites and mirrored duplicate artifacts (both the pack200 and jar version). The b3 Aggregator worked much better and made it much easier to customize my update site. See the manual at: https://wiki.eclipse.org/Eclipse_b3/aggregator/manual for install instructions and details.
The basic steps I used were:
File > New > Other... > b3 > Repository Aggregation.
Select the Aggregation node and set the Build Root to the folder where you want the aggregated repo to go.
Add the platforms you care about using R-click the Aggregation node > New Child > Configuration.
Add one Validation Set, normally set its Label to main.
If you don't need any additional bundles from the main eclipse repository (ie: http://download.eclipse.org/releases/mars), you can add it to the Validation Set as a Validation Repository, but typically you will need to add it as a Mapped Repository under a Contribution so dependencies and/or additional eclipse features can be downloaded.
For each plugin, add a Contribution with a Label, and under that at least one Mapped Repository with a Location.
Add Custom Category nodes to the Aggregation if you want; give them each a unique Description, Identifier, and Label.
Expand the Repository Browser node at the bottom > expand the repo url > expand the Installable Units > Look at the features under Categories (if present) and/or under Features.
R-click the features you want and Add to Custom Category (if you are using those), otherwise Add to parent mapped repository as > Mapped Feature.
R-click any node > Build Aggregation.
Important Note: if you don't map any features from a given repository, that entire repository will be mirrored (the latest versions of all bundles I think, not actually everything in the repo).
I fortunately didn't have to mess with Exclusion Rules or Valid Configuration Rules, which seem to make things more complicated. However, exclusion rules may be necessary if the repositories contain bundles that have dependency conflicts, in which case one or more conflicting bundles need to be excluded.
While b3 Aggregator normally only downloads the latest version of every feature you have mapped (and it's dependencies), if you repeatedly use Build Aggregation over time as new versions are released, the obsolete versions will accumulate in your aggregation. You could use Clean then Build Aggregation but this means you will have to redownload everything. Instead, simply add another .b3aggr aggregation file, set the Build Root, add your Configurations, and add one Contribution with a Mapped Repository using the path to your local mirror's final directory. Don't map any features or create any categories. Then Build Aggregation and only the latest versions from your mirror will be aggregated!
I just faced this issue and resolved it by following the instructions from this guide. In summary, run the following commands on your terminal in Eclipse folder:
eclipsec.exe -application org.eclipse.equinox.p2.metadata.repository.mirrorApplication -source $1 -destination $2
eclipsec.exe -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication -source $1 -destination $2
Where $1 refers to the URL to the online repository and $2 refers to the path to the local folder. E.g. to download Vrapper on my Windows Desktop:
$1 = http://vrapper.sourceforge.net/update-site/stable/
$2 = C:/Users/foo/Desktop
Transfer the folder to the machine without Internet connection. Then, launch Eclipse -> Help > Install new software. Specify the local repository (i.e. the folder that you've just transferred) for the installation. That should work.