Monday, July 26, 2010

(CI) Building Eclipse PDE plugins from Maven

...is a pain in the arse.

After evaluating maven-pde-plugin, which one would think would make it easy, turns out not so much.

I've swapped over to using Tycho (because it appears to better support multiple build options, like update sites and RCP apps directly instead of just plugins and features), but that isn't proving trivial even in the most basic sense still.

But, using Tycho 0.9.0 from the ibiblio org.sonatype.tycho groupid (not to be confused with org.codehaus.tycho...or several other groupId's I've run into) you still have issues:

Errors like: "Cannot find lifecycle mapping for packing: 'eclipse-plugin' come up a lot. Looking at the off-chance there is a dependency issue, you are required to use an unstable release version of Maven 3 (as of 7/26/2010 at any rate). Using maven 3.0-beta-1 you now get "Unknown packaging: eclipse-plugin"...so not much help there either.

Searching for help on either of these issues get posts like 'fixed in Tycho 0.5.0', or 'you need to modify how you build from source'...which if you get the binary from a public maven repository one would hope would work as expected (per why most people want to use maven so you DONT run into these issues).

Other people mention 'update m2eclipse'...except I'm running this from the command line for the purpose of eventually moving to Hudson/Continuous Integration. Maybe I mis-understand the purpose of this maven plugin and it must be used in eclipse with m2e?

Please help if you read this!


EDIT: reason for chasing down why I want to automate Eclipse PDE builds is
1) I have an RCP app I would like to migrate over (from Eclipse 3.0 unfortunately)
2) primary reason was to pre-load company JDBC drivers for use in Eclipse (http://www.eclipse.org/forums/index.php?t=msg&goto=549384)


ANSWER: do not assume the 'convention':




WRONG plugin artifactId: maven-tycho-plugin

CORRECT plugin artifactId: tycho-maven-plugin

Wednesday, July 21, 2010

Web Browser plugins, how I loathe thee, let me count the ways.....

I have had a passionate dislike for web browser plugins. Yes, they add new exciting features...that you may or may not be able to control, or have a predictable behavior across the world-wide-web.

Take for example two very common plugins that I usually have to deal with for reporting, document management/archive, etc.

PDF plugins (Adobe)
TIFF plugins (variety)

Adobe PDF plugins -
  • Versions/upgrades regularly, users have to regular update 'the site', even though it's not the site, it is the plugin asking for upgrades.
  • To embed, not embed, dealing with pop-ups allowed.
  • And...here is a good one....the web-embed adobe plugin making *multiple* http requests for the same content, and if your logging didn't account for that - multiple logs (see http 206, byte serving/byte range requests).
TIFF plugins -
  • Variety of plugins with different options/features/control (and even something 'simple' like if the plugin allows multiple page viewing....apparently not standard?!)
  • You, your client/customer, or someone, has Outlook/Office installed and it has an update, a critical update, a security update, whatever -- and reverts to using the MS Tiff viewer by default despite your best effort to use a different TIFF plugin.
  • TIFF encoding/compression formats (i.e. g3/fax compression that has an X-Y ratio difference, that some plugins understand and show 'correctly', and others that show without the appropriate ratio and have 'crunched' images).
  • And the occasional TIFF that has a byte that isn't understood by Plugin XYZ, or other plugin, but yes on this plugin....search for it, they happen.
Then you add in other plugins like flash/shockwave, java applets, activex/silverlight, codec/encoding video players (whether to use quicktime, realplayer, windows media player, divx, ......), and developers just can not wait until HTML 5 becomes a real-world/real-usage deal.