» tagged pages
» logout

(Feed found, click Add Page to syndicate.) Error finding feed, please try again » Find feed title

A Blog Page allows you to add entries, for news or other time sensitive postings

(Login required to save to your tagged pages.)
(or Cancel)

Make further edits, (or Cancel)

(Login required to save to your tagged pages.)
(or Cancel)

(Editing anonymously: to be credited for your changes, login or register a new account)

Change Page Permissions? Changing these permissions will adjust who can modify this page.

Anonymous (change)
Swik Users (change)
(or Cancel)
Upload an image from your computer:
or Copy an image from a URL:
or Erase the current icon:
Icon Preview:

or Cancel

Erase EasyEclipse? The contents of EasyEclipse page and all pages directly attached to EasyEclipse will be erased.

or Cancel

(Editing anonymously: to be credited for your changes, login or register a new account)

other page actions:
EasyEclipse

EasyEclipse

EasyEclipse is an Eclipse distribution that packages together the Eclipse IDE and selected open source plugins targeted at various kinds of development. It is intended to make Eclipse easier to download, install, and use. Versions are available for Java (for desktop development, server side development, and mobile development), LAMP (Perl, Python, PHP), Ruby and Rails, C, C++ and for developing plug-ins for Eclipse itself (Plugin Warrior).

The latest release 1.3 is based on Eclipse 3.3 Europa.

easyeclipse.org
EasyEclipse project team

sorted by: recent | see : popular
Content Tagged EasyEclipse

Dave Carver: Automated SDK JavaDoc Documentation Part Deux

A little touch of XSLT magik

In a prior posting, I talked about the pain point of creating SDK JavaDoc Help content for eclipse. It tends to get out of synch with the actual documentation, as the TOC.xml has to be maintained manually. I found a DocLet called JELDoclet that creates one or more XML files for the javadoc. With this created, one can do a little bit of XSLT to do the following:
  1. Create the HTML documentation for the class and package files, that are normally produced by the standard javadoc.
  2. Create the necessary Toc.xml file, that is used by the eclipse help system.
To integrate the help nicely into eclipse, it is usually handy to have everything grouped by Package, and then the documentation for each class underneath the package it belongs too. All of this information is available from the JEL xml file, but the trick with XSLT 1.0, is that it doesn't have a grouping statement. Why not just use XSLT 2.0? The main reason is that the base XSLT parser that comes with Java 1.5 JDK is Xalan based. Sun repackaged and only included portions of the full Xalan, mainly they use the XSLTC compiler/interpreter from Xalan. Anyways, I wanted to keep this to the lowest common denominator.

Since XSLT 1.0 doesn't include a group-by statement, and the Meunchian Grouping method can be confusing, I found this little piece of EXSLT magik by Oleg Tkachenko. Basically the code simulates a group-by clause. Here is the xslt that generates the toc.xml from the JEL xml file:


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:set="http://exslt.org/sets"
xmlns:xalan="http://xml.apache.org/xalan"
exclude-result-prefixes="set"
>
<xsl:param name="sdkname">Some Name</xsl:param>
<xsl:param name="dir">doc/html</xsl:param>
<xsl:output indent="yes" encoding="UTF-8" xalan:indent-amount="3"/>
<xsl:key name="allPackages" match="jelclass" use="@package"/>

<xsl:template match="/jel">
<toc label="{$sdkname}">
<topic label="Reference">
<xsl:for-each select="set:distinct(jelclass/@package)">
<topic label="{.}">
<xsl:apply-templates select="key('allPackages', .)"/>
</topic>
</xsl:for-each>
</topic>
</toc>
</xsl:template>

<xsl:template match="jelclass">
<topic label="{@fulltype}" href="{$dir}/{@fulltype}.html"/>
</xsl:template>

</xsl:stylesheet>


Basically, the code reads the JEL xml file that contains all the java classes and their documentation, and groups all the packages together, it then processes each package and creates the necessary topic entries for each class in the toc.xml file.

The above xslt runs on Xalan, and should run on the Sun version of Xalan as well. The javadoc doclet steps, the html generation, and the toc.xml generation steps can be included in an Ant build script. This allows for the SDK JavaDoc Documentation to be generated automatically everytime a build is done. If a new class or package is included, that new class and it's corresponding documentation will be included as well. The same options that you have for the standard javadoc, are available with the jeldoclet, so you have the same level of control on what gets included and what doesn't.

No More Excuse for Outdated Documentation

[pulls out the soapbox]

Bug 231472 contains most of the work, except for the xslt above, but I'll get that added in a few days. As committers, it's our responsibility to the community to make sure they have the appropriate documentation. Not only so that they know how to use the classes we have created, but also for those people that need to come behind us and maintain the code that we provide. A couple of additional items that would be nice to do (PDE adds some checks to do some of these).
  1. Make sure all your classes both internal and public API have appropriate javadoc documentation.
  2. Automate the generation and upkeep of that documentation.
  3. Follow the JavaDoc best practices (Something that we in the XSL Tools project need to correct).
  4. Run the JavaDoc DocCheck doclet against your java source. It will provide a nice report telling you what is missing in the way of javadoc documentation.
I know that we are all busy, and writing documentation isn't the thing we enjoy doing, but it makes the user communities job easier. I personally don't believe that JavaDoc is something that the user community should write. It's something that we need to make sure we do consistently. We need to make sure that we make the time to do what is right for the community as a whole.

EasyEclipse: Planet Eclipse

Chris Aniszczyk: Eclipse BugDay is Friday

It's that time of month again... it's Eclipse BugDay this Friday. Here are bugs I find interesting from PDE:

[220109] - [refactoring] Add a PDEDeleteParticipant
[233682] - open extension point by double clicking in the manifest editor
[184084] - [refactoring] Renaming an .exsd file should cause plugin.xml to be updated
[241505] - New Library Plug-in wizard should allow to set a BREE
[240597] - Refactor site.xsl for easier maintenance

Also, this BugDay marks a year since the program was started at Eclipse.

Was it a good idea? Was it successful? I don't know, but I do know from a bugzilla query that over 200 bugs have been fixed as a result of bugday. That's not too bad :)

In the end, it's been fun working with new contributors inside of PDE and other projects, thanks for participating!

EasyEclipse: Planet Eclipse

EclipseLive: JavaScript Development Toolkit (JSDT) Features

Bradley Childs (IBM)
 
Abstract:

Bradley Childs introduces the new JavaScript Development Toolkit in Webtools 3.0. This presentation covers the 7 JSDT features and preferences.

Total running time 08:23 minutes


delicious delicious | digg digg | dzone dzone

EasyEclipse: Planet Eclipse

Chris Aniszczyk: Tip: Internationalization and RCP

I had to help someone internationalize their RCP application today and I didn’t really have a straight forward simple example to point them to so I figure I’d share something here for everyone’s benefit. I’ll use the famous RCP mail example to get things started. The first step in internalization is making sure our strings are externalized so translators can actually do something with them. For Eclipse plug-ins, there will be two places you need to externalize strings:

  • Java artifacts (ie., .java)
  • Plug-in related artifacts (MANIFEST.MF and plugin.xml)

Within Java files, the wonderful JDT tooling provides an Externalize Strings wizard (Source->Externalize Strings…):

Within plug-in artifacts, PDE also provides an Externalize Strings wizard (PDE Tools->Externalize Strings or click the hyperlink on the Overview page):

Once we have all our strings externalized, we need to create a fragment (e.g., org.eclipse.mail.nl1) to store our translations (File->New->Fragment Project):

From the screenshot above, you should see that the translated properties files are co-located in the same respective location of the original file. The translated properties files also have a naming convention of name_locale.properties (e.g., messages_es.properties).

So now that we have some translated properties file, how do we test our translations? PDE provides an easy way to set the locale you’re developing against… similar to the way you define a target platform. In the target platform preference page, head over to the Environment tab and choose the language you’re interested in:

Once you do that, simply launch like you normally would to test out the fancy translations:

That’s it! Also, if you need translations for Eclipse.org plug-ins… check out the Babel project!

Here is the code used in this tip if you need to take a test drive at home. Hope this helps.

EasyEclipse: Planet Eclipse

EclipseLive: DSF-GDB Debugger

Pawel Piech (Wind River)
 
Abstract:

This demonstration presents the unique features of the GDB debugger integration developed by the Device Debugging project. This debugger uses DSF which is the next generation debugger framework for C/C++ debugging.

Total running time 05:37 minutes


delicious delicious | digg digg | dzone dzone

EasyEclipse: Planet Eclipse

Denis & Karl: Community vs. Quality

At Babel we're trying to solve the Localization of Eclipse problem with a community approach, where anyone can help translate Eclipse. However, a recurring concern (shared amongst commercial entities) is the quality of the translations, as they are not being done by professional translators.

As I was casually testing a new Babel feature, I stumbled upon this message, in English, that I was attempting to translate to French:
The Bundle-NativeCode file {0} could not be not found
An innocent mistake, really, but considering this has been in CVS for almost 2 1/2 years, I began wondering why the professional translators haven't spotted this. Or perhaps even worse, the pros simply translated the string as per their requirement and didn't bother to go the extra mile to have this fixed. I did.

So there we have it... Babel is enabling community-driven translations, and we're make the English version of Eclipse even better in the process.

EasyEclipse: Planet Eclipse

Doug Schaefer: Who's leading anyway?

The LinuxHater linked off to Christopher Blizzard's (from OLPC fame and now at Mozilla) blog on the current state of affairs with the GNOME project. He gives some very eye opening insight into what's happening there and the potential future directions for GNOME, GTK, and friends. It's not pretty, literally.

GNOME is getting big in the mobile space, or at least the number of contributors from that space is starting to dominate the GNOME project. And as we all know in the open source world, the contributors are the leaders and get to make the decisions. What this likely means and what blizzard is afraid of is that the GNOME desktop is not going to get the attention it needs to compete with the modern interfaces it competes with. The commercial interest just isn't there to make it happen like it is with GNOME mobile.

He explicitly spells out Qt and Apple as leaders in making good user experiences and developer friendly APIs. My favorite quote of his: "If in a platform-driven market and a platform-driven world you’re not the #1 or #2 player it’s going to be very difficult to make a dent in the market. (This is especially true if Nokia decides to fix the Qt licensing.)" I agree on both fronts. I can't see how GNOME is going to grow without serious innovation. And I hope that Nokia fixes the Qt licensing (wink, wink, nudge, nudge).

Being CDTDoug and focused on embedded and mobile at Wind River and on the success of CDT for Windows development with Wascana, why do I care so much about the Linux desktop? Well I think it's the missing piece in the open source success story. We have Linux as an overwhelming favorite in the server market and it's growing in great strides in the embedded space. But without success on the desktop, my Mom isn't going to care. Which means Microsoft and Apple and closed source technologies as still seen as the right path to innovation by the general public. And until "I am a Mac" dukes it out with "I am a Linux PC", there will always be doubts on whether open source can compete with the big boys.

EasyEclipse: Planet Eclipse

Elias Volanakis: Showing different images for expanded / collapsed nodes of a JFace TreeViewer

Did you ever want a JFace TreeViewer that shows different icons depending on the expanded / collapsed state of a node? The animation below shows what I mean:

Different images are shown in the tree, depending on the state of each node:

     — collapsed node
     — expanded node
     — leaf node

So here is what you need to do:
  1. Create a LabelProvider that returns different images based on the expanded state of an element:
    class NodeLabelProvider extends LabelProvider {   
      // ...
      public Image getImage(Object element) {
        Image result = LEAF;
        Node node = (Node) element;
        if (node.hasChildren()) {
          result = viewer.getExpandedState(node) ? NODE_EXPANDED : NODE_COLLAPSED;
        }
        return result;
      }
    }

  2. Create a TreeListener to update the image when the users clicks on the plus or minus icon in the tree:
    class UpdateIconTreeListener implements TreeListener {

      public void treeCollapsed(TreeEvent e) {
        updateImage((TreeItem) e.item, true);
      }

      public void treeExpanded(TreeEvent e) {
        updateImage((TreeItem) e.item, false);
      }

      private void updateImage(TreeItem item, boolean isCollapsed) {
        Image image = isCollapsed ? NODE_COLLAPSED : NODE_EXPANDED;
        item.setImage(image);
      }

    }

  3. Tree elements can be expanded/collapsed via Java code by calling methods such as viewer.expandToLevel(Object, int) and viewer.collapseToLevel(Object, int). Remember to manually trigger an update of the element's label (i.e. the image and text) in those cases:
      viewer.expandToLevel(node, 1);
      viewer.update(node, null);

Download the example project.

Happy hacking,
Elias.

EasyEclipse: Planet Eclipse

Bjorn Freeman-Benson: Invite a Friend to EclipseCon

We're already thinking about EclipseCon 2009 and one of the things we're thinking about is referral rewards. If you, a registered attendee, convince others to register, we'd like to offer some token of our thanks. We're looking for ideas and suggestions...

(please add your suggestions to bug 241611)

EasyEclipse: Planet Eclipse

Darin Swanson: Twitter Search

I have started to really like Twitter. But not in the "classic" sense but rather using Twitter Search. Twitter Search is something I have only recently really started to use but it allows me to attempt to keep up with real time events.

Twitter Search (the old Summize.com that got acquired and rolled into Twitter as Twitter Search) allows you to easily follow all the tweets that are occurring around a given topic. Without having to know which individuals to follow. Interesting content without much work. This is why I like it :-)

Today I am following the OSCON tweets...and can barely keep up with about 20 updates a minute. But it is worthwhile as it has pointed me to interesting content.
Twitter Search lets you know when there are new results (on the page and in the browser tab).
It also has the feature to expand tinyurl.com entries so you can actually see the URL before going to it. I hope they add this feature to the classic Twitter tweet entry. I like to at least have an idea of where I am going before I get there :-)

I hope this helps someone else work smarter...

EasyEclipse: Planet Eclipse

Doug Gaff: Virus (Scanner) Infestations

Returning to the two recent themes of bloated software and fixing broken computers, I spent this weekend with my in-laws for a family reunion. Unfortunately for me, visits to family members almost always include family computer maintenance. On tap this time was the usual problem: "my computer is running slowly". But in this case, the problem wasn't spyware. The computer in question is a P4 1.6 GHz with 256 MB of memory running XP. Not smoking by today's standards, but certainly capable of running XP and one additional app as long as the background crapware is kept to a minimum. My father-in-law runs a small business, and he's been using the same apps for several years to keep the books and manage his customer interactions.

In this case, the background crapware was the virus scanner. This machine was running a fairly recent version of Norton Internet Security. Norton Antivirus was on the computer when it was purchased several years ago, and at the time, the version running was commensurate with the resources and capabilities of the system. But software never gets smaller and faster, does it? It only gets slower and more bloated, and that's what's been happening to the Norton products for years.

So why did my father-in-law upgrade to a newer version? Because the software told him to. Virus and spyware scanners are notorious for dire warnings to ill-informed and fear-stricken users that they have to upgrade to the latest version in order to be "fully" protected. "You're one click away from having your identity stolen!" I'm not talking about keeping virus definitions up-to-date (always important). I'm talking about full upgrades of the software to get all of the latest "features". In the case of Norton, the task of virus/spyware scanning has morphed into an entire suite of products that plug into everything you do. This means more background processes, more memory consumed, and more strain on system resources…or on my father-in-law's computer: massive hard-drive thrashing.

This is an out-of-box experience problem. Norton (and other software packages like it) should check the current system specifications before suggesting a massive upgrade. A simple message like, "you really need more memory and a faster hard drive before you upgrade to this new version," would really be welcomed. An even a better solution would be to write better software. Just because computers have more cores, more speed, more memory, and faster and bigger hard drives doesn't mean software should expand to fit. The entire software industry, Eclipse included, needs to take a step back and take a hard look at this problem.

I really feel for computer users like my father-in-law. Outside of my "geek circle", everyone else I know is in the same user category as he is. They need us to make life easier for them. My advice to the fear-stricken: keep Windows and your browser up to date, install AVG Free instead of Norton or anything else, use Firefox with the NoScript add-on, and then use some common sense when browsing the web and reading emails.

P.S. If you find yourself in this situation with Norton, be warned that there are compatibility problems between Norton Internet Security Suite and XP SP3. In our case, internet browsing stopped working completely. Norton's uninstall was not successful removing all of the Norton stuff, and the only thing that saved the day is a nice removal utility on Symantec's website that appears to properly clean up everything. I was mere moments away from losing another entire day with a system reinstall.


tags: norton, avg, firefox, noscript, xp sp3, software bloat


EasyEclipse: Planet Eclipse

Brian Fitzpatrick: Ever wonder how to get a Database from a Connection Profile?

Hi all!

Have you ever wondered how to get a DTP SQL Model Database object from a connected connection profile? I seem to run into this problem infrequently, but always have to go through many gyrations to find the answer.

Larry from IBM, another member of the Connectivity team, was kind enough to provide the answer. It resulted in this chunk of code:

public Database getDatabaseForProfile (IConnectionProfile profile) {
IManagedConnection managedConnection = ((IConnectionProfile)profile).
getManagedConnection("org.eclipse.datatools.connectivity.sqm.core.connection.ConnectionInfo");

if (managedConnection != null) {
try {
ConnectionInfo connectionInfo = (ConnectionInfo) managedConnection.
getConnection().getRawConnection();
if (connectionInfo != null) {
return connectionInfo.getSharedDatabase();
}
} catch (Exception e) {
e.printStackTrace();
}
}
return null;
}

(Sorry the code's not pretty. I haven't found a great way of including code in Blogger blog posts yet.)

Basically under the covers there is a ConnectionInfo connection adapter that is used to map between the java.sql.Connection object we get from JDBC and the SQL model that's populated via the catalog loaders.

So there you have it! Not that many people have a need for such a thing, but it's handy just in case!

--Fitz

EasyEclipse: Planet Eclipse

Nathan Gervais: 1 Million Downloads!

Recently I've been working on the Packaging site to update its download counts to be more accurate. I'm proud to say mission accomplished!



The most exciting part of all this is over the past weekend we broke 1 Million Downloads of Ganymede. To be precise the total download count (as of this morning) for all the Packages + The Eclipse Classic Download is 1,168,432

Congratulations, and job well done to the entire Eclipse Community!

*Edit* Apparently my calculator skills failed. Download Count updated!

EasyEclipse: Planet Eclipse

Peter Friese: Call for Papers / Participation: MDSD Today 08

From October 15th - 17th, the second workshop on model driven software development "MDSD Today" will take place in Elmshorn near Hamburg, Germany.

The goal of this conference is to provide a platform for professionals (managers, architects and engineers alike) in the field of model driven software development to meet and exchange ideas.

The three day will be organized into the following major blocks:

  1. Management Day
  2. Research Papers and Industrial Reports
  3. MDSD Tutorials

The management day will feature keynotes by Dr. Axel Uhl (Chief Development Architect with SAP) and Ed Merks (of Eclipse Modeling fame).

Tutorials on various MDSD-related topics (such as model-to-model transformations, model-to-text transformations, external textual DSLs) will be delivered by members of the Eclipse Modeling Project on day 2 and day 3 of the conference.

If you use model driven software development in your daily work, please consider giving a presentation.

If you do not use MDSD and would like to hear about other's experiences, you should consider participating in the conference and take the chance to attend the MDSD tutorials. At EUR 350 for three days, that's a real bargain.

The CfPs and more information on the conference can be found here (english) and here (german).

Hope to see you there!

EasyEclipse: Planet Eclipse

Aleksey Aristov: OSGi running on Amazon EC2

Server side OSGi applications now can also be easily deployed on computing clouds implemented by Amazon (EC2). With several mouse clicks your exported bundles can be uploaded to remote storage (S3) and added to profile (Launch Configuration). Now virtual servers (EC2 instances) containing OSGi framework provisioned with selected bundles can easily be started.

OSGi on EC2 video presentation

For those who do not know what EC2 is: it is a very cool service coming from Amazon. It allows users to start virtual servers within it's "Elastic Compute Cloud". Compared to traditional server hosting, Compute Cloud allows you to scale your capacity according to your demands. By running servers in the cloud, you can avoid initial expenses of buying new hardware and such. Another attractive feature - you do not have to sign up for any long term contracts (which is usually almost always the case in Germany).

Amazon will charge you on "pay for what you use" basis. Their current prices start from 10 cents per instance hour plus some additional traffic fees.

In my opinion, this is a very good option to host Java based services. What makes it even better option is that hosting services with high quality Java support are usually expensive hard to find.

EasyEclipse: Planet Eclipse

Dave Carver: Automated SDK JavaDoc Documentation

One of the pain points with working with eclipse, is generating the SDK documentation (bug 231472). Typically this is done by using the standard javadoc command, and outputting HTML files. The toc.xml files, then need to be updated manually to link to the appropriate HTML files. However, sometimes this doesn't integrate well with how the other documentation is integrated into eclipse. Mainly because the linking is done to the Frames content of the javadoc file, and it just looks messy.

The reason some plugins do this, is that hundreds if not thousands of individual javadoc html files can be generated. What is needed is some way to get this information into a format that can be used to generate automatically the toc.xml file, and any supporting html files in one or two steps.. After searching around for a while, I think I have a possible solution. There is a little known doclet hiding on sourceforge called JELDoclet. It generates an XML file from the javadoc.


<jelclass superclass="NLS" visibility="public" superclassfulltype="NLS" fulltype="org.eclipse.wst.xsl.core.internal.Messages" type="Messages" package="org.eclipse.wst.xsl.core.internal">
<comment>
<attribute name="@author">
<description>Jesper Steen</description>
</attribute>
</comment>
<fields>
<field visibility="public" fulltype="java.lang.String" type="String" name="XSLCorePlugin_parserConfiguration" static="true">
<comment>
<description>TODO: Add JavaDoc</description>
</comment>
</field>
<field visibility="public" fulltype="java.lang.String" type="String" name="XSLCorePlugin_badInitializationData" static="true">
<comment>
<description>TODO: Add JavaDoc</description>
</comment>
</field>
<field visibility="public" fulltype="java.lang.String" type="String" name="XSLCorePlugin_coreError" static="true">
<comment>
<description>TODO: Add JavaDoc</description>
</comment>
</field>
</fields>
<methods>
<constructor visibility="public" name="Messages" />
<method visibility="public" fulltype="void" type="void" name="reloadMessages" static="true">
<comment>
<description>TODO: Add JavaDoc</description>
</comment>
</method>
</methods>
</jelclass>


The easiest way to generate this file is with an ANT script using the javadoc task:


<javadoc destdir="doc" package="true" docletpath="${workspace}/lib/jeldoclet.jar">
<fileset dir="${workspaceloc}/org.eclipse.wst.xsl.core/src">
<include name="**/*.java"/>
</fileset>
<doclet name="com.jeldoclet.JELDoclet" />
</javadoc>


JELDoclet has options to generate a single XML file that contains everything (ideal if you are creating docbook or dita files). Or it has the ability to generate single xml files for each class (ideal for generating html files from xml). Either way, by having an XML representation of the JavaDoc one can manipulate and start to automate the process of generating the appropriate toc.xml file for eclipse documentation.

Ideally, one could convert the XML file to Docbook and then run it through the eclipse.xsl file to generate the appropriate plugin with corresponding indexed HTML and toc.xml created. If this was included in a feature build for an SDK plugin, then there would be no reason for the SDK documentation to be out of date with the HTML documentation. It provides a fairly simple method for keeping the two in synch. It doesn't levitate the need for the committers to make sure that the javadoc documentation itself is accurate, or even if everything is documented. To do the latter, one would need to run the doclet DocCheck across the code.

So feel free to voice your opinion on bug 231472, if you agree with this approach or have another way to make sure that the sdk javadoc documentation is easy to create.

EasyEclipse: Planet Eclipse

Page 1 | Next >>
Username:
Password:
(or Cancel)