tag:blogger.com,1999:blog-292070642024-03-07T14:42:20.129-08:00Paul's Eclipse BlogMusings from a committer in Platform UIpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-29207064.post-17840678010732636412014-09-12T13:40:00.001-07:002014-09-12T13:40:20.494-07:00Looking at High Availablility with Eclipse OrionI've had the opportunity to do some work on Eclipse Orion lately, and I'm really enjoying it. There are opportunities to learn about technology on both the server (Java and/or Nodejs) and the client side (HTML, CSS, and JS). It's a lot to learn :-)<br />
<br />
One of the things I've been looking at is High Availability in Orion 7.0. If we use horizontal scaling, we can upgrade one server while leaving another server to continue to provide service (we're working with some kind of proxy in front of the servers, like NGINX, to direct traffic).<br />
<br />
<a href="http://ahuntereclipse.blogspot.com/">Anthony</a> has been working on consolidating Orion metastore/metadata, on distributing upgrades on user access or background processes, and on a policy to cover how we add/upgrade new metadata properties so that older servers could still function against the new metadata.<br />
<br />
I've been focused on allowing multiple servers to access the same user content and search indices at the same time.<br />
<br />
By default, there's only one small change in Orion 7.0. The search indices which used to reside in <span style="font-family: "Courier New",Courier,monospace;">osgi.instance.area/.plugins/org.eclipse.orion.server.core.search </span>will now reside in <span style="font-family: "Courier New",Courier,monospace;">osgi.instance.area/.plugins/org.eclipse.orion.server.core.search/<version></span> (where the current version is <b>v16</b>).<br />
<br />
You can use properties (See <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.core/web-ide.conf">web-ide.conf</a>) to activate the new configuration, where the user content and the search indices are in a common location but each server still has its own local <span style="font-family: "Courier New",Courier,monospace;">osgi.instance.area</span>.<br />
<br />
For example, if I had 2 servers that had their local OSGi instance areas at <span style="font-family: "Courier New",Courier,monospace;">/opt/orion/workspace</span> (not shared between servers) and a common NFS mount at <span style="font-family: "Courier New",Courier,monospace;">/home/data</span>, I could set up the orion configuration on each server to serve up the same content using:<br />
<br />
<ul>
<li>orion.file.content.location=/home/data/orion/content</li>
<li>orion.search.index.location=/home/data/orion/search</li>
<li>orion.file.content.locking=true</li>
</ul>
The search indices and user content should not point to the same directory. The file content locking uses file system (per process) locks to protect read-writes of user metadata and instructs only one process to run the search indexing jobs at a time.<br />
<br />
We've done some preliminary testing, but we always welcome more testing and feedback. If you get a chance to use this, please let me know :-)<br />
<br />paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-5630695056234448762012-09-26T11:33:00.000-07:002012-09-26T11:33:00.342-07:00version qualifiers with CBI and gitWhen building an RCP app or feature, you don't want bundle qualifiers that change with every build, that removes the benefit of updating only what has changed. But you do want to be sure that a given version.qualifier is repeatable (built from the same source). One cool little feature that came out of the CBI work was a way to derive bundle qualifiers from git.<br />
<br />
The Eclipse Project has been built with PDE build and map files for a long time now. The map file entry told PDE build what version and what location to check out during a build. This checks out org.eclipse.jface from CVS in one of our older builds, and will produce the plugin org.eclipse.jface_3.6.2.M20110210-1200.jar:<br />
<blockquote>
plugin@org.eclipse.jface=M20110210-1200,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,</blockquote>
With our move to git, we've updated them to GIT entries so they can be checked out:<br />
<blockquote>
plugin@org.eclipse.jface=GIT,tag=v20120817-083647,repo=git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git,path=bundles/org.eclipse.jface</blockquote>
This will produce org.eclipse.jface_3.8.101.v20120817-083647.jar. But the map based git fetch factory only works because it copies the plugins from the git repo that contains them to the <i>buildDirectory/plugins</i> directory. The tag used both for the qualifier and to check out a version of the bundle for the build. But when there are multiple bundles are in a git repo and you can only checkout one tag at a time, the CVS pattern doesn't hold up for git.<br />
<br />
When moving to the CBI based build, we'd be building all of the bundles in a git repo at the same time. In this scenario, it doesn't make sense to tie the bundle qualifier to a repository tag of some kind. The important functionality is 1) the qualifier doesn't change if the source code doesn't change and 2) the qualifier is repeatable when derived from the same build input.<br />
<br />
That's where the notion of using the UTC commit timestamp of the last commit to touch a project came from. Tycho provides tycho-buildtimestamp-jgit, a timestamp provider that can be configured to work with tycho-packaging-plugin (in the 0.16.0 SNAPSHOT, I believe).<br />
<br />
Example:<br />
<br />
<pre><code> <plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-packaging-plugin</artifactId>
<version>${tycho.version}</version>
<dependencies>
<dependency>
<groupId>org.eclipse.tycho.extras</groupId>
<artifactId>tycho-buildtimestamp-jgit</artifactId>
<version>${tycho-extras.version}</version>
</dependency>
</dependencies>
<configuration>
<strictBinIncludes>false</strictBinIncludes>
<format>'v'yyyyMMdd-HHmm</format>
<timestampProvider>jgit</timestampProvider>
<jgit.ignore>
</jgit.ignore>
</configuration>
</plugin></code></pre>
<br />
Now building our repo will generate predictable and reproducible qualifiers. This will also help reduce the number of vDATE-TIME tags we push to our git repo, as only the build input commit needs to be tagged. In 4.2.2 we get org.eclipse.jface_3.8.101.v20120914-1338.jar.<br />
<br />
There are some drawback to this approach, but all in all it provides a qualifier convention that doesn't require a lot of configuration.<br />
<br />paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-66219894166875795222012-07-24T11:29:00.001-07:002012-07-24T11:29:43.602-07:00CBI and the eclipse project build<p>The CBI initiative is working at providing some infrastructure and templates to make it easy to get a new eclipse project up and running. So with a little setup, a new project can take advantage of some of the technologies (maven/tycho) and services (hudson.eclipse.org, eclipse jar signing) that the Eclipse Foundation offers.
</p><p>
One of CBI's trial projects is the Eclipse Project build (now called Eclipse Classic SDK :-) It's like the poster child for build edge conditions.
</p><p>
Right now the Eclipse project is built with a rather large set of PDE build scripts. But as we recently went through a lot of work trying to get them to build on eclipse.org, I can attest to the fact that they're not terribly portable.
</p><p>
With the need for various organizations to be able to build eclipse in their own environments, the CBI initiative is taking advantage of the fact that the second person to build something with maven gets a (mostly :-) free ride.
</p><p>
After cloning a large git repo made up mostly of submodules, all you have to do is install 2 poms and you're off to the races:
</p><p>
<pre>
bash$ git clone -b Juno_RC4_R4 --recursive \
ssh://git.eclipse.org/gitroot/cbi/platform-aggregator.git \
R4_platform-aggregator
bash$ cd R4_platform-aggregator
bash$ mvn -f eclipse-parent/pom.xml \
clean install \
-Dmaven.repo.local=/opt/pwebster/lts/R4_localrepo
bash$ mvn -f maven-cbi-plugin/pom.xml \
clean install \
-Dmaven.repo.local=/opt/pwebster/lts/R4_localrepo
bash$ mvn \
clean install \
-Dmaven.test.skip=true \
-Dmaven.repo.local=/opt/pwebster/lts/R4_localrepo
</pre>
</p><p>
Once finished, your build repo is in <b>R4_platform-aggregator/TMP/org.eclipse.sdk.epp/target/repository</b> and some Eclipse SDK zips are in <b>R4_platform-aggregator/TMP/org.eclipse.sdk.epp/target/products</b>. These locations might move when we migrate some releng information over to eclipse.platform.releng.eclipsebuilder.
</p><p>
This is still a work in progress, so the build doesn't produce all of the build output of our tradition PDE-driven build. Work is still being done to get the compile levels correct, and figure out a replacement or callout to the customCallBacks.xml.
</p><p>
There are also some other hiccups, like having to run the build twice as the first time it fails with a compile error in org.eclipse.jface. But in short order you have yourself a product build.
</p><p>
For more information see the <a href="http://wiki.eclipse.org/CBI">CBI</a> wiki.
</p>paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-26585254437644970132012-02-15T12:42:00.000-08:002012-02-15T12:42:13.799-08:00p2 can update your eclipse.iniI regularly switch my base SDK install to try out new developer integration builds, and it's not to much trouble to get it set up correctly thanks to <b>p2</b> and the <b>director</b>.<br />
<br />
<pre>eclipse/eclipse \
-application org.eclipse.equinox.p2.director \
-noSplash \
-repository \
http://download.eclipse.org/eclipse/updates/4.2-I-builds,\
http://download.eclipse.org/e4/updates/0.12-I-builds,\
http://download.eclipse.org/releases/juno,\
http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository \
-installIUs \
org.apache.commons.jxpath/1.3.0.v200911051830,\
org.apache.batik.xml/1.6.0.v201011041432,\
org.dojotoolkit/1.6.1.v201105210659,\
org.eclipse.nebula.widgets.gallery/1.0.0.R_0_20090212,\
org.eclipse.egit.feature.group,\
org.eclipse.jgit.feature.group,\
org.eclipse.emf.sdk.feature.group,\
org.eclipse.xtext.sdk.feature.group,\
org.eclipse.wst.xml_ui.feature.feature.group
</pre><br />
As you can see I use the director to set up my eclipse/running target with orbit bundles I need, with EGit, and with SDKs that I need like EMF, XText, XML Editors and Tools. I love a good automated process.<br />
<br />
With all functionality in use and with 23 platform and e4 git repositories for EGit/JGit to work through, it's easy to get an OOME with eclipse default settings. Because I'm testing downloads instead of upgrades, that means I have to update my <b>eclipse.ini</b> every time. It's minor, but it breaks the automated process.<br />
<br />
Since p2 provides the touchpoints that can modify the eclipse.ini already, it should be simple to hand-craft a local repo with an IU that can update the eclipse.ini as part of my director call.<br />
<br />
<pre>
<unit id='toolingorg.eclipse.e4.fix.jvmArg' version='4.2.0.I20120131-2200' singleton='false'>
<provides size='2'>
<provided namespace='org.eclipse.equinox.p2.iu' name='toolingorg.eclipse.e4.fix.jvmArg' version='4.2.0.I20120131-2200'/>
<provided namespace='toolingorg.eclipse.sdk.ide' name='org.eclipse.e4.fix.jvmArg' version='4.2.0.I20120131-2200'/>
</provides>
<requires>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.sdk.ide' range='[0.0.0,5.0.0)'/>
</requires>
<touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/>
<touchpointData size='1'>
<instructions size='2'>
<instruction key='unconfigure'>
addJvmArg(jvmArg:-Xms40m);addJvmArg(jvmArg:-Xmx384m);removeJvmArg(jvmArg:-Xms64m);removeJvmArg(jvmArg:-Xmx1024m);
</instruction>
<instruction key='configure'>
removeJvmArg(jvmArg:-Xms40m);removeJvmArg(jvmArg:-Xmx384m);addJvmArg(jvmArg:-Xms64m);addJvmArg(jvmArg:-Xmx1024m);
</instruction>
</instructions>
</touchpointData>
</unit>
</pre><br />
I added a <b>.feature.group</b> IU to make it stand out that the fix has been installed into this version of eclipse, and voila.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-58777015086599093012011-11-15T09:51:00.000-08:002011-11-15T09:52:05.282-08:00EGit and a shortlived topic branchI've been experimenting with git workflows in Eclipse/EGit, trying to leverage some of the (supposed) power or functionality we get from using git for our SCM. Fortunately, the EGit folks were able to offer some hints as to how to make that happen.<br />
<br />
The easiest way to get started is to create the topic branch off of your main <b>remote</b> branch, using <i>Team>Switch To>New Branch</i>. Because we want to avoid small merges, I already have <b>branch.autosetuprebase=always</b> set, and that's reflected in the defaults in the EGit Create Branch dialog. In my case I created <b>pwebster/bug357532</b> off of <b>origin/master</b>. That way changes to master will be picked up and my local changes rebased automatically.<br />
<br />
I also used the suggested pattern of <b><committerId>/branchName</b>. We hope to have a receive hook in place soon that allows committers to delete their own topic branches if pushed to the public repo. <br />
<br />
But if you aren't working on a feature branch, you probably want to push your topic branch commits back to your remote branch, in my case <b>origin/master</b>. You can do this by setting a push refspec on that remote. I went to my repository configuration in the <i>Preferences>Team>Git>Configuration</i> dialog and adding the following property: <b>remote.origin.push=pwebster/bug358020:refs/heads/master</b>.<br />
<br />
Now for a short lived topic branch, you're set. Pulling will keep you up to date with <b>origin/master</b>, and you can push your fix to <b>origin/master</b> without having to do a lot of switching/fast-forward merging/pushing/deleting.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-5437923295980673852011-11-09T10:05:00.000-08:002011-11-09T11:54:55.607-08:00Where the git did that go?I just came back from Paternity leave in the Eclipse SDK milestone (M3) week. The leave was great. Coming back was, as always, exciting. A slightly misconfigured tool had removed branches and tags (and an aggressive prune/gc had removed commits) during a push to our <a href="http://git.eclipse.org/c/platform/eclipse.platform.ui.git/">eclipse.platform.ui</a> repo, leading to <i>Bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=361707">361707</a> - I have broken the platform-ui git repository</i>. Because tags and commits were gone, we also broke all of the warmup I builds for our M3 week. My apologies to all that suffered.<br />
<br />
These are all done by legitimate actions supported by git ... it just turns out that if you have a process backed by a central canonical repository, you really don't want your source disappearing out from under you. "I might have pushed back most of our repo" is not an acceptable level of support :-)<br />
<br />
We were able to find a mostly complete repo, disable the Eclipse Foundation commit hook and push back the repo. We are discussing ways to limit this kind of damage in the future. See<br />
<br />
<ul><li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=362076">Bug 362076</a> - Better policy to guard against deleting all branches and tags from our public repos</li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=362361">Bug 362361</a> - Better policy ... enforce receive.denyDeletes = true</li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=362363">Bug 362363</a> - Better policy ... provide hooks to allow a committer to delete <userid>/branchname branches</li>
</ul>paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-79618365406015309062011-08-09T18:19:00.000-07:002011-08-09T18:19:17.832-07:00Git Migration and taggingThe Eclipse SDK, or <a href="http://download.eclipse.org/eclipse/downloads/">Eclipse Classic</a> as it now tends to be called, has been building and releasing for just about 10 years, using the PDE Build system. Our releases are based on map files, which contain the IDs, SCM, and co-ordinates of the plugins we need to build.<br />
<br />
When moving from CVS, where you can tag individual files, to git, where you tag a commit (the repo), this can cause headaches.<br />
<br />
The common practice of tagging the projects that change for each week's I-builds means that <a href="http://cvs2svn.tigris.org/cvs2git.html">cvs2git</a> generates a master branch that looks like a fir tree :-) The delete commits <b>remove</b> all of the projects that weren't tagged. That makes the commit accurate, but that's not the shape of the git repo we want. A little scripting and we moved the tags from the delete commits back onto the main branch.<br />
<br />
The other problem comes from the practice of tagging the release (<b>R3_6</b>) but only branching projects that change (<b>R3_6_maintenance</b>). In order for cvs2git to make the branch correct, the first commit on the <b>R3_6_maintenance</b> branch is delete commit. To make the important maintenance branches look correct, you can fix this one of 2 ways. Either rebase the branch around the delete commit (before you publish it to the public), or pre-condition the CVS repo so that all projects that are tagged <b>R3_6</b> are branched <b>R3_6_maintenance</b> as well.<br />
<br />
The scripts I used to fix Platform UI are in the <a href="http://git.eclipse.org/c/e4/org.eclipse.migration.git/tree/scripts">org.eclipse.migration/scripts</a> directory.<br />
<br />
<br />
<br />
paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-70965340756548498272011-07-29T11:36:00.000-07:002011-08-10T15:21:05.359-07:00Git Migration and ignore filesAs I mentioned in <a href="http://pweclipse.blogspot.com/2011/07/git-migration.html">Git Migration</a> I've been involved in the Platform UI CVS to Git migration using the <a href="http://cvs2svn.tigris.org/cvs2git.html">cvs2git</a> tool.<br />
<br />
After your first successful conversion of a test repo, you fire it up in eclipse and check it out. That's when you see ... a lot of untracked changes! Oh yeah, all our <b>.cvsignore</b> files are useless :-)<br />
<br />
Obviously we wanted a <b>.gitignore</b> at the root of our repo, from the beginning of time ... just like the catchphrase "there's an app for that", git will allow you to re-write your history so that it looks like the <b>.gitignore</b> was in every branch and tag since day one (<a href="http://stackoverflow.com/questions/3895453/how-do-i-make-a-git-commit-in-the-past">How do I make a git commit in the past?</a>). Obviously since this is a re-write, you need to do this as the last step <b>before</b> you publish your repo.<br />
<br />
<ol><li>create suitable file contents</li>
<li> add it to your repo</li>
<li>re-write all of the index trees in each commit to add the file</li>
<li>reset your repo</li>
</ol><br />
<br />
Here's the example as fed into bash:<br />
<br />
<pre>bash$ cat - >../gitignore <<EOF
bin/
*~
*.rej
*.bak
*.patch
javacore.*
heapdump.*
core.*
Snap.*
target/
EOF
bash$ new_file=$(git hash-object -w ../gitignore)
bash$ git filter-branch \
--index-filter \
'git update-index --add --cacheinfo 100644 '"$new_file"' .gitignore' \
--tag-name-filter cat \
-- --all
bash$ git reset --hard
</pre><br />
Now I have a <b>.gitignore</b> at the root of my repo, and my status and EGit views are not cluttered with spurious untracked files. Rinse and repeat for more specialized <b>.gitignores</b> in various project directories that need them.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-18914077313026809142011-07-20T10:59:00.000-07:002011-07-20T10:59:05.793-07:00Git MigrationA large part of the Open Source world seems hot on git these days (and DVCSs in general). I can kinda see why. For tracking changes, the notion of a commit definitely makes more sense than updating the versions on files that CVS has to offer. The ease of creating git repos plays well with one of my own beliefs, which is "Even for one's own little projects, if it's not in a VCS it may as well be written on the back of a napkin". Social coding sites like <a href="https://github.com/">GitHub</a> offer an ease of contributing to projects that contributors love, and git makes it easier to keep contributions (commits) from going stale than when dealing with patches in email or bug tacking systems. Git itself has useful tools for visualizing your repo (like <i>gitk</i>), tracking down when a bad behaviour was introduced (<i>git blame</i>), and a dozen others besides.<br />
<br />
And for those that miss their <b>C</b> roots, you can pretend your git hashes are pointers: <i>5eec2b04a70f704a7cdc1b77db59bb90ec03dd68</i> :-)<br />
<br />
With the Eclipse Foundation also interested in supporting git as its main VCS, the <a href="http://www.eclipse.org/projects/project_summary.php?projectid=eclipse">Eclipse Project</a> decided to move to git at the beginning of the Juno Release cycle. I've been involved with the Platform UI component migration.<br />
<br />
I'll write a second post soon with more details about the problems we encountered and some of the steps we took, but after a grueling 2 weeks the conversion of this component is done. Woo Woo!<br />
<br />
<ul><li>git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git</li>
<li>git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git</li>
<li>git://git.eclipse.org/gitroot/e4/org.eclipse.e4.tools.git</li>
</ul>paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-81207787315786569142011-06-17T13:07:00.000-07:002011-06-17T13:07:46.374-07:00p2 cheatsheetI was writing a p2 mirror script suggestion for a colleague. When it morphed into a sorta p2 cheatsheet, I thought I'd blog about it (so I can find it again when I need it :-).<br />
<br />
<b>repo syntax</b><br />
<br />
Most repos are specified via URLs like <b>http:</b>, but they can be files on the disk or even zipped repos:<br />
<br />
<ul><li>http://download.eclipse.org/<wbr></wbr>eclipse/updates/3.7-I-builds</li>
<li>file:///home/data/httpd/<wbr></wbr>download.eclipse.org/eclipse/<wbr></wbr>updates/3.7-I-builds</li>
<li>jar:file:///opt/pwebster/emf-<wbr></wbr>xsd-Update-2.7.0RC3.zip!/</li>
</ul><br />
Just a note: destinations are (almost) always normal directory paths, not URLs.<br />
<br />
<b>Mirroring repos</b><br />
<br />
You can quickly (well, I/O bound :-) mirror 2 builds repos so you can compare them on your disk. Here's an ant script for current, important, build repos.<br />
<br />
<pre><project name="Mirror" default="mirrorRepos">
<property name="eclipse36Mirror" value="${baseDir}/eclipse36" />
<property name="eclipse36Repo" value="http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200" />
<property name="eclipse37Mirror" value="${baseDir}/eclipse37" />
<property name="eclipse37Repo" value="http://download.eclipse.org/eclipse/updates/3.7-I-builds/I20110613-1736" />
<target name="mirrorRepos">
<echo message="Mirror from ${eclipse36Repo} to ${eclipse36Mirror}" />
<p2.mirror destination="file:${eclipse36Mirror}" ignoreerrors="true">
<source location="${eclipse36Repo}" />
<!--slicingOptions includeOptional="false" includeNonGreedy="false" latestVersionOnly="true"/-->
<!--iu id="org.eclipse.sdk.ide"/-->
</p2.mirror>
<echo message="Mirror from ${eclipse37Repo} to ${eclipse37Mirror}" />
<p2.mirror destination="file:${eclipse37Mirror}" ignoreerrors="true">
<source location="${eclipse37Repo}" />
<!--slicingOptions includeOptional="false" includeNonGreedy="false" latestVersionOnly="true"/-->
<!--iu id="org.eclipse.sdk.ide"/-->
</p2.mirror>
</target>
</project>
</pre><br />
<br />
You can run that from an eclipse instance, either in eclipse using an Eclipse Application, or from the command line (my preference):<br />
<br />
<pre>bash$ eclipse/eclipse -noSplash \
-application org.eclipse.ant.core.antRunner \
-DbaseDir=/some/useful/basedir -buildfile mirror.xml</pre><br />
It'll spit out some messages about unsatisfied IUs, but that's OK because you're using the slicer, not the provisioner.<br />
<br />
<b>IUs and version numbers</b><br />
<br />
If you're looking at plugin or IU versions, you can quickly get a list in the "IU=version" format:<br />
<br />
<pre>bash$ eclipse/eclipse -noSplash \
-application org.eclipse.equinox.p2.director \
-repository http://download.eclipse.org/eclipse/updates/3.7-I-builds/I20110613-1736 \
-list</pre><br />
If you pick a composite repo like <a href="http://download.eclipse.org/eclipse/updates/3.6" target="_blank">http://download.eclipse.org/eclipse/updates/3.6</a> you can list all of the IUs, and then install a specific version of <b>org.eclipse.sdk.ide</b>, for example.<br />
<br />
<br />
<b>Creating a product for your platform</b><br />
<br />
You can use the same scripts that the PDE build uses to generate a complete install for a platform:<br />
<br />
<pre><project name="Build Product" default="buildProduct">
<property name="p2.repo.URL" value="http://download.eclipse.org/eclipse/updates/3.7-I-builds" />
<property name="iuId" value="org.eclipse.sdk.ide" />
<!--property name="iuId" value="org.eclipse.platform.ide"/-->
<!--property name="iuId" value="org.eclipse.rcp.id"/-->
<property name="profile" value="SDKProfile" />
<property name="os" value="linux" />
<property name="ws" value="gtk" />
<property name="arch" value="x86_64" />
<target name="buildProduct">
<ant antfile="${eclipse.pdebuild.scripts}/genericTargets.xml" target="runDirector">
<property name="p2.director.installPath" value="${baseDir}/p2_${os}_${ws}_${arch}/eclipse" />
<property name="p2.director.profile" value="${profile}" />
<property name="p2.director.iu" value="${iuId} " />
<property name="os" value="${os}" />
<property name="ws" value="${ws}" />
<property name="arch" value="${arch}" />
<property name="p2.repo" value="${p2.repo.URL}" />
<!--property name="p2.director.version" value="an.IU.version"/-->
</ant>
</target>
</project>
</pre><br />
<br />
<br />
<pre>bash$ eclipse/eclipse -noSplash \
-application org.eclipse.ant.core.antRunner \
-DbaseDir=/some/useful/basedir -buildfile productBuild.xml</pre><br />
The exact same thing can be accomplished using the command-line director (just with a lot of arguments :-)<br />
<br />
<pre>bash$ eclipse/eclipse -noSplash \
-application org.eclipse.equinox.p2.director \
-repository http://download.eclipse.org/eclipse/updates/3.7-I-builds \
-installIU org.eclipse.sdk.ide \
-destination /some/useful/basedir/linux_gtk_x86_64 \
-bundlepool /some/useful/basedir/linux_gtk_x86_64 \
-profile SDKProfile \
-profileProperties org.eclipse.update.install.features=true \
-p2.os linux -p2.ws gtk -p2.arch x86_64 -roaming</pre><br />
<b>Installing into your own eclipse</b><br />
<br />
This is the shortest command line of all, and the easiest way to take a new eclipse and install features from scripts.<br />
<br />
<pre>bash$ eclipse/eclipse -noSplash \
-application org.eclipse.equinox.p2.director \
-repository http://download.eclipse.org/eclipse/updates/3.7-I-builds \
-i org.eclipse.releng.tools.feature.group</pre><br />
<b>More info</b><br />
<br />
More about the director command line: <a href="http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_director.html" target="_blank">http://help.eclipse.org/<wbr></wbr>helios/index.jsp?topic=/org.<wbr></wbr>eclipse.platform.doc.isv/<wbr></wbr>guide/p2_director.html</a><br />
<br />
More about the p2 tasks and all the options they can take: <a href="http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_repositorytasks.htm" target="_blank">http://help.eclipse.org/<wbr></wbr>helios/index.jsp?topic=/org.<wbr></wbr>eclipse.platform.doc.isv/<wbr></wbr>guide/p2_repositorytasks.htm</a>paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-47729029478639203942011-03-28T12:40:00.000-07:002012-01-06T05:35:11.421-08:00maven and tycho vs an Orion featureEclipseCon 2011 has come and gone, and I was lucky enough to be there. One of the nice things about going to speak at EclipseCon is the opportunity to see the other projects and technologies congregating around the Eclipse Foundation. I'll blog later about the talks I gave, but one of the things I tried while down there was using Maven and Tycho to build a p2 repo. <br />
<br />
I picked one of the Orion features. My efforts can be seen in git://git.eclipse.org/gitroot/e4/org.eclipse.orion.server.git in the <b>mavenExperiment</b> branch.<br />
<br />
There are some things maven needs to get started, which I put in a <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.server.parent/pom.xml?h=mavenExperiment">parent pom</a>. A tycho-version property (I needed the 0.11.0-SNAPSHOT so a <b>javax.servlet</b> import package could resolve) and a <b>pluginRepository</b> so I could load that version of tycho. The repositories to build from: 3 p2 repos in my case. Some build <b>plugin</b> configuration I copied from the tycho RCP example, including configuring the qualifier with <format>'v'yyyyMMdd-HHmm</format><br />
<br />
The <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/bundles/org.eclipse.orion.server.core/pom.xml?h=mavenExperiment">plugin poms</a> are straight forward, as I want manifest first builds. You just need to make sure the versions and IDs match. Same with <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/features/org.eclipse.orion.server-feature/pom.xml?h=mavenExperiment">feature poms</a>.<br />
<br />
To generate the p2 repo you need to specify 2 things. An <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.server.repository/pom.xml?h=mavenExperiment">eclipse-repository pom</a> (relatively straight forward, although I've copied in extra maven plugin statements). And a <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.server.repository/category.xml?h=mavenExperiment">category.xml</a> that lists the features you want in the repo.<br />
<br />
I list all of my modules in my <a href="http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.server.aggregator/pom.xml?h=mavenExperiment">aggregator pom</a>, and then run "mvn clean install".<br />
<br />
Ta da: a p2 repo with my 2 features in it.<br />
<br />
I'm still encountering some problem either with my configuration or with tycho itself. I open bugs for the $HOME/.m2/repository interfering with a second build: <a href="https://issues.sonatype.org/browse/TYCHO-606">https://issues.sonatype.org/browse/TYCHO-606</a> and trying to add extra categories to the p2 repo using category.xml results in the generated repo missing things: <a href="https://issues.sonatype.org/browse/TYCHO-605">https://issues.sonatype.org/browse/TYCHO-605</a><br />
<br />
I think there's some work to be done on the Execution Environment side as well, although JIRA appears to be down at the moment.<br />
<br />
Once the build has been configured to run with maven, the next person just has to check out the code and "mvn clean install". That looks promising. I'm glad I had the opportunity to try out maven and tycho.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-48997403817171850082011-03-10T05:08:00.000-08:002011-03-10T05:08:43.603-08:00A working state from a p2 updateIn one of our recent build/update cycles we made a change that was source compatible but not binary compatible. In this case (there are no errors anywhere) it's easy to miss that you need to tag the consuming bundle as well.<br />
<br />
The build ran fine, but the previous build's consuming bundle was used when creating the update site (since we didn't tag that bundle, the qualifier did not change).<br />
<br />
When an unsuspecting co-worker updated to the latest build, his system would no longer start at all with a number of java.lang.NoSuchMethodErrors.<br />
<br />
So how do you fix your install, given that you can't even bring up the workbench? As it turns out, p2 can help you. The SDK profile saves its state on each installation change. You can usually find this information in:<br />
<br />
<pre>bash-4.1$ ls eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile
1299467192263.profile.gz 1299499722731.profile.gz 1299761082054.profile.gz
1299467192395.profile.gz 1299499723473.profile.gz 1299761705917.profile.gz
1299467285942.profile.gz 1299499764937.profile.gz state.properties
1299467287251.profile.gz 1299500329056.profile.gz</pre><br />
Then you just need to pick the last stable version of your installation, and you can revert your install and restart your system.<br />
<br />
<pre> eclipse/eclipse -noSplash \
-application org.eclipse.equinox.p2.director \
-repository file:$(pwd)/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile \
-profile SDKProfile \
-revert 1299499722731
</pre><br />
Obviously you'll need to use a different eclipse install and the necessary <b>-destination</b> arguments if the corrupt bundle is *in* the director part of your install's p2 framework :-)<br />
<br />
The director won't run this command without specifying a <b>-repository</b>, but it's not important which one you use so I used the installations own SDKProfile repository.<br />
<br />
For more director information see <a href="http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_director.html">p2 director</a>.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-41753960023134979582011-02-23T11:01:00.000-08:002011-02-23T11:01:11.575-08:00PDE build as workspace exportA question came up on the newgroups^H^H^H^Hforums recently about a headless way to build/export features and plugins from a workspace. It turns out it is possible, using the pluginPath property.<br />
<br />
When you configure the PDE build build.properties:<br />
<ol><li>Your provided topLevelElementId has to be your feature, or a "master" feature.</li>
<li>You must provide an elementPath property that's the absolute path to your master feature.</li>
<li>Your pluginPath can then point to your workspace.</li>
<li>You probably want to skipBase, skipMaps, and skipFetch</li>
<li>p2.gathering = true will generate the p2 metadata</li>
<li>p2.category.site=file:/<full-path>/site.project/site.xml will include the site categories in the generated build repo</full-path></li>
</ol>You also have to override "gatherLogs" in your customTargets.xml. Your build repo is ready to install!<br />
<br />
But I wouldn't recommend it. Without digging into some arcane PDE build properties, it pollutes your workspace with build files, @dot directories, etc.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-33313387676480713742010-09-24T09:47:00.000-07:002010-09-24T09:47:10.116-07:00The simple RCP product buildA question came up the other day on the difference between building small RCP apps pre-3.5 with the delta pack, and what to do in the new p2 world. So I did what everybody wishes they could do ... I cornered Andrew Niefer and asked him a few questions.<br />
<br />
I created the standard RCP mail app and then a feature to contain it. The I created a .product file that includes the RCP mail feature and org.eclipse.rcp (a few more plugins than the mail app technically needs, but a good starting point). The .product also had some branding information/splash information in it.<br />
<br />
I want to use a product build, as I'm building a product. If you're going to be creating your runnable repo from p2 repos, you don't set baseLocation any more. You care about 2 different properties:<br />
<ul><li>repoBaseLocation - a directory where you can mirror your p2 repos, or at least the pieces you need. You can create multiple repo directories under this location</li>
<li>transformedRepoLocation - PDE Build will take your repoBaseLocation and convert it to a runnable repo (to be consumed by the build)</li>
</ul>Out of the regular build properties, this looks like:<br />
<br />
<pre>buildDirectory=${base}/buildDirectory
repoBaseLocation=${base}/repoBase
transformedRepoLocation=${base}/transformedRepos
</pre><br />
You also need to set the location(s) of the repos you will consume, and provide a product file:<br />
<br />
<pre>eclipsePlatformRepo=http://download.eclipse.org/eclipse/updates/3.6
product=${builder}/rcp_mail.product
runPackager=true
p2.gathering=true
</pre><br />
There are other options that need to be filled in the build.properties file, but that's left as an exercise to the reader. The next step is to set up your customTargets.xml. Because I assume the defaults for most everything, I don't have to copy out the template any more. For the p2 part of this exercise, just provide a preProcessRepos target<br />
<br />
<pre><span style="color: cyan;"><</span><span style="color: cyan;">project</span><span style="color: cyan;"> </span><span style="color: lime;">name</span>=<span style="color: #ff6060;">"RCP Mail customTargets overrides"</span><span style="color: cyan;"> ></span>
<span style="color: cyan;"><</span><span style="color: cyan;">import</span><span style="color: cyan;"> </span><span style="color: lime;">file</span>=<span style="color: #ff6060;">"${eclipse.pdebuild.templates}/headless-build/customTargets.xml"</span><span style="color: cyan;"> /></span>
<span style="color: cyan;"><</span><span style="color: cyan;">target</span><span style="color: cyan;"> </span><span style="color: lime;">name</span>=<span style="color: #ff6060;">"preProcessRepos"</span><span style="color: cyan;">></span>
<span style="color: cyan;"><</span><span style="color: cyan;">p2</span><span style="color: #8080ff;">.</span><span style="color: cyan;">mirror</span><span style="color: cyan;"> </span><span style="color: lime;">source</span>=<span style="color: #ff6060;">"${eclipsePlatformRepo}"</span><span style="color: cyan;"> </span><span style="color: lime;">destination</span>=<span style="color: #ff6060;">"${repoBaseLocation}/launchers"</span><span style="color: cyan;">></span>
<span style="color: cyan;"><</span><span style="color: cyan;">iu</span><span style="color: cyan;"> </span><span style="color: lime;">id</span>=<span style="color: #ff6060;">"org.eclipse.equinox.executable.feature.group"</span><span style="color: cyan;"> </span><span style="color: lime;">version</span>=<span style="color: #ff6060;">""</span><span style="color: cyan;">/></span>
<span style="color: cyan;"><</span><span style="color: cyan;">iu</span><span style="color: cyan;"> </span><span style="color: lime;">id</span>=<span style="color: #ff6060;">"org.eclipse.rcp.feature.group"</span><span style="color: cyan;"> </span><span style="color: lime;">version</span>=<span style="color: #ff6060;">""</span><span style="color: cyan;"> /></span>
<span style="color: cyan;"></p2</span><span style="color: #8080ff;">.</span><span style="color: cyan;">mirror></span>
<span style="color: cyan;"></target></span>
<span style="color: cyan;"><</span><span style="color: cyan;">target</span><span style="color: cyan;"> </span><span style="color: lime;">name</span>=<span style="color: #ff6060;">"postFetch"</span><span style="color: cyan;">></span>
<span style="color: cyan;"><</span><span style="color: cyan;">replace</span><span style="color: cyan;"> </span><span style="color: lime;">file</span>=<span style="color: #ff6060;">"${buildDirectory}/pluginVersions.properties"</span><span style="color: cyan;"> </span><span style="color: lime;">token</span>=<span style="color: #ff6060;">"HEAD"</span><span style="color: cyan;"> </span><span style="color: lime;">value</span>=<span style="color: #ff6060;">"${timestamp}"</span><span style="color: cyan;"> /></span>
<span style="color: cyan;"></target></span>
<span style="color: cyan;"></project></span>
</pre><br />
<br />
<b>org.eclipse.rcp.feature.group</b> will mirror everthing you need for the <b>org.eclipse.rcp</b> feature, including the different platform fragments. <b>org.eclipse.equinox.executable.feature.group</b> will mirror the features that a product build can use to create your specific executables (rebranded or renamed, etc). PDE build will run the <i>p2.repo2runnable</i> step for you automatically.<br />
<br />
Now you just need to run it:<br />
<br />
<pre class="Bash" name="code">eclipse/eclipse -application org.eclipse.ant.core.antRunner \
-buildfile eclipse/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/productBuild/productBuild.xml \
-Dbuilder=/opt/local/rcp/builder \
-Dbase=/opt/local/rcp/base \
-Dtimestamp=20100924-1100
</pre><br />
<br />
This generate 4 zips (the platforms from my configs= property) although the names were a little odd, they were complete product zips for each platform.<br />
<br />
Thank you to <a href="http://aniefer.blogspot.com/">Andrew</a> for the examples and tips I used to set this up.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-12345869136781449522010-07-26T05:46:00.000-07:002010-07-26T05:46:03.539-07:00Import Projects from a RepositoryI've been focused on e4/4.0 lately. A lot. Both on the modeled workbench infrastructure and on building the darn thing (I worship the ground Kim M walks on). But I discovered a feature in 3.6 that I find extremely useful. When importing plugins and fragments from any target platform, you now have the option to import them from (the CVS) repository.<br />
<br />
Being able to import the source has always been useful if you want to see how something in JDT or PDE works, or if you want to tweak part of the behaviour of one of your plugins, or for the really brave, you want to see if you can fix a bug :-)<br />
<br />
But while useful it has always been a problematic feature. Creating source bundles always lost the shape of the original project and its build information, since the source bundle is a representation of the binary bundle. The more complicated the layout or building of the original bundle, the further away the source bundle is from the actual plugin project.<br />
<br />
And so "Import Project from Repository". Just grab the project. You have the option to take the tag that was used to build the bundle (the exact source in your target) or just grab it from HEAD (to get the latest). Fiddle with it. Reset it. Generate a patch for a fix that would actually apply to the bundle source! The committers will love you forever!!<br />
<br />
Well, perhaps that's a little over the top, but I think it's a handy feature for plugin developers that need to poke around in someone else's bundles.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-40038081966389246502010-06-11T09:54:00.000-07:002010-06-11T09:54:55.706-07:00Maybe a comment policyAs much as I do enjoy the comments I get from such as "佩GailBohanan1蓉" I've decided to try comment moderation so I don't have to continually delete comments from my posts. So what's my moderation policy:<br />
<br />
1) no adult site links<br />
2) keep the language clean<br />
3) stay more or less on topic<br />
<br />
#1 is obvious <br />
<br />
#2 well, this is a work related/technical blog. While sometimes eclipse might drive us to distraction, those moments can be captured using English (or the Language of your choice)<br />
<br />
#3 this has a lot of flexibility (discussions will go wherever they want), but it is mostly in place to keep eclipse blogs from digressing into discussions about Chris Aniszczyk's Armani jorts... :-)paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-16147494924796292482010-02-19T11:05:00.000-08:002010-02-19T11:05:37.905-08:00PDE will tell youWe're experimenting with a lot of new technology in e4 and with different development paradigms. It's all good. But development on 3.x and with PDE will continue for many years to come, and PDE has some often overlooked tools that can really help you develop your plugin and find your IDs.<br />
<br />
1) Plug-in Selection Spy (ALT+SHIFT+F1) activate a part or dialog page and hit ALT+SHIFT+F1. Plug-in spy will open a popup and describe the contents (at least it will try). It will provide information about what ID and implementation class the focus part has, as well as which plugin contributed it, what are the active identifiers (menu, help, etc) and what type is the selection that part publishes.<br />
<br />
2) Plug-in Menu Spy (ALT+SHIFT+F2). Hit ALT+SHIFT+F2 and then pick a menu item. The popup will provide information about where that item lives, action ID, command IDs if available, etc.<br />
<br />
3) In the PDE Editor, the Browse... button. Many extensions need IDs provided in another extension. For example a menu contribution (org.eclipse.ui.menus) needs a commandId (org.eclipse.ui.commands). If you are asked to fill in an ID and there is a Browse... button, use it. It will give you a filterable list, and cuts down on cut&paste errors.<br />
<br />
These 3 are examples of PDE tools that you probably don't use very often, but when you need them they're *really* helpful.paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-87557685650700889592010-02-05T11:39:00.000-08:002010-02-05T11:39:01.941-08:00e4 and "early" compatibility<p>As the model for the e4 workbench stabilizes we're back working hard on the compatibility layer. Right now it consists of the gutted org.eclipse.ui.workbench plugin. The idea is to support the API we have in org.eclipse.workbench, but based on the e4 workbench model and e4 services, instead of the mass of internal code in parts, perspectives, and presentations.</p><p>We're taking a 2 pronged approach. Creating an e4 IDE application and slowly adding useful views and actions, seeing what is needed to bring them up. We want to support a useful number of views (like the Project Explorer and Problems view) sooner rather than later.</p><p>We're also running the <code>org.eclipse.ui.tests.api.ApiTestSuite</code> (after cleaning up internal references in the tests themselves with the aid of a tweaklet). ApiTestSuite covers the most common scenarios (opening and closing windows, perspectives, views, and editors), and supporting our API is a good way to help 3.x plugins run on e4 with the compatibility layer.</p><p>There's always a lot to do, so if you are interested please check out <a href="http://wiki.eclipse.org/E4/Compatibility/Running_the_compatibility_layer">http://wiki.eclipse.org/E4/Compatibility/Running_the_compatibility_layer</a>. You can also post to the <a href="https://dev.eclipse.org/mailman/listinfo/e4-dev">e4-dev</a> mailing list, or join us on irc at irc://freenode.net/#eclipse-e4 </p>paulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-62379342665602994892009-11-03T05:04:00.000-08:002009-11-03T05:57:21.221-08:00e4 and injectable command executionI'm fond of most of the Command Framework in Eclipse 3.x (I have to maintain it after all :-) The notion of an abstract command (as opposed to the Command class) has 2 interesting responsibilities:<br /><ol><li>Am I enabled?</li><li>Do something.</li></ol>In 3.x, commands delegate them to the command's currently active handler. Two aspects of the 3.x implementation aren't quite right in my opinion.<br /><br />Responsibility #1 is implemented as state (<code>isEnabled()</code>) on the Command itself. Because a command is a global singleton (it's supposed to represent the operation) this has the unintended side effect that a command is enabled or disabled globally for the application. The active handler determines the state, but based on whatever information it wants (which may or may not be the same information it will execute against).<br /><br />Responsibility #2 is implemented in the handler's execute method. It can then use the execution event to get the <code>IEvaluationContext</code> and extract information out of it. This mostly works well, and you end up treating the <code>IEvaluationContext</code> as a map.<br /><br />In e4 we're looking <code>IEclipseContext</code> "<a href="http://www.eclipse.org/e4/resources/e4-whitepaper.php">Contexts: the service broker</a>" which provides a localized view into the application state (i.e. what you can see from your view or editor makes sense). Information relevant to the state of the application is stored in your context in 2 forms. Some information is identified by class (<code>ECommandService.class.getName(), EventAdmin.class.getName()</code>) and some information is identified by name (<code>selection, activePart</code>).<br /><br />Now the fun part. In e4 a handler for a command can define 2 methods:<br /><ul><li><code>canExecute(*)</code> - This will be called by the framework before trying to execute a command</li><li><code>execute(*)</code> - This will be called by the framework when appropriate (can you guess what it does? :-)</li></ul>But in e4 you don't need to extract your variables from your context, you can ask for them directly:<br /><code><pre><br />public boolean canExecute(<br /> @Named("selection") IStructuredSelection selection);<br />public void execute(<br /> @Named("selection") IStructuredSelection selection, <br /> Shell shell);<br /></pre></code><br />When the framework needs to call either method, it will inject the needed information from the appropriate <code>IEclipseContext</code>. It uses the <code>@Named</code> annotation if it is present, or the type of the parameter (for example, <code>Shell.class.getName()</code>) if <code>@Named</code> is not.<br /><br />In e4 1.0 we're adopting the <a href="http://jcp.org/en/jsr/detail?id=330">JSR 330</a> annotations for injection (plus a few extras that we need). This is still a work in progress, but it's moving right along. If you are interested, now is the time to get involved - <a href="http://wiki.eclipse.org/E4">http://wiki.eclipse.org/E4</a>.<br /><br />There's a lot more to this story, so stay tuned for the next update.<br /><br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-46774427331966565492009-10-06T06:16:00.000-07:002009-10-06T07:08:47.364-07:00Continuous integration of Platform UI testsWith the work I was doing for <a href="http://wiki.eclipse.org/E4/Builds">e4 builds</a> I've had the opportunity to set up a PDE build and test environment. So I thought I would setup the Platform UI automated tests to run in a continuous build cycle on a machine in the lab.<br /><br />I think it's interesting because:<br /><ol><li>The tests need to run against the latest I build for that week</li><li>I need to patch 2 features to install my plugins from HEAD. I just followed Andrew's <a href="http://aniefer.blogspot.com/2009/06/patching-features-with-p2.html">instructions</a>.<br /></li><li>I wanted to use p2 to configure the tests, not the Automated Test Framework<br /></li></ol>As there's no real packaging or reuse involved, I just set up 3 features to drive the build. My 2 patch features, which include all of the Platform UI plugins that need to be replaced in org.eclipse.rcp and org.eclipse.platform. And my test feature, which includes the 2 patch feature, all of the Platform UI test plugins that contain my automated tests, and the automated test framework plugins:<br /><ul><li>org.eclipse.core.tests.harness</li><li>org.eclipse.test.performance</li><li>org.eclipse.test</li><li>org.eclipse.ant.optional.junit<br /></li></ul>Setting up PDE build involves copying the headless build templates (build.properties, customTargets.xml) and setting the parameters to match your build environment. Then creating a map project that's pointing to the correct features/plugins, and away you go.<br /><br />For continuous builds you tend to want to build from HEAD. The best way (especially if you have a real map that's is regularly tagged for something else) is to set to properties:<br /><code></code><pre><br /> forceContextQualifier=v${buildId}<br /> fetchTag=HEAD<br /></pre><br />That way you don't end up with a lot of plugins that look like com.example.plugin_HEAD :-)<br /><br />I also want to generate a p2 repo so I can consume my build easily. That's the standard set of p2 properties at the bottom of the build.properties file.<br /><br />Once that's up (and a few tweaks to the customTargets.xml to use the latest I-build I will provide) and then you can build with the org.eclipse.ant.core.antRunner application.<br /><br />Now I want to use p2 to run my automated tests. First I had to use XSLT to fix the content.xml and relax the feature patch version ranges (feature patches will target a very specific feature qualifier combination). There's a potential p2 <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=280314">fix</a> in the works, but simple XSL will do for now.<br /><br />I'm running the automated tests in my postBuild, with modified code I swiped from the Eclipse SDK automated test framework. The difference is that instead of having to generate a test.properties with the correct test plugin to test plugin version mapping and trying to unzip the build plugins into the eclipse test instance, the setup to run the tests now involve:<br /><ol><li>unzip the eclipse test instance</li><li>Call the director to install the plugin under test, the support plugins, and the patch features</li><li>call the plugin's test.xml<br /></li></ol>It manages all of the version numbers and dependencies for free, so your list of IUs looks like:<br /><br />-installIUs ${testPlugin}, org.eclipse.test, org.eclipse.ant.optional.junit, org.eclipse.ui.test.platform.patch.feature.group, org.eclipse.ui.test.rcp.patch.feature.group<br /><br />And now I have my headless automated test environment :-) The relevant build files and map files can all be found in <a href="http://dev.eclipse.org/viewcvs/index.cgi/platform-incubator/ui/org.eclipse.ui.automated.build/org.eclipse.ui.releng/">CVS</a>.<br /><br /><ul><li>:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse</li><li>platform-incubator/ui/org.eclipse.ui.automated.build/org.eclipse.ui.releng<br /></li></ul>There are a lot of opportunities for improvement in this environment (continually updating the build target from http://download.eclipse.org/eclipse/updates/3.6-I-builds for example) but this is enough to get me started.<br /><br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-71586644763653519612009-08-18T05:47:00.001-07:002009-08-18T05:49:35.779-07:00Eclipse againThis last year has been very busy, working to finish Eclipse 3.5 and getting the <a href="http://wiki.eclipse.org/E4">Eclipse e4 Tech Preview</a> into shape. Over the next few months, I hope to expound on some of the new techniques that can be used with Commands, Handlers, and Menu contributions as of 3.5<br /><br />But really, I'll post something this time :-)<br /><br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-1162235357115845942006-10-30T10:55:00.000-08:002006-10-30T11:09:17.136-08:00Place command in menus in eclipse 3.2In eclipse 3.2, there is good support for keybindings, commands, and handlers. There are some snippets available at <a href="http://wiki.eclipse.org/index.php/Platform_Command_Framework">Platform Command Framework</a>.<br /><br />But it's not obvious how to link your command+handler implementation to a menu or toolbar item. The <action/> elements have a definitionId attribute that can link the action to a command, but that allows the action's IActionDelegate to be linked to the keybinding (through the command). It turns the action's IActionDelegate into a handler for keybinding purposes through the use of an ActionHandler proxy class.<br /><br />But what if you would prefer to implement your commands and handlers, and then just have the command called from your menus the same way it is through keybindings.<br /><br />As it turns out, there is public API that will allow you to create a GenericCommandActionDelegate. I have an example available on the <a href="http://wiki.eclipse.org/index.php/Platform_Command_Framework">Platform Command Framework</a> page.<br /><br />The implementation takes advantage of the fact that the action element is created through IConfigurationElement#createExecutableExtension(*), which means that your action delegate can implement IExecutableExtension and receive extra configuration information from the plugin.xml.<br /><br />It's not a perfect solution for 3.2 (there would need to be more work to support something like checked state or radio buttons), but it will allow you to focus on creating command and handlers, and then using the action based extensions to execute your commands.<br /><br />The same strategy could be used for 3.1 as well, although some modifications would have to be made. In 3.1, you have to build your own ExecutionEvent and call the Command#execute*(*) method yourself.<br /><br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-1150987828922395262006-06-22T07:37:00.000-07:002006-06-22T07:59:23.020-07:00What can the Command framework do for you?In 3.2 much more of the eclipse action infrastructure has moved onto the command framework. It is based on 4 extension points.<br /><br /><span style="font-weight:bold;">org.eclipse.ui.commands</span> and the ICommandService create the abstract user command (like COPY). <span style="font-weight:bold;">org.eclipse.ui.handlers</span> and the IHandlerService allow plugins and interested parts to provide an implementation for the COPY command.<br /><br /><span style="font-weight:bold;">org.eclipse.ui.bindings</span> can map key sequences to commands, and IBindingService can programmatically review those keybindings. <span style="font-weight:bold;">org.eclipse.ui.contexts</span> and the IContextService can activate contexts, which can be used to scope the keybindings.<br /><br />The IBindingService can be used to programmatically add new keybindings ... but not easily. There was some example code and discussion on the newsgroup:<br /><br /><a href="http://dev.eclipse.org/newslists/news.eclipse.platform/msg55884.html">Re: Action accelerators</a><br /><br />In 3.2 there is still no replacement for placing the command in a menu or toolbar. <actions/> (which should always be linked to commands, BTW) are still used, and the work is done in 4 extension points. org.eclipse.ui.actionSets, org.eclipse.ui.editorActions, org.eclipse.ui.viewActions, and org.eclipse.ui.popupMenus.<br /><br />Providing this replacement will be part of the command framework work for 3.3.<br /><br />I'm still wondering if this information should be captured on a wiki for updating (until it can make it into the 3.3 documentation), or just left floating around the newsgroups ...<br /><br />Later,<br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.comtag:blogger.com,1999:blog-29207064.post-1149341595226770482006-06-03T06:30:00.000-07:002006-06-03T06:33:15.236-07:00Eclipse, you say? Very interesting.It's been just over a year since I joined the Eclipse team. I've been hearing about these blog postings that other Eclipse committers and Eclipse Foundation members maintain, and thought I would add my 2 cents into the pot.<br /><br />But later, this first post was very tiring :-)<br /><br />PWpaulweb515http://www.blogger.com/profile/13481600474889179891noreply@blogger.com