Wednesday, August 25, 2010

Headless Build for Beginners - part V

Headless building Update Site

There is no easy way to achieve this. There have been some discussions in past and the Build and Test Automation article too touched it in brief. But its all hacky. I tried various stuff but the closest I could get was build features and plug-ins using (mentioned in) a site.xml and generating the metadata for them. The site.xml can be placed with them manually but I could not find a way to (automatically) update the site.xml with the feature and plug-ins build qualifiers. (There are always hacks like having a dummy site.xml and do a find-replace in it. Or write a custom ant task that emits XML for ste.xml - none of the hack is very maintainable or scalable)

After more investigation I realized may be I was trying to solve the wrong problem. We really don't need the update site (not if you are using Eclipse 3.4 or later). A p2 repository is not only easy to generate but is also the recommended way of distributing features and plug-ins.

Headless building a p2 repository

Now a p2 repo can be generated either from a bunch of features and plug-ins or directly from a product configuration. Both explained in Eclipse help. We will here take a product configuration and build a p2 repository for it. The setup will be same as discussed before. However this time, we will copy all the files from /org.eclipse.pde.build/templates/headless-build folder to our build configuration folder (build\buildConfiguration). Thus, the build structure will now looks like this

<buildConfigurationDirectory>
       allElements.xml
       build.properties
       customAssembly.xml
       customTargets.xml
<buildDirectory>
       plugins/
              com.example.helloworld
              com.example.product
                     example.product
       features/
              com.example.helloworld.feature

The current setup will generate the product when build. We now need to add a hook for repository generation. This can be done in customAssembly.xml. Open it in Eclipse or your favorite text editor and make the following changes in post.gather.bin.parts target.

<target name="post.gather.bin.parts">
 <p2.publish.featuresAndBundles
  repository="file:/${buildDirectory}/repository"
  source="${buildDirectory}/tmp/${archivePrefix}" 
  compress="true"
 >
 </p2.publish.featuresAndBundles>
</target>       

Note that p2.publish.featuresAndBundles is just of the of ant task that can be used to generate metadata. There are more for different situations. The idea here was more to see how to add custom call in ant scripts.

Run the build as before
java -jar c:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile c:\eclipse\plugins\org.eclipse.pde.build_3.6.0.v20100603\scripts\productBuild\productBuild.xml -Dbuilder=c:\build\buildConfiguration

This will create a p2 metadata repository in file:/${buildDirectory}/repository folder. You can control the location using repository property.

Tuesday, August 24, 2010

Headless Build for Beginners - part IV

Customizing the build

Not always we want the build to happen according to the out-of-the-box scripts.In fact, customizations are almost always needed - be it fetching the sources or the way we wish to assemble them. PDE Build provides a set of templates which can be used to hook in the customize (add to and/or override) the default behavior.

These templates are available in PDE Build plug-in (inside templates\headless-build folder of org.eclipse.pde.build_<version><qualifier>). The scripts and templates are one the main reason why PDE Build plug-in is a directory and not a jar.

The purpose and usage of these templates have been explained nicely in Eclipse help under the topic Customizing a Headless Build.

These templates are
  • customTargets,xml
  • allElements.xml
  • customAssembly.xml
In short, the customTargets.xml have various pre- and post- ant targets that build.xml (or productBuild.xml - in case you are building a product) calls before and after each process (like setup, source fetch, build, assemble, package, etc). Similarly, the targets in allElements.xml and customAssembly.xml gets delegated for various jobs.

To use these templates we need to copy them in the build configuration directory (c:\build\buildConfiguration in our example) where we stored build.properties file in previous steps. And then modify the appropriate targets. This is what we will do for building an update site in next step.

Tuesday, August 17, 2010

e4 Talk by Boris

Boris Bokowski (@bokowski) will be talking about e4 at IBM EGL Campus on Friday, August 20, 2010 (3 to 4 PM). See the details on the Bangalore Eclipse Developer's Groups.

Friday, July 30, 2010

PDE Good Practices: #7 Keep build.properties synced

We often land up in situations like "it was working in my workspace but exported plugins are behaving differently". An important thing to notice is that workspace is build considering the project classpath settings. However, the Export wizard or headless build does not have access to it. They reply on build.properties file. Thus it is very important to keep it in sync with the project settings. Eclipse Helios (3.6) added a bunch of preferences to help you do just that.


I would even recommend having project specific preferences enabled whenever possible. This will ensure all developers are reported for problems and their workspace settings doesn't have them ignored.

PDE Good Practices: #6 Share target definitions

Always have your target definitions in a project instead. This way

  1. it can be added to source control repository and changes to it can be tracked.
  2. all the other members who wish to work with that code can share it and thus compile against the same target. This will keep everyone on same page.

Thursday, July 22, 2010

PDE Good Practices: #5 Prefer target over workspace

Remember it is a 'good practice' and not necessarily the best suited to your needs. So unless you are sure what you are doing, it is advisable to keep all the dependent plug-ins in target. Check-out only the those which you need to modify, The benefits are

  • A small workspace is easier to follow
  • Even a full build will be much faster
  • Since target platform can be shared, you can be sure that you are build against the same exact version as your peers
  • Launch will be faster

If you miss that Types are not showing up in the searches, use PDE preference to add all the target plug-ins to the Java search.


Tuesday, July 20, 2010

PDE Good Practices: #4 Use startup code carefully

Be very careful when adding code to
  1. Plug-in load and constructor



  2. org.eclipse.ui.startup extension

These places have a big impact on application startup time. Also note that the if there are many plug-ins dependent on one plug-in and that plug-in is doing something on load (which it shouldn't be) then it may be delaying the loading of the whole stack.

Headless Build for Beginners - part III

Automated building an RCP application from a product configuration file

Most of this post contains same info as the eclipse help page with same heading.

Creating a product configuration file is easy. Check the eclipse help page explains it well. Assuming the our product config example.product looks like this and resides in a plug-in com.example.product.




Basic Setup
We will need 3 directory paths
  1. where the features and plug-ins to be build will reside. We will call it buildDirectory.
  2. where the build configuration file (build.properties) will reside. We will call it buildConfiguration.
  3. where the eclipse installation resides. We will call it baseLocation.
Now to prepare these directories
  1. Copy the features and plug-ins in side the buildDirectory. Ideally this will be a source checked out from the version control system. Custom ant tasks can be used to automate that. For this example, the directory shall look like this
  2. <buildDirectory>
           plugins/
                  com.example.helloworld
                  com.example.product
                         example.product
           features/
                  com.example.helloworld.feature


  3. Copy build.properties file from baseLocation/plugins/org.eclipse.pde.build_<version>/templates/headless-build to buildConfiguration folder. This file will configure the build and the output.
  4. Now we need to edit this build.properties file and fill in the parameters
    1. product=C:/build/buildDirectory/plugins/com.example.product/example.product
    2. This entry shall point to the product configuration file. The features/plugins mentioned in this file will only be picked for the build but searched in buildDirectory and baseLocation.
    3. archivePrefix=HelloWorld
    4. The archivePrefix is the name of the Folder under which the product will reside.
    5. configs=win32, win32, x86
    6. The configs shall point to the platforms for which product has to be build. The eclipse mentioned at baseLocation should have RCP Delta Pack. Without the delta pack, the build wont be able to create product for other platforms. Also, when troubleshooting for missing config or launch files, ensure that right version of delta pack is installed.RCP Delta Pack is build along with SDK so the same version shall be used. I am building only for windows that is that the configs entry is for only win32. For building other platforms, uncomment the required platforms. The platforms are delimited using & \.
    7. buildDirectory=C:/build/buildDirectory
    8. This will the buildDirectory we setup above.
    9. buildType=I
    10. I is for Integration build, N for Nightly, M for Milestone, S for ...I dunno. But you got the point.
    11. buildId=ExampleProductBuild
    12. This will name the build archive.
    13. base=C:/
      baseLocation=${base}/eclipse
    14. The base is the location which contains the eclipse installation (with RCP Delta Pack).
Running and understanding output

The build will be invoked as before

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-installation-path>\plugins\org.eclipse.pde.build_<version><qualifier>\scripts\productBuild\productBuild.xml -Dbuilder=c:\build\buildConfiguration

example

java -jar c:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile c:\eclipse\plugins\org.eclipse.pde.build_3.6.0.v20100603\scripts\productBuild\productBuild.xml -Dbuilder=c:\build\buildConfiguration

The output will look like this

I.ExampleProductBuild
│   ExampleProductBuild-win32.win32.x86.zip

└───compilelogs
    └───plugins
        └───com.example.helloworld_1.0.0.201007191243
                @dot.log


The folder I.ExampleProductBuild will contain the build logs and the product build ExampleProductBuild-win32.win32.x86.zip. If we had chosen other configs they too will appear here in separate zip (or whichever format we specify).

Thursday, July 8, 2010

PDE Good Practices: #3 Lazy-loading and Singleton plug-ins

Lazy Loading

When a plug-in is marked for lazy loading it is NOT loaded until it is needed. This helps in keeping the memory footprint of application small as possible.

A plug-in can be marked for lazy loading by checking the 'Activate this plug-in when one of its classes is loaded' checkbox on the Manifest editor overview page. This create the following entry in the Manifest.MF file.

Bundle-ActivationPolicy: lazy

Singleton plug-ins

It is preferable to use singleton plug-ins unless you know what you are doing. If a plug-in exposes extension points then it has to be singleton. But if not, it is still advisable to keep them singleton. This would ensure only one version of the plug-in is loaded at a time and generally its the latest one (unless version bound).

A plug-in can be made singleton by checking the 'This plug-in is a singleton" checkbox on the manifest editor overview page.

OSGi environments generally prefer non-singleton plug-ins as they can be dynamically installed.





Thursday, July 1, 2010

PDE Good Practices: #2 Externalize bundle strings

Externalize all bundle strings.
  • Use ‘Usage of non-externalized strings’ preference




  • Enabling the preference marks all the strings that should be externalized.

  • Use 'Externalize Strings Wizard' to externalize the strings


  • 'Bundle-Localization' entry in Manifest points to the properties file containing the externalized strings.


The value 'plugin' for 'Bundle-Localization' entry means that there will be a 'plugin.properties' file in the plugin root containing the externalized strings e.g. '%Bundle-Name'. 

PDE Good Practices: #1 Separation of Concerns

  • Do not create monolithic plug-ins.
  • A plug-in is used to group the code into a modular, extendable and sharable unit. 
  • Prefer having  separate plug-ins for Core, UI, Doc, etc 
  • Separate the platform/locale code into fragments.
  • Put related plug-ins under same feature.


Wednesday, June 16, 2010

Headless Build for Beginners - part II

Building through features

Plug-ins are rarely required to be build in isolation. The nicer way of building them is through features. Of course, features are more useful from distribution and deployment point of view. A feature is build the same way as a plug-in. Include the required plug-ins in the feature.xml and generate the build.xml from build.properties file (right-click and choose PDE Tools). Now launch the feature build.

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<feature-project-path>\<build-xml-path>

example
java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld.feature\build.xml

Note that build will fail if the included plug-ins do not have the build.xml generated for them. This is not a likely scenario and definitely not the way it is done. But let it be for time being. Generate the build.xml for all the plug-ins for build to succeed. Later on we will see how it can be done without it.

Passing parameters to AntRunner from command line

The build generated by the above command will leave the feature jar inside the feature project and the plug-in jar inside the plug-in project folder. Of course they shouldn't scattered all around. They need to be collected to one place.

Open the build.xml for the plug-in project and inside the 'init' target there is one property called 'plugin.destination'. It is this location where the jar is finally created by the 'build.update.jar' target.

<property name="plugin.destination" value="${basedir}"/>

Change the value of this property to "${buildDirectory}". Make the similar change for the 'feature.destination' property in the build.xml for the feature project.

If the build is triggered now, it will fail because it can not find the value for the 'buildDirectory'. The value can be provided through command line using -D option.

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<feature-project-path>\<build-xml-path> -DbuildDirectory=<build-storage-location>

example
java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld.feature\build.xml -DbuildDirectory=c:\build\buildOutput

When the build is run, ${buildDirectory} will be replaced by the value(location) provided and jars will get created there.

More parameters can be supplied using -D<variable-name>=<value> from the command line.

Ant properties file

Passing parameters from the command line is not very scalable or maintainable. A better way is to pass the parameters using a properties file.

Create a properties file, say, 'custom_build.properties' inside a folder, say, 'buildConfiguration'. The name 'custom_build.properties' have been chosen to distinguish it from 'build.properties'. Carefully note that though both are name=value kind properties file, it is common(rather better) practice to not mix them. Since 'build.properties' has a special meaning in context of PDE, it is recommended that a different name is used to avoid any confusion.

Store the property and its value in the properties file.
buildDirectory=c:/build/buildConfiguration
Note the forward slashes instead of backslash. The backslashes will work too but needs to be escaped.

Now open the build.xml for the feature project and add the 'loadproperties' entry under the 'project' tag.
<project name="com.example.helloworld.feature" default="build.update.jar" basedir=".">
 <loadproperties srcfile="../../buildConfiguration/build.properties" />
        ...
This entry needs to be made only in feature project's build.xml and is not required for the plug-in projects' build.xml. They still can use the same variable name and will get the value from the properties file.

Note that the value for the 'srcfile' is a relative path and the ../../ (grand-parent directory) indicates that the properties file has been kept in one folder outside the folder (or workspace) containing the projects.

Monday, June 14, 2010

Headless Build for Beginners - part I

The easiest way to generate the plug-in jars is through Export Wizard. Assuming we already know this, lets try to play with headless build.

Headless Build
Here the workbench (IDE or UI) is referred to as 'head'. Headless build essentially means running the builds from command line in non-UI mode. This can be achieved by various means, however, we will start with java command line and org.eclipse.equinox.launcher jar.

Java -jar
This is standard Java part. Java executable has many command line options and -jar is one of them. The curious souls can learn more about packaging and executing jars. 

org.eclipse.equinox.launcher
Eclipse has its own OSGi implementation which is known as Equinox. 'org.eclipse.equinox.launcher' is a plug-in as well as executable jar that launches the OSGi Runtime. It is located under plug-ins folder as org.eclipse.equinox.launcher_<version><qualifier.jar> ( for example org.eclipse.equinox.launcher_1.1.0.v20100507.jar).
-application
This '-application' option tells 'org.eclipse.equinox.launcher' that which application has to be launched. The application is identified by its id. The application is discovered using the Application Admin service. The Runtime Application Model explains how it works.

org.eclipse.ant.core.antRunner
Its the application id for the AntRunner application. It is contributed by org.eclipse.ant.core plug-in and its purpose it to run Ant build files.

build.xml
Its the Ant script to build the plug-in. Good news is the we need not be expert in Ant (however it good to have some knowledge about it). The PDE Build can generate this help for us. Right click on the build.properties and select PDE Tools -&gt; Create Ant Build File. This will generate build.xml and javaCompiler...args files. There may be more and specially name of the later may vary depending on the output. entry in the build.properties file.

Putting the pieces together
Assuming that the name of the plugins project is 'com.example.helloworld' the command to build it headlessly will be

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<project-name>\<build-xml-path>

example
java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld\build.xml

Result
This will build the plug-in project according to build.xml script. Since it was generated for us from build.propertied, it is essentially this file that governs the build. Note that build.xml is not generated automatically not kept in sync with build.properties. For any modifications to be reflected, the build.xml file has to be regenerated.
Assuming our plug-in does not have the Bundle-Classpath entry in the Manifest.MF file and source.. and output.. are the only source and output entries in our build.properties. The resultant build of such a plug-in will be in a folder '@Dot' in the project along with the log-file @dot.log .
This is not quite we expected. We were hoping to see a com.example.helloworld_1.0.0.v201006141121.jar kind of file. This happened because the default target (task) will just compile the classes. To make it generate the jar, edit build.xml and make the default target 'build.update.jar' (mentioned in the very first line).

<project name="com.example.helloworld" default="build.update.jar" basedir=".">

This shall generate the com.example.helloworld_<version><qualifier>.jar in the project folder. The build.xml can be modified to have it created in a desired location instead. Also note that the timestamp that replaces 'qualifier' is not the build time but the time when the build.xml was generated.

Saturday, May 22, 2010

Admirer of Eclipse

Helios is looking for 360 friends http://www.eclipse.org/helios/friends.php I am sure with generous Eclipse community, this won't be hard to get. However, we can do something more.

I am suggesting a smaller donation package named 'Admirer of Eclipse'. For a donation of $15 or $20, the donor will get a batch like Friend of Eclipse and Early access to Helios release.

There are two main reasons I came up with this suggestion.

1. There is much less donation from AP region compared to other geographies. This is probably because $35 when converted to local currency becomes a significant figure. I feel may be $15 or $20 is more affordable.

2. One of the major benefit the 'Friends of Eclipse' enjoy is the faster downloads. Now since most Eclipse users at least here in India (and probably adjoining Geos) have 128 kbps or less internet connection. Hence, the larger bandwidth from Eclipse servers is no more a benefit for them.

Please vote a Yes or a No for the idea below (or http://poll.fm/1xfa3 if can't see it)







Sunday, May 2, 2010

Remote Debugging Eclipse

Recently I ran into a nasty bug that will get reproduced only in host Eclipse 1.The best way to catch them is by remote debugging.

Remote Debugging
Remote debugging is a java feature. Since Eclipse is java application (running inside a JVM) we can remote debug it given the JVM used to launch Eclipse supports it. Most JVMs supports remote debugging from pre-1.4 era.

WebSphere give a nice definition "Debugging a program running on one system while controlling the program from another system is known as remote debugging. The debugger supports remote debugging by allowing you to run the debugger user interface on one system, while running the debug engine on another system. The system running the debugger user interface is known as the local system. The system where the debug engine runs is known as the remote system."

How to remote debug Eclipse?
  1. Start the Eclipse as server
  2. We need to pass -Xdebug VM argument to Eclipse to tell JVM to get launched with debugger. We need to pass certain more options to tell it to start in server mode and listen to a particular socket.

    This command shall be entered on the command prompt
    eclipse.exe -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 

     

    See the complete details for the options and their meaning at Connection and Invocation Details page.

  3. Creating a Remote Java Application debug config
  4. Start another instance of Eclipse where we will debug the other instance launched in Step 1. Also check out the code that you want to debug. Once this is done, open debug launch configurations and choose 'Remote Java Application' and create a new debug config.


    The project text box shall contain the project which has the code that needs to be debugged. The connection type shall be standard socket attach while port will contain the socket address we gave in Step 1. The host is localhost we both instances are running of same machine.

  5. Connecting and attaching to the remote server
  6. Launch the debug config like any other debug config. This will launch the debug mode. Place the breakpoints and do the relevant actions in the server Eclipse instance to hit the.

  7. Debugging
  8. The debug process is same as normal debug. No differences. However, if you change the code then the updated code is not what that would run. Remember the server Eclipse is still running in separate JVM. So what you are getting is only a reflection of the code execution. The debug session will end when the serve Eclipse instance is closed or the client Eclipse is disconnected using the disconnect button in the debug view.
1. Host Eclipse: The default eclipse instance is referred to as Host Eclipse. When self-hosting, a new Eclipse is launched from it, it is referred to as Guest Eclipse or Nested Eclipse Instance.

Monday, April 26, 2010

Eclipse Day India 2010 - thank you

Bangalore hosted the first edition of Eclipse Day last Friday. And what a gathering it was. More hundred (actually around 110) Eclipse enthusiasts attended the event.

The event was scheduled to have 2 track of sessions after the keynote. But because of Eyjafjallajökull (I actually spent 30 minutes learning its pronunciation ) eruptions grounded most of the European flights, Daniel Megert could not make it for the event. And as we were scrambling for a keynote speaker, Rajesh Thakkar came to our rescue. Thanks Pradeep also persuading him.

Keynote:
Rajesh spoke about 'Agile and Open Source'. He walked us through agile principles and helped us visualize how they fit into open source world. In Eclipse, we are already following many of its principles. We have small iterations. We build and re-factor often. We react to changing requirements rather quickly. Our stakeholders can see what we are building anytime they want. And more importantly Rajesh cautioned us about the myths around the buzzword 'agile'.

After keynote we broke into 2 tracks. All the presentations were well received. The number of interested attendees varied from talk to talk but then we gave them tough choices too of which one to attend. The mood, however, was very exciting.

I wish I could sit and attend all the presentations but had to run around to ensure all talks continue on time and without hiccups. Anyway...am contended as I could meet so many Eclipse enthusiasts. But those who could attend the various talks, do blog about them.

Needless to say such events can not be successful without support from sponsors. So once again a special thanks goes to Eclipse Foundation, IBM Rational Software, Progress Software and Genuitec for supporting the event. We hope the event was up to your expectation and you also benefited from it as much we did.

Thank you all the speakers. You all did a great job and we really appreciate your efforts. A special mention needs to go for Kopal Kothari and Sarika Sinha - the two attendees who volunteered for anchoring the event. Without you it would have been impossible to keep the event on schedule. Since the entry was through registrations, we really thank all the volunteers at the registration desk - Lakshmi, Manju, Kopal, Raksha, Ayushman, Deepak and Satyam. Chetan, Kamalnath and Madhu Samuel did all the photography for the events. Hope they will get the time soon to upload the photographs. Others also who clicked pics please upload it to Flickr and tag is as 'EclipseDayIndia'.

All the presentations will soon be added to slideshare and the link will be made available on event web-site. Meantime, I would request the attendees to fill up a small feedback form.

Tuesday, April 13, 2010

Eclipse Day India 2010

Eclipse Day India 2010 will be held on April 23, 2010 at Monarch Luxur, Bangalore. Around 150 Eclipse enthusiasts from over 35 companies are expected to attend this event. This shows Eclipse is getting lot of love from Bangalore and many companies are either using it for their development needs or relying on it as a base for their products. 

The agenda for the event has been announced. Dani will be delivering the keynote address to Eclipse Day India attendees.

If you are attending the event do meet up in the networking lobby. We won't have a frosty beverage but nice coffee and yummy food instead :-) I am very excited about this event and eager to know the ways in which developers are using Eclipse in their projects.

Unconference

There will be an hour session where attendees can share their ideas, experiences and knowledge of Eclipse and related technologies. So please do come forward and share your stories.

Saturday, April 3, 2010

Feature based launching

Recently we made an conscious effort for making features first class citizens in target definitions. As a part of that effort PDE introduced Feature based launching. This is available in 3.6 M6 build.

Till now there was only a not so elegant way to self-host using features - Feature-based self-hosting. This has now been deprecated.

Feature-based launching


An eclipse application can now also be launch just by picking the feature to launch with. This will be very helpful as in most scenarios as we have plug-ins grouped under features and we will want to have all plug-ins in a feature launched.


(This is M7 look. M6 look differs only with an extra version column)

How will it work?
It will work much like plug-ins only. However, few important points.

  1. The checkbox "Use feature from workspace if available" if self-explanatory. When checked, workspace feature will be used (instead one from target) to find the required plug-ins.
  2. Plug-in Location can be Default, Workspace or External (that is, Target Platform). Default means the value will be Workspace or External as selected using "Default Plug-in Location" option under "Restore Defaults" button.
  3. Plug-in Location means the location from where the plug-ins of a certain feature will be resolved. Thus, a feature might be getting picked from Target but its plug-ins can be picked from the Workspace instead.
  4. "Add Required Features" will only add (select) those features to the launch config which are mentioned as dependent features in feature manifest. It will not try to see if the dependent plug-ins map to any feature.
  5. Dependent plug-ins will be implicitly added to the launch. These are the plug-ins which do not belong to any feature and but the plug-ins of the selected features depend on them. e.g. com.ibm.icu
  6. These implicit plug-ins will be picked from same location from where the dependent plug-ins were picked from. If a finer control is needed then good old plug-in based launch is more suited.
Do report bugs if you find anything is not working as mentioned or expected.

Tuesday, February 16, 2010

Eclipse Day Submissions

Thanks everyone for showing such enthusiasm for Eclipse Day. We already have received some nice proposals. And as requested by many we are relaxing the last date to submit the talk proposals till Feb 28, 2010.

You may find the submitted proposals here  http://bit.ly/EclipseDaySubmissions

Tuesday, February 9, 2010

Did you register for Eclipse Day India 2010?

Registrations opened today for Eclipse Day India 2010 and it has been a great response. Half the seats already booked on day one. Attendees from over 20 companies have already registered and the number will only go up further only so register quickly.

We will be publishing the agenda by mid-March. So if you are an Eclipse enthusiast then it will be a great opportunity to not only attend some really nice presentations but also network with the community. 

And if you are a company which consumes Eclipse, then what better occasion to show your support by becoming a joint sponsor. IBM Rational has already come forward to joint sponsor event.

We would love to hear from you if you have been doing some nice work with Eclipse and plug-ins. Do submit your thoughts at http://EclipseDay.in.

Wednesday, February 3, 2010

[New in 3.6 M5] Configurable problem severities for build.properties

User will now have a finer control over build.properties related problems. Till now there was one catch all preference setting.


In 3.6 several new validations have been added to ensure build.properties reflects the project build path and environment settings. These can be turned on-off using the new additional preferences which looks like this




source. and output. preferences will control the problem reporting for all the source and output entries. A previous post discusses the validation rules in detail.

bin.includes and src.includes related preferences will handle the problem reporting for the corresponding entries. They are typically checked for files and folders existence. src.includes is also validated for presence of source folders. These entries were discussed in this post.
Java compliance properties preference refers to the problems reported for javacSource, javacTarget and jre.compilation.profile entries. The validations rules have been discussed earlier in another post.

The last one remains as catch all for remaining entries.

See Also
Eclipse 3.6 M5 - New and Noteworthy

Friday, January 15, 2010

Eclipse Day India 2010

Eclipse Day India 2010

I and Prakash are organizing Eclipse Day India 2010 on Friday, April 9, 2010. Since this is the first time it is being organized in India, we are keeping the theme fairly broad and simple - Eclipse Plug-in Development. You can find the details at http://eclipseday.in.

Sponsorship
Unlike Eclipse Demo Camp last year, this will be on a slightly bigger scale and thus we need sponsors. If you wish to support the event by extending a sponsorship please do get in touch with us. This will be a great opportunity to reach a gathering of more than 100 Eclipse developers and users from around a dozen companies.

Call for Talks
The Eclipse Day India is now inviting proposals for talk. Last day to submit  your proposals is Feb 15, 2010. See the details on the event wiki.

Attendee Registration
The event is FREE. There is no cost to attend however preregistration is must due to limited seats. Registrations open Feb 1, 2010.

Wednesday, January 6, 2010

I came third

This came as a complete surprise to me. Am at number three in 'Most contributed patches approved for IP Log' list.

Reproducing the list from Denis Roy's post.

Most contributed patches approved for IP Log
68 Ian Tewksbury       @ibm.com
51 Matthew Piggott     @piggot.ca
46 Ankur Sharma        @ibm.com
46 Chris Jaun          @ibm.com
44 Ian Bull            @eclipsesource.com
40 Tim Buschtoens      @eclipsesource.com
37 Pawel Pogorzelski   @ibm.com
36 Benjamin Cabé       @sierrawireless.com
31 Danny Ju            @oracle.com
29 Raksha Vasisht      @ibm.com

Am also glad for Raksha (who is part of same team as I am) that she too made it in Top Ten. We got committers right in September '09 so playing in a bigger league now. Hope to report (if not resolve) lots of bugs in 2010 :)