Explore Git Internals with the JGit API

by Rüdiger Herrmann at October 20, 2014 09:05 AM

Written by Rüdiger Herrmann

Have you ever wondered how a commit and its content is stored in Git? Well, I have, and I had some spare time over the last rainy weekend, so I did a little research.

Because I feel more at home with Java than with Bash, I used JGit and a couple of learning tests to explore the Git internals of commits. Here are my findings:

Git – an Object Database

Git at the core is a simple content-addressable data store. This means that you can insert any kind of content into it and it will return a key that you can use to retrieve the data again at a later point in time.

In the case of Git, the key is the 20 byte SHA-1 hash that is computed from the content. The content is also referred to as an object in Git terminology and consequently the data store is also called an object database.

Let’s see how JGit can be used to store and retrieve content.

Blobs

In JGit, the ObjectInserter is used to store content into the object database. It can be seen as the rough equivalent to git hash-object in Git.

With its insert() method you can write an object to the data store whereas its idFor() methods only compute the SHA-1 hash of the given bytes. Hence the code to store a string looks like this:

ObjectInserter objectInserter = repository.newObjectInserter();
byte[] bytes = "Hello World!".getBytes( "utf-8" );
ObjectId blobId = objectInserter.insert( Constants.OBJ_BLOB, bytes );
objectInserter.flush();

All code examples assume that the repository varaible points to an empty repository that was created outside of the snippet.

The first parameter denotes the object type of the object to be inserted, a blob type in this case. There are further object types as we will learn later. The blob type is used to store arbitrary content.

The payload must be given in the second parameter, as a byte array in this case. An overloaded method that accepts an InputStream is also available.

And finally, the ObjectInserter needs to be flushed to make the changes visible to others accessing the repository.

The insert() method returns the SHA-1 hash that is computed from the type, the content length and the content bytes. In JGit, though, a SHA-1 hash is represented through the ObjectId class, an immutable data structure that can be converted to and from bytes, ints, and strings.

Now you can use the returned blobId to retrieve the content back and thus ensure that the above code actually wrote the content.

ObjectReader objectReader = repository.newObjectReader();
ObjectLoader objectLoader = objectReader.open( blobId );
int type = objectLoader.getType(); // Constants.OBJ_BLOB
byte[] bytes = objectLoader.getBytes();
String helloWorld = new String( bytes, "utf-8" ) // Hello World!

The ObjectReader’s open() method returns an ObjectLoader that can be used to access the object identified by the given object ID. With the help of an ObjectLoader you can get an object’s type, its size and of course its content as a byte array or stream.

To verify that the object written by JGit is compatible with native Git you can retrieve its content with git cat-file.

$ git cat-file -p c57eff55ebc0c54973903af5f72bac72762cf4f4
Hello World!
git cat-file -t c57eff55ebc0c54973903af5f72bac72762cf4f4
blob

If you look inside the .git/objects directory of the repository, you’ll find a directory named ‘c5′ with a file named ‘7eff55ebc0c54973903af5f72bac72762cf4f4′ in it. This is how the content is stored initially: as a single file per object, named with the SHA-1 hash of the content. The subdirectory is named with the first two characters of the SHA-1 and the filename consists of the remaining characters.

Now that you can store the content of a file, the next step is to store its name. And probably also more than just one file, since a commit usually consists of a group of files. To hold this kind of information, Git uses so called tree objects.

Tree Objects

A tree object can be seen as a simplified file system structure that contains information about files and directories.

It contains any number of tree entries. Each entry has a path name, a file mode and points to either the content of a file (a blob object) or another (sub) tree object if it represents a directory. The pointer of course is a SHA-1 hash of either the blob object or the tree object.

To start with, you can create a tree that holds a single entry for a file named ‘hello-world.txt’ that points to the above stored ‘Hello World!’ content.

TreeFormatter treeFormatter = new TreeFormatter();
treeFormatter.append( "hello-world.txt", FileMode.REGULAR_FILE, blobId );
ObjectId treeId = objectInserter.insert( treeFormatter );
objectInserter.flush();

The TreeFormatter is used here to construct an in-memory tree object. By calling append() an entry is added with the given path name, mode and the ID under which its content is stored.

Fundamentally, you are free to chose any path name. However, Git expects the path name to be relative to the working directory without a leading ‘/’.

The file mode used here indicates a normal file. Other modes are EXECUTABLE_FILE, which means it’s an executable file, and SYMLINK, which specifies a symbolic link. For directory entries, the file mode is always TREE.

Again, you will need an ObjectInserter. One of its overloaded insert() methods accepts a TreeFormatter and writes it to the object database.

You can now use a TreeWalk to retrieve and examine the tree object:

TreeWalk treeWalk = new TreeWalk( repository );
treeWalk.addTree( treeId );
treeWalk.next();
String filename = treeWalk.getPathString(); // hello-world.txt

Actually, a TreeWalk is meant to iterate over the added trees and their subtrees. But since we know that there is exactly one entry, a single call to next() is sufficient.

If you look at the just written tree object with native Git you will see the following

$ git cat-file -p 44d52a975c793e5a4115e315b8d89369e2919e51
100644 blob c57eff55ebc0c54973903af5f72bac72762cf4f4    hello-world.txt

Now that you have the necessary ingredients for a commit, let’s create the commit object itself.

Commit Objects

A commit object references the files (through the tree object) that constitute the commit along with some meta data. In detail a commit consists of:

  • a pointer to the tree object
  • pointers to zero or more parent commits (more on that later)
  • a commit message
  • and an author and committer

Since a commit object is just another object in the object database, it is also sealed with the SHA-1 hash that was computed over its content.

To form a commit object, JGit offers the CommitBuilder utility class.

CommitBuilder commitBuilder = new CommitBuilder();
commitBuilder.setTreeId( treeId );
commitBuilder.setMessage( "My first commit!" );
PersonIdent person = new PersonIdent( "me", "me@example.com" );
commitBuilder.setAuthor( person );
commitBuilder.setCommitter( person );
ObjectInserter objectInserter = repository.newObjectInserter();
ObjectId commitId = objectInserter.insert( commitBuilder );
objectInserter.flush();

Using it is straightforward, it has setter methods for all the attributes of a commit.

The author and committer are represented through the PersonIdent class which holds the name, email, timestamp and time zone. The constructor used here applies the given name and email and takes the current time and time zone.

And the rest should be familiar already: an ObjectInserter is used to actually write the commit object and returns the commit ID.

To retrieve the commit object from the repository, you can again use the ObjectReader:

ObjectReader objectReader = repository.newObjectReader();
ObjectLoader objectLoader = objectReader.open( commitId );
RevCommit commit = RevCommit.parse( objectLoader.getBytes() );

The resulting RevCommit represents a commit with the same attributes that were specified in the CommitBuilder.

And once again – to double-check – the output of git cat-file:

$ git cat-file -p 783341299c95ddda51e6b2393c16deaf0c92d5a0
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author me <me@example.com> 1412872859 +0200
committer me <me@example.com> 1412872859 +0200

My first commit!

Parents

The chain of parents form the history of a Git repository and model a directed acyclic graph. This means that the commits ‘follow’ one direction

A commit can have zero or more parents. The first commit in a repository does not have a parent (aka root commit). The second commit in turn has the first as its parent, and so on.

It is perfectly legal to create more than one root commit. If you use git checkout --orphan new_branch a new orphan branch will be created and switched to. The first commit made on this branch will have no parents and will form the root of a new history that is disconnected from all other commits.

Git Internals: Merge Commit
If you start branching and eventually merge the divergent lines of changes, this usually results in a merge commit. And such a commit has the head commits of the divergent branches as its parents.

In order to construct a parented commit, the ID of the parent commit needs to be specified in the CommitBuilder.

commitBuilder.setParents( parentId );

A RevCommit class, which represents a commit within the repository, can also be queried about its parents. Its getParents() and getParent(int) methods return all or the nth parent RevCommit.

Be warned however, that though the methods return RevCommits these are not fully resolved. While their ID attribute is set, all other attributes (fullMessage, author, committer, etc.) are not. Thus, an attempt to call parent.getFullMessage() for example will throw a NullPointerException. In order to actually use the parent commit you need to either retrieve a full RevCommit by means of the ObjectReader like outlined above or use a RevWalk to load and parse the commit header:

RevWalk revWalk = new RevWalk( repository );
revWalk.parseHeaders( parentCommit );

All in all, keep in mind to treat the returned parent commits as if they were ObjectIds instead of RevCommits.

More on Tree Objects

If you are to store files in sub-directories you need to construct the sub-trees yourself. Say you want to store the content of a file ‘file.txt’ in folder ‘folder’.

First, create and store a TreeFormatter for the subtree, the one that has an entry for the file:

TreeFormatter subtreeFormatter = new TreeFormatter();
subtreeFormatter.append( "file.txt", FileMode.REGULAR_FILE, blobId );
ObjectId subtreeId = objectInserter.insert( subtreeFormatter );

And then, create and store a TreeFormatter with an entry that denotes the folder and points to the just created subtree.

TreeFormatter treeFormatter = new TreeFormatter();
treeFormatter.append( "folder", FileMode.TREE, subtreeId );
ObjectId treeId = objectInserter.insert( treeFormatter );

Git Internals: Tree Object
The file mode of the entry is TREE to indicate a directory and its ID points to the subtree that holds the file-entry. The returned treeId is the one that would be passed to the CommitBuilder.

Git requires a certain sort order for entries in tree objects. The ‘Git Data Formats’ document that I found here states that

Tree entries are sorted by the byte sequence that comprises the entry name. However, for the purposes of the sort comparison, entries for tree objects are compared as if the entry name byte sequence has a trailing ASCII ‘/’ (0x2f).

To read the contents of the tree object you can again use a TreeWalk. But this time, you need to tell it to recurse into subtrees if you which to visit all entries. And also, don’t forget to set the postOrderTraversal to true if you whish to see entries that point to a tree. They would be skipped otherwise.

The whole TreeWalk loop will look like this in the end:

TreeWalk treeWalk = new TreeWalk( repository );
treeWalk.addTree( treeId );
treeWalk.setRecursive( true );
treeWalk.setPostOrderTraversal( true );
while( treeWalk.next() ) {
  int fileMode = Integer.parseInt( treeWalk.getFileMode( 0 ).toString() );
  String objectId = treeWalk.getObjectId( 0 ).name();
  String path = treeWalk.getPathString();
  System.out.println( String.format( "%06d %s %s", fileMode, objectId, path ) );
}

…and will lead to this output:

100644 6b584e8ece562ebffc15d38808cd6b98fc3d97ea folder/file.txt 
040000 541550ddcf8a29bcd80b0800a142a7d47890cfd6 folder 

Although I find the API not very intuitive it gets the job done and reveals all the details of the tree object.

Concluding Git Internals

No doubt, that for common use cases the high-level Add- and CommitCommands are the recommended way to commit files to the repository. Still, I found it worthwhile digging in to the deeper levels of JGit and Git and hope you did so, too. And in the – admittedly less common – case that you need to commit files to a repository without a working directory and/or index, the information provided here might help.

If you like to try out the examples listed here for yourself, I recommend to setup JGit with access to its sources and JavaDoc so that you have meaningful context information, content assist, debug-sources, etc.

The complete source code is hosted here:
https://gist.github.com/rherrmann/02d8d4fe81bb60d9049e

For brevity, the samples shown here omit the code to release allocated resources. Please refer to the complete source code to get all the details.

The post Explore Git Internals with the JGit API appeared first on Code Affine.


by Rüdiger Herrmann at October 20, 2014 09:05 AM

Eclipse Icons for your Presentations

by Jérémie Bresson at October 20, 2014 05:55 AM

I am giving a lot of trainings lately. Some of them are for our co-workers at BSI (topics around Java and Eclipse). And some of them for external clients, mostly related to the Eclipse Scout framework.

For these trainings, I often have to prepare slides on short notice. As an example, the slide below explains the location of the tests in an Eclipse Scout RT project:

Where are the tests?

Frequently, a lot of icons representing the Eclipse IDE elements are needed in such slides. Unfortunately the icons of the IDE itself are too small (16×16 pixels) to be used on the slides, but luckily I found this page (UI Graphics > Design > Common Elements > Wizard elements) on the Eclipse wiki. This page also contains an Adobe Illustrator file including the wizard Icons. And those icons are exactly what I needed for my slides. From this Illustrator file, I could extract all icons with or without background and save them into individual files for both PNG and SVG formats.

Wizard icons

I checked with the Eclipse Foundation and got an answer from Mike Milinkovich: the icons I have created are licensed under EPL because they are a derivated work of the original file.

Hoping that this exercise may be useful to others, I have made my code and approach available on GitHub: common_wizard_elements (or just download the common_wizard_elements.zip to get the SVG and PNG files).

Disclaimer: I am not a graphic designer and I have limited knowledge of the SVG file format. Feel free to give me feedback (as comment on this blog or on the GitHub project).

And just in case: should you be interested in Eclipse Scout trainings, please let us know.

Scout Links

Project Home, Forum, Wiki, Twitter


by Jérémie Bresson at October 20, 2014 05:55 AM

openHAB and Eclipse SmartHome News Flash

by Kai Kreuzer (noreply@blogger.com) at October 19, 2014 12:32 PM

JavaOne and the Valley

Having spent a few days in the Silicon Valley, I feel it is time to share some experiences. The main reason for the my trip was the talk about Smart Homes for the Masses at JavaOne in San Francisco. This was well attended and we had brought a lot of toys with us to do a live demo of Eclipse SmartHome and QIVICON. There were other good talks about home gateways like the one from ProSyt about OSGi on gateways or from Eurotech about the Eclipse Kura project.

Thanks to the Eclipse Foundation, we also had two slots at the Eclipse booth in the exhibition hall to demonstrate Eclipse SmartHome and talk to people about it. Ian Skerrett even did an impromptu video recording of our demo setup.

Besides the very professionally organized conference by Oracle, it is always remarkable, how the "normal" life of IT geeks look like in the valley. I had the chance to present the Eclipse SmartHome based openHAB project at a local MeetUp in Oakland, hosted by ACE Monster Toys. Behind the rather uninviting entrance in an industrial area, there are great tools for the startups of tomorrow: huge CNC-machines, lots of sewing machines, powerful laser cutters etc. Entrepreneurs from all over the valley meet here to discuss latest technologies - such as openHAB in this case! On this occasion, I was given one of the new GE LED light bulbs, which are with less than $15 incredibly cheap in comparison to any other radio controlled light bulb on the market. And what is cool about it: It can be linked to the Philips Hue bridge and is now fully supported by the Eclipse SmartHome Hue binding!


At this MeetUp, I also had the pleasure to meet the creator of the STACK Box, a recently funded Kickstarter project. I really like the concepts this project is following as they are very much in-line with the idea of openHAB: Having an open and extensible software stack for a home gateway that serves as an integration point while protecting the users privacy. Did I actually already mention that I consider myself a home gateway junkie? Over the years I have collected an impressive compilation - and yet I am still missing popular gateways like the SmartThings hub, the Revolv hub, the Ninja Sphere or the Wink hub...

On October 3rd, I was invited to the TWiT studios in Petaluma for an interview - they have a special FLOSS channel and usually broadcast live - as I couldn't arrange the usual time, they made an exception for me and did a pre-recording. Their studio is amazing and they have a very professional crew - well, see the results of the show yourself!

EclipseCon Europe is coming!

Shortly after JavaOne, we had reached an important milestone for Eclipse SmartHome - the very initial release has been published - Eclipse SmartHome 0.7.0! A main feature of it over the initial code base from openHAB is the support of discovery mechanisms for bindings. The first developers are now actively trying this out and thus I am thrilled to already see support for Philips Hue, Yahoo Weather, Sonos, LIFX, Belkin Wemo, MAX!Cube, KNX, IRTrans and others being developed! I will soon do a blog post that shows this in action and should give you a good idea of how solutions that are built on Eclipse SmartHome can look like - so stay tuned!

If you are close to Ludwigsburg end of October, a good chance to see the first results is at my talk at EclipseCon Europe, which I am doing together with my colleague Jochen Hiller from Deutsche Telekom. You can also learn how to implement a binding yourself in 15 minutes or get your hands dirty at the IoT playground. If you are interested in the Eclipse IoT space in general and would like to meet the different people involved in it, the Unconference that is held on Monday, Oct 27th, is a good opportunity to do so - hoping to see you there!

by Kai Kreuzer (noreply@blogger.com) at October 19, 2014 12:32 PM

Why Your IoT Product Strategy Needs to Include Open Source

by Ian Skerrett at October 17, 2014 04:43 PM

For the last two years, I have been talking about why open source will be critical to the success of the Internet of Things.  The current state of IoT/M2M is a lot of propriertary platforms and protocols. This can’t last and won’t win in the long term.

This week during a webinar about the new Vorto IoT project from Bosch, I saw the best illustration of why companies that don’t include open source in their product strategy will eventually fail.  Check out this slide about the Bosch IoT Platform Strategy:

Bosch Product Strategy

 

Bosch is one of the leading industrial companies in the IoT industry. They definitely get it and their analysis of the market is definitely worth considering. Consider each of their assumptions very carefully:

1. 2-5 major IoTS platforms (in next 5-7 years) – At the start of every new technology innovation there are lots of different platforms that are developed. However, overtime the industry consolidates around 2-5 key providers, ex databases, web servers, Java servers, etc.   This will happen in IoT.

2. At least one of them will be Open Source – Open source has proven to be a provider of production quality software. In many markets, open source is the dominant supplier.  There is no reason to believe that this will not be the case in IoT.

3. Bosch not able to develop one of these proprietary platforms alone and customers/partners would not accept it – Developing a proprietary platform takes a LOT of development resources but more importantly a LOT of marketing, sales, and business development resources. Even a company as large as Bosch recognizes this fact. Companies like Google, Apple, IBM, SAP, Oracle, Salesforce, Microsoft plus some others may have the resources and skills to compete but most companies don’t. Most companies will need to identify their key value add for IoT. Providing a platform is not going to be a value add that is sustainable in the long-term.

4. No risk/dependency on proprietary 3rd party platform – Bosch and other companies still need an IoT platform, so they are making a make vs buy decision. If they decide to not Make  (see #3) then the buy decision comes down to a proprietary platform or an open source platform. Considering #2, deciding to go with an open source platform provides a lot more flexibility and less risk of being dependent on another company.

If you are setting a product strategy for an IoT product, you will be faced with a Make vs Buy decision.  I think Bosch makes a pretty compelling case for open source. More importantly, Bosch has decided to be a leader in open source, ensuring they have a significant role and stake in the success.

Reason #2

The other reason open source is going to win is captured in by Matt Asay in his recent article. The answer of course is: Developers.  As Matt points out ‘Developers aren’t going to go for proprietary standards.’  And as Matt points out, developers are attracted to code:

But let’s be clear: None of these companies lining up to join this or that foundation will prove dispositive in cementing any particular standard as theopen source standard. Developers do that.

And developers are attracted by tools and platforms that make them more productive, fast. Getting a marquee list of donors to a foundation is meaningless if the foundation doesn’t generate code that appeals to developers.

This is why what we are doing at Eclipse IoT is so important. We have code, sandbox servers and tutorials to make it easy for developers to get start with IoT.

It is clear code and openness will win in IoT. Join us in creating an amazing IoT open source community.



by Ian Skerrett at October 17, 2014 04:43 PM

Little Known Things about the Eclipse Infocenter: Debugging Information (5/5)

by howlger at October 17, 2014 03:18 PM

This is the last of the five well-hidden features of the Infocenter. The Eclipse Infocenter is the Eclipse help system launched as a web application which can of course also be remotely debugged like any other Java application. But in situations when you cannot easily access the server on which the Infocenter is running you can still get hold of a list of active plug-ins and some help-specific configuration information. Furthermore, you can display any file of an active plug-in. This debugging information, which is similar to the Configuration Details in the About Dialog of your Eclipse IDE, can be accessed not by following a link or by clicking a button but by opening specific URLs.

Infocenter About page

For a table of active plug-ins just open the page about.html. You can sort the rows by clicking on a column header. This list can be used to get the source code of the plug-ins, which is required for a remote debugging session. Or you can check if there are any known security vulnerabilities (e. g. cross-site scripting vulnerability) that need to be fixed by updating the Infocenter. You should use Eclipse 3.8 or newer just to be on the safe side. Two weeks ago I found three pretty old Infocenters with security issues which are certainly not the only ones. I informed the operators but nothing has happened so far. For this reason I even waited until today with publishing this post.

Infocenter About Preferences page

To get help-specific preferences you have to open about.html?show=preferences. But this page shows only the basic help configuration. To get a file such as plugin.xml, toc.xml or META-INF/MANIFEST.MF of a specific plug-in you have to open rtopic/plug.in.id/path/to/file, for example:

This was the final episode of the series on five little known things about the Eclipse Infocenter. I hope that you liked it. How many of the well-hidden features did you already know?

  1. Basic and Bot Mode
  2. Deep Linking
  3. Search Links
  4. Language Switching
  5. Debugging Information

Flattr this



by howlger at October 17, 2014 03:18 PM

EclipseCon Europe /OSGi Community Event

October 17, 2014 06:00 AM

The conference is less than 2 weeks away. Don't miss out, register now!

October 17, 2014 06:00 AM

Open IoT hangout #11 - IPSO Smart Objects

by Eclipse Foundation at October 16, 2014 05:31 PM

Join +Benjamin Cabé and +Ian Skerrett from the Eclipse Foundation and their guest +Michael Koster to learn more about the recently released Smart Objects Starter Pack, and what it means for IoT developers.

by Eclipse Foundation at October 16, 2014 05:31 PM

In 2 weeks EclipseCon Europe 2014 will be over

by Jérémie Bresson at October 16, 2014 03:45 PM

We will be at the EclipseCon Europe 2014 in two weeks.

Come and meet us at booth #10:
ECE - Eclipse Scout - Booth 10

We are looking forward to meeting you and discussing about your experiences with Eclipse Scout.

Scout Links

Project Home, Forum, Wiki, Twitter


by Jérémie Bresson at October 16, 2014 03:45 PM

CR1 for Luna - Ionic, Forge, Hibernate, Server

by fbricon at October 16, 2014 12:37 PM

Happy to announce JBoss Tools 4.2 CR1 and Red Hat JBoss Developer Studio 8 CR1 for Eclipse Luna is now available.

JBoss Developer Studio 8 Splashscreen

Installation

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

java -jar jboss-devstudio-{version}-installer-{standalone|eap}.jar

JBoss Tools or JBoss Developer Studio Bring-Your-Own-Eclipse (BYOE) requires a bit more:

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse 4.4 JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you either find us on Eclipse Marketplace under "JBoss Tools (Luna)" or "JBoss Developer Studio (Luna)".

For JBoss Tools you can also use our update site directly if you are up for it.

http://download.jboss.org/jbosstools/updates/development/luna/

Note: Integration Stack tooling will become available from JBoss Central at a later date.

What is new ?

This release is mainly a big set of bug fixes but we managed to slip in a bunch of new features too.

Hotcode replace aware server adapter

Ever been annoyed by Eclipse’s "Hot Code Replace Failed" dialog and how it only offers you to Continue, Terminate or fully restart your running VM ?

Ever wonder why Eclipse couldn’t just restart your deployed modules and let you continue working without have to wait for a restart of the application server + your own application ?

If you can answer yes to the above, then you will be happy to hear we now support this.

JBIDE 18094a

Now, if you run a server in Debug mode and a hot code replace fails due to some class or jar changes, the dialog above will appear, giving you the option to restart the modules, terminate the server, restart the server, or just continue as if nothing happened.

But beyond this, it also offer you the option to "Remember this choice for this server", allowing you to click "Restart modules" once and then all subsequent hot code replace failures will automatically trigger a restart of just the modules.

This is probably my personal most wanted feature improvement in years - sorry for it to take so long but please do enjoy it now.

Hibernate Tools "rewired"

To support the latest Hibernate 4.3 and JPA 2.1 releases, we had to "rewire" large part of Hibernate Tools' internals. In the past Hibernate 3.6 was hardwired to be used for loading users mapping configurations for the UI - that is no longer the case. The configured version for your console configuration is now used everywhere instead of only for codegeneration.

I’ll spare you from the details here but just outline that the rewiring has been completed and we now support Hibernate 4.3 and JPA 2.1. But beyond that, previous versions should be much more stable now too!

If you do find discrepancies in this area, please let us know by opening a bug report.

New AngularJS Forge wizard

JBoss Central now features a new AngularJS with Forge project wizard to let you kickstart new JavaEE based applications almost from scratch, using the powerful JBoss Forge scaffolding capabilities.

new forge wizard

You will be asked to install Forge Tools, if it is not already installed. The wizard will also recommend you to install the AngularJS tooling.

Once you create the project skeleton from the new wizard, a cheatsheet will open and will guide you through the different steps necessary to use JBoss Forge and scaffold REST endpoints and a UI layer based on AngularJS.

Please be aware that if you enable "Early Access" on JBoss Central you will get even better AngularJS suport (see below).

Updated AngularJS tooling

AngularJS IDE v.0.5.0 is now available in JBoss Central Early Access (go to the software/updates page in JBoss Central and click on the Early Access checkbox). Biggest change here is that the Angular JS editor is no longer needed and has been removed. Instead, content assist, code highlighting and easy navigation for AngularJS are now available from the standard and JBoss Tools HTML editors.

angular

More Ionic goodies for mobile development

More widget components have been added to the Ionic Palette for HTML5 files. See the New and Noteworthy page for a complete list of newly available widgets.

palette

When an Ionic widget is added to an HTML file, the links to Ionic JS/CSS CDN resources may also be created automatically.

ionic js

Content assist (Ctrl+Space) for <ion-*> tags and their attributes is now supported by the JBoss Tools HTML editor.

ionic ca

Pom properties activated m2e configurators

JBoss project configurators for m2e now support an activation property in the <properties> section of pom.xml. Expected values are true/false and override the workspace-wide preferences found under Preferences > JBoss Tools > JBoss Maven Integration.

Available properties are :

  • <m2e.cdi.activation>true</m2e.cdi.activation> for the CDI Project configurator,

  • <m2e.seam.activation>true</m2e.seam.activation> for the Seam Project configurator,

  • <m2e.hibernate.activation>true</m2e.hibernate.activation> for the Hibernate Project configurator,

  • <m2e.portlet.activation>true</m2e.portlet.activation> for the Portlet Project configurator.

Using these are good if you find our automatic detection is too eager or too weak in finding that you need the plugins setup for CDI, Seam, Hibernate or Portlet features.

The pom.xml editor also provides matching XML templates for these properties, when doing ctrl+space in the <properties> section.

…​and more

There are more improvements covered in the more details: What’s New.

What is Next

The next release is set to be the last candidate release, so please, do try this one out and give feedback to make sure you’ll have a good experience with JBoss Tools on Eclipse Luna!

Let us know what you think in the comments below!

Hope you enjoy it and remember…​

Have fun!

Max Rydahl Andersen & Fred Bricon
@maxandersen @fbricon


by fbricon at October 16, 2014 12:37 PM

Beta3 for Luna - Cordova, Ionic, OpenShift, Server

by maxandersen at October 16, 2014 12:37 PM

Happy to announce JBoss Tools 4.2 Beta3 and Red Hat JBoss Developer Studio 8 Beta3 for Eclipse Luna is now available.

JBoss Developer Studio 8 Splashscreen

Installation

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

java -jar jboss-devstudio-{version}-installer-{standalone|eap}.jar

JBoss Tools or JBoss Developer Studio Bring-Your-Own-Eclipse (BYOE) requires a bit more:

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse 4.4 JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you either find us on Eclipse Marketplace under "JBoss Tools (Luna)" or "JBoss Developer Studio (Luna)".

For JBoss Tools you can also use our update site directly if you are up for it.

http://download.jboss.org/jbosstools/updates/development/luna/

Note: Integration Stack tooling will become available from JBoss Central at a later date.

What is new ?

This release is mainly a bunch of bug fixes but also a few new features and a very important regression fix.

Better Plugin Management for Apache Cordova

Our Hybrid Mobile Tools now supports automatically downloading the plugins listed in your config.xml giving you two benefits:

  1. Allow you to exclude the physical plugin binaries from your source control

  2. On import the right plugin will be fetched dynamically, great for sharing examples and code.

Also don’t forget we have proposed and contributed Hybrid Mobile Tools at Eclipse under Eclipse Thym.

CordovaSim is now less meme-compatible

CordovaSim using Ripple had a "easter-egg" in the sense when you used a Cordova plugin that the Ripple engine did not understand would show a dialog titled "I Haz Cheeseburger?!?!". Great for those with a great love for internet memes but it was not very informative.

Now we provide a less meme heavy dialog letting the user know what plugin that is not supported and allow you to not have to see the message again.

Plug-in not supported dialog

Btw. if you use a popular and/or important plugin that is not supported open a jira or PR against CordovaSim.

Ionic framework in palette

We’ve added support for Ionic framework. Ionic is a AngularJS based framework that provides nice mobile components that works especially well with Cordova based application.

Ionic palette

Maven Central archetype catalog

One of the improvements in m2e 1.5 for Luna was that it no longer by default download the Nexus indexes for all repositories by default. It was simply too slow.

Thus that had to go but by removingt this the list of archetypes for the 'New Maven Project' was heavily reduced.

In Beta3 we’ve added the Maven Central Archetype catalog meaning you get access to ~9600 archetypes in a few seconds vs several minutes in pre m2e 1.5 days.

Maven Central Archetype Catalog

Review commit changes when pushing to OpenShift

When pushing changes to OpenShift and you have uncommitted changes we now show a variation of the standard git commit dialog allowing you to be selective about what files you want to get committed/added before your push.

Review changes before committing to OpenShift

JMX Navigator grouping of connections

With all the great additions to the JMX tooling in last beta we realized the JMX Navigator view could benefit from having its connections grouped by type.

Allows you to more easily find what you are looking for and when auto-discovered connections come and go the view stays stable.

JMX Navigator group by connection type

Fixed incremental deployment regression

…​and finally we fixed a rather severe regression in our server tools. The server adapter were triggering full redeployments if your project had certain type or module or jar dependencies.

Making your development workflow really slow compared to the more or less instant feedback you should get when just updating dynamic content like html or jsf.

Sorry for having that broken but now it is fixed - thus if you felt the server publishing was slow then please try it now! It should be back to its fast self again.

…​and more

There are more improvements covered in the more detailed: What’s New.

What is Next

This Beta is the last planned Beta for JBoss Tools 4.2 and Developer Studio 8. The next release is set to be the candidate release thus please do try this release out and give feedback to make sure you’ll have a good experience with JBoss Tools on Eclipse Luna!

Let us know what you think in the comments below!

Hope you enjoy it and remember…​

Have fun!

Max Rydahl Andersen
@maxandersen


by maxandersen at October 16, 2014 12:37 PM

m2e 1.5.0 improvements

by fbricon at October 16, 2014 12:37 PM

The Maven Integration for Eclipse plugin, a.k.a. m2e, released version 1.5.0 a few weeks ago, as part of the annual Eclipse release train, this year known as Luna. 77 Bugs were fixed as part of that release, compatible with both Eclipse Kepler and Luna. I believe it’s a pretty solid one, with numerous interesting fixes and usability improvements that deserve a blog post. So here goes, in no particular order:

Improved project import workflow

Selecting Maven projects to import used to take an inordinate amount of time, due to a suboptimal - I love that word :-) - Maven Lifecycle Mapping Analysis (LMA). LMA is used to determine whether the projects would require further configuration to operate properly in Eclipse. That LMA is now only run after projects are imported, making selection of projects to import much, much faster (< couple seconds vs 1-2 min for the wildfly 8.0 codebase and its 130 projects, for instance)

After import, lifecycle mapping error markers are collected on imported projects and the discovery service is invoked to find proposals to fix those errors.

Another improvement to this workflow is the ability to easily import multi-module projects to an Eclipse Working Set. The default name is inferred from the root project but can be overridden manually:

m2e workingset import

More performance improvements during import itself are to be expected to be included in m2e 1.6.0.

See bugs 409732, 408042 and 417466.

Improved memory consumption

Maven project instance caching strategy has been revisited to reduce memory consumption. For a workspace with 300+ projects for instance, heap memory used went from 2.5GB down to well under 1GB without any noticeable side effects.

Nexus index download disabled by default

Before m2e 1.5, by default, Nexus indexes were downloaded on new workspace startup, then subsequently once a week. Depending on your internet connection, that whole process could take 15 minutes or more, heavily pegging the CPU. Once the indexes were updated, the size of the workspace would increase by approximately 500 MB. Even though space is relatively cheap these days, those with many workspaces (eg., for testing) or large workspaces, this extra disk usage can add up quickly.

m2e 1.5.0 now has this feature disabled by default. You can still enable it in Preferences ▸ Maven ▸ Download repository index updates on startup. One major downside of having this feature disabled by default though, is Archetype and Artifact/Plugin searches are now much less efficient, as they rely on this indexed content.

See bug 404417

New Maven Profile management UI

The JBoss Tools team contributed its Maven Profile management interface to m2e 1.5.0. This new interface eases switching between profiles.

Rather than right-clicking on a project, going to the Properties ▸ Maven page, then manually (mis)typing a list of active or disabled profiles, you can now just use Ctrl+Alt+P to open the new Maven Profile selection interface.

m2e profile selection

The new interface is also accessible from the Maven context menu: Right-click project Maven ▸ Select Maven Profiles…​

The list of available profiles is inferred from profiles defined in:

  • the project pom.xml

  • the project’s parent hierarchy

  • user and global maven settings.xml

When several projects are selected, only the common available profiles are displayed for selection. Common profiles are profiles defined in settings.xml or profiles having the same id in different pom.xml.

You can learn more about that feature from the original JBoss Tools blog

See bug 428094

Easily update outdated projects

The Update Maven Project dialog (launched via Right-click project Maven ▸ Update Project…​ or via Alt-F5), now shows a dirty overlay on projects which need updating.

Additionally, an "Add out-of-date" button adds all out-of-date (OOD) projects to the current selection. If an OOD project has not been selected, a warning is shown underneath the selection table with a link equivalent to "Add out-of-date". Warning text and "Add out-of-date" button tooltip show a count of unselected OOD projects.

m2e select ood projects

See bug 422667

No more Unsupported IClasspathEntry kind=4

There’s a very popular question on StackOverflow about an m2e bug that plagued many users of the maven-eclipse-plugin: m2e would throw Unsupported IClasspathEntry kind=4 exceptions on classpath entries generated by the maven-eclipse-plugin (one of the reasons why you should never mix maven-eclipse-plugin and m2e).

m2e 1.5.0 no longer complains about these unsupported classpath entries, but unexpected classpath issues may still arise, should you mix duplicate jars from m2e and those added by the maven-dependency-plugin.

New checksum settings

Ever connected to a network with limited Internet access or simply stayed at a hotel where you needed to get past a for-pay-firewall, resulting in HTML pages being downloaded instead of jars? There’s nothing better to pollute your local Maven repository. Maven CLI builds can use these flags:

  • -C - fail build if checksums do not match

  • -c - warn if checksums do not match

m2e now has a global Checksum Policy available in Preferences ▸ Maven, that will help you keep your sanity, and yor local repository clean:

m2e checksum policy flag

While m2e actually won’t create any Warning markers on projects when "Warn" is selected, it will override existing checksum policies set on repositories.

Improved settings for Errors/Warnings preferences

m2e has been known for generating specific errors that have puzzled more than one user in the past:

  • Project Configuration is not up-to-date - a change in pom.xml might require a full project configuration update.

  • Plugin execution not covered by lifecycle - m2e doe not know if it is safe to execute a maven plugin as part of the Eclipse build

With the new Preferences ▸ Errors/Warnings page, users can now decide according to their own needs whether these errors should be downgraded to Warning, or even be ignored entirely.

m2e warnerrors prefs

See bugs 433776, 434053

Maven runtime changes

A few changes have been made with regards to the Maven runtime(s):

  • The embedded Maven runtime has been updated to maven 3.2.1.

  • The Netty/AsynHttpClient transport layer as been replaced with OkHttp 1.5.4. OkHttp is now the default HTTP client on the Android platform. It brings HTTP 2.0 and SPDY support to artifact downloads. Please note though, NTLM authentication is not supported.

  • Maven runtime installations can now be customized with a name, and additional libraries can be added. Maven Launch configurations now reference the Maven runtime by name, instead of using a hard-coded location so the configuration is more portable.

See bugs 427932, 418263, 432436

Accept contributions from Gerrit

In order to lower the contribution barrier and increase contributor diversity, the m2e project now accepts changes contributed via the Gerrit review system. Head over the wiki that explains how to use it. Does it work? Hell yeah! After several significant contributions, Anton Tanasenko has joined the m2e team as commiter!

Welcome Anton!

See bug 374665

Conclusion

With new blood on the m2e team, numerous fixed bugs and some big new features & improvements, m2e 1.5.0 is a pretty exciting release. Hope you guys appreciate this year’s release, before an even better version next time.

So if you haven’t installed m2e 1.5.0 yet, head over to https://www.eclipse.org/m2e/download/ and have at it.

We’d love to hear your feedback on the mailing list, or whether you report bugs or enhancement requests.

Fred Bricon
@fbricon


by fbricon at October 16, 2014 12:37 PM

EASE @ EclipseCon Europe

by Christian Pontesegger (noreply@blogger.com) at October 16, 2014 10:45 AM

 
Just 10 days until EclipseCon Europe opens its doors. If you did not register yet, it is about time! All these tutorials and talks along with meeting the developers behind those tools is inspiring and well worth the costs.

While there will be no official talk about EASE this year, you may join our Where to go with EASE session at the Unconference Day on monday.

Catch me for a coffee break or meet me at the hackathon and discuss your scripting needs with me.

by Christian Pontesegger (noreply@blogger.com) at October 16, 2014 10:45 AM

EMF Forms 1.4.0 Feature #3: Styling Capabilities

by Jonas Helming at October 16, 2014 10:16 AM

In this blog series, I describe the five most notable new features of EMF Forms 1.4.0. EMF Forms is a framework to efficiently develop form-based UIs based on a given data model. Please refer to this tutorial for an introduction to EMF Forms and to this post for an overview of the series.

As notable feature number three in EMF Forms 1.4.0, I pick the new template model and its styling capabilities. EMF Forms ships with default renderers for all view model elements. These provide a good starting base, but in many cases, projects want to adapt the way view model elements are rendered. EMF Forms supports this; renderers can be adapted and replaced. However, there are some small required adaptations that are frequently necessary in projects. An example of such  a adaptation is the background color of a control or the font of a label. With EMF Forms 1.4.0, these properties can be configured without the implementation of a custom renderer, more precisely, the parameters can be set with the existing renderers of EMF Forms.

In the view model itself, the setting of renderer parameters is done in a simple model called “Template Model”. There is a clear separation between the template model and the view model. View models describe the logic structure of the UI and are independent from the rendering. Template models set concrete values for the rendering, e.g., font sizes or colors.Template models are therefore very similar to CSS styles. Like CSS, a style always consists of a selector and a number of style properties. The selector determines for which elements in the UI the style is applicable. There are currently two supported types of selectors in EMF Forms. A “View Model Element Selector” defines a certain view model element that the style should be applied to, e.g., “Control”, “Group” or “Label”. Additionally, the selector can rely on the properties of a view model element, e.g., it could only apply for read-only view model elements. The second selector “Domain Model Reference Selector” binds a style to a specific attribute of the domain model, e.g., the firstName attribute of the class User.

image03 EMF Forms 1.4.0 Feature #3: Styling Capabilities

After defining the selector, an arbitrary number of style properties can be added to a style. All of them will apply to the elements determined by the selector. The following screenshot shows the result of a styled UI.  The first text control has the “alignment right”, the third has a different “Mandatory maker” and the label has adapted font, size and color. Please find more information how to use template models in EMF Forms here.

image02 EMF Forms 1.4.0 Feature #3: Styling Capabilities


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, eclipseRT, emf, eclipse, eclipseRT, emf


by Jonas Helming at October 16, 2014 10:16 AM

Sirius 2.0 : Under the Hood

by Cédric Brun (noreply@blogger.com) at October 16, 2014 10:10 AM

This summer was quite intense for the Sirius team. Sirius 1.0.0 was barely out that development of the 2.0 stream started while report from adopters which are not part of the Eclipse Release train started to appear.

That represents fixing more than 100 tickets since the end of june, a few for Sirius 1.0.1 which got published a few weeks ago (and is part of Luna SR1). From those tickets 82 are targetting Sirius 2.0 (over a current perimeter of 101 tickets), we are currently validating the changes and closing the gap. As a sidenote more than one third of the tickets implemented in this version are directly funded by end users (hint : this might be you).

Sirius 2.0 will be released just before EclipseCon Europe , most of the 21 enhancements in this scope are already implemented and are under validation:  now might be a good time for giving a look.
These enhancements are mostly focused on the diagram editor user experience, fixing long standing issues inherited from the default behavior of the GMF runtime and bringing nice features for intensive users of diagrams. But we'll tell more about that in a specific post, lets focus on the "not so visible changes" for now :

Performances and Scalability

Another strong focus of the 2.0 version was performances and scalability : finding bottlenecks and taking them down.

We worked on the basis of EcoreTools 2.0 with a "big enough" model to detect such bottlenecks and mostly focused our efforts on the CPU usage (for now but memory will also be important at some point too).  1.5Go heap was the target, as long as the scenario were doing fine within this bound we did not investigate.

What is a "big enough" model you will ask, it is composed of 500 000 model elements (here EClasses, EAttributes, EPackages ...). 20 000 representations are created on top of those, 2 of them representing hundreds of EClasses.

The test data is reverse engineered from the Sirius source code itself which make it quite "close" to a sensible Ecore model. Such a model makes it easy to identify bottlenecks: places where your code have a complexity relative to the number of model elements, or places where you are doing too much work on the UI thread.



This has proven to be a very efficient way to identify problems and to fix them. Having a consistent installation of EcoreTools + Sirius is quite easy, opening the test project become a breeze then and anybody in the team can reproduce the problem and measure for himself.

And here we are :


We fixed 16 tickets tagged "performances" for the 2.0 release, here is the list of improvements :
- Sirius is initializing itself quicker (notable on startups and first usage)
- Many calls from the UI threads which were scaling poorly when you have thousands of representations are now way faster
- Delete have seen a big boost and is now scaling based on what you specify and how many things have changed during the execution of your tool independently of the size of the model
- Diagram having lists with many elements are created and refreshed quicker (the improvement is noticeable has soon as you have lists with hundreds of elements)
- Select All used to have an irritable lag when you were working on a big model, it is now instantly completed.
- Tree Editors defined using Sirius are now more efficient in refreshing the SWT Components.

But more things have been identified often with partial patches which have not graduated yet to the stage of "reviewed and regression tested" but will in the next releases. Expect some improvements in the way "save" is handled when you have hundreds of resources. This is a constant effort but one which has great pay-off: any improvement in Sirius itself brings improvements in the dozens of tools which are relying on it.

Performances are always a tricky issue for a generic framework or technology, so many things will depend on how its used and in which context and the most innocent change can dramatically impact the properties of your tool. The #1 rule is : have test data which are representative of what you want to achieve, make sure it can be used and migrated easily from version to version.

Headless - aka reuse the plugins with no UI


Another area which have seen improvements is about using Sirius in "other contexts".

A first batch of changes has been merged so that some of the basic services offered by Sirius are now able to run without any UI. Things like loading a representation resource, creating a diagram,  refreshing it, modifying the model and saving can now be used as a server-side or continuous integration process for instance.

Here is a scenario which will work in headless :

 
I'm pretty excited about this release and I'm looking forward to see these improvements in the tools already adopting Sirius. Of course these are just a few more steps closer to the goal, Sirius 3.0 planned for June will bring even more !


by Cédric Brun (noreply@blogger.com) at October 16, 2014 10:10 AM

How to make eclipse attractive to new communities?

by Michael Scharf (noreply@blogger.com) at October 15, 2014 04:13 PM

Recently, I had some discussions with different people on how to make eclipse attractive for non-java communities, in particular for web and mobile developers. This is also based on my experience doing web development. Here are some of my thoughts:

The Java mind-set in eclipse

The eclipse IDE is for many people (like me) a super powerful Java IDE, and in fact, it killed pretty much all its competitors (except for IntelliJ). Java is a strongly typed language and this allows for a lot of analysis that can be done statically and we got used to refactorings and an IDE that fully "understands" our code and its dependencies. Eclipse encouraged us to structure our projects in a way that make dependencies much more explicit by having a set of interdependent projects in the workspace. The plug-in concept enforces a modular structure and is a way of organising the workspace. That's all great.

But there is another reality: all the systems and languages that are much less statically defined and that are structured differently than java. It starts with C. CDT essentially started by copying JDT, it still suffers form that, because C and C++ is a different languages with very different mind-sets than java, although there are some syntactic similarities

Similarly, trying to impose the concepts and mind-set of Java on all those scripting languages and setup-files is probably doomed to fail. I love strongly typed languages, I love modelling. In that area eclipse has so much to offer! But there is the other text based "unstructured" world with a different mind-set, where you "simply add a line to a script to get that cool feature going" (I have to say a lot about frustrations and benefits this "it's really simple" approach can create).

Is eclipse missing this huge opportunity that has opened in the last years with the shift in direction of web technologies?

The "force of intelligence" applied to eclipse

A few weeks ago, I posted a strange and probably hard to understand article about an equation that describes the physical force of intelligence. The equation essentially says, that intelligent systems try to move into directions where they are not trapped. If we apply the equation of intelligence to this problem, we have look at eclipse and at Jetbrains (the creators of IntelliJ) as two distinct "intelligent systems". Both organisations are "intelligent systems" with a "will to survive". The way those organisations act intelligently, is by moving into a direction that "maximises their future freedom of action", as I explained in the blog mentioned above.

In eclipse, nobody has real power to "direct" what is done, instead, the eclipse eco system has to surf the waves that are coming. Its intelligence is a kind of swarm intelligence. And, I think, eclipse has done a pretty good job on this. If the common interest of eclipse (as an "intelligent" system) happens to be in sync with the interest of one or more of its contributors, that is great. But just seeing where eclipse should go, without the power to steer it in that direction, is not "intelligence" according to the equation of intelligence (intelligence requites anticipating possible futures and the power to move into a promising direction) [by that definition this blog entry may not be intelligent, because I have no power to move eclipse].

Jetbrains, on the other hand, has a pretty clear gradient to follow: it has to satisfy its customers in order to make them to pay for the product, which will give them money to maintain and increase their power of action in the future. I assume the JetBrains has more control over its employees than "eclipse" has over the community to drive the development into a "desired" direction. If they continue to make clever moves they may outperform eclipse in the long run.

If I had superpower and could drive eclipse....

What would I do, if I could influence the direction of eclipse and work with a team of people that would have the manpower to make some changes to eclipse?

I think, with a few relative simple changes or additions, eclipse could increase its future freedom of action dramatically by embracing the reality of many developers. The key factors are: 
  • simplify, simplify, simplify
  • install a minimal set of plugins and suggest additions
  • embrace the file system -- don't impose projects on directories
  • don't try to build everything in java -- integrate external tools
  • embrace the command line
  • do clever search and code completion using heuristics instead of complicated models
Or in one sentence: eclipse could be an editor that talks to its environment that can grow to full blown IDE if the user needs and wants it. Instead of being an all-inclusive self-contained IDE that can be abused as editor.

Here are some more concrete ideas to focus on:
  • Create a simple extensible editor with pluggable syntax highlight (something like LiClipse by Fabio Zadrozny)
    • leverage existing (external) syntax highlighting tools to do the job (tools that are not necessarily written in java)
    • or allow to use existing syntax highlighters like the ones form TextMate
  • allow to simply create projects that are whole directory trees including different git/subversion repositories
    • Essentially, allow to point to one one or more root directories and with some clever filtering, allow to exclude parts of the file-tree that are relevant. 
    • Make it simple to assign properties, like 'generated', 'test-code', 'external-library' to subtrees (using patterns or by some UI) to be used for filtering
  • Allow to easily integrate external tools and builders. There is a strong tendency to rewrite tools in java to integrate them. Instead, provide an environment that allows to run, manage and communicate with processes that run externally on the local or on remote machines.
  • Create a clever non-modal search tool, that understands the basic syntax of languages and that can be configured to know where to search, given a context.
    • When I am in file X, I know that file Y is relevant but file Z is not connected to where I am. The problem with search is often how to limit the search scope cleverly. 
    • Typical filters on string searches would be: Do or don't search generated files, test files or external libraries; do or don't search in comments or strings; do or don't search local variables. With some basic understanding of scopes and different areas (which could come for the syntax highlighter), search can be dramatically improved.
  • A plug-in recommender
    • Provide a mechanism that suggests to install  plug-ins based on the content of the project 
  • Provide a generic heuristics based code completion tool (similar to CodeRecommenders). 
  • Heuristics based code navigation. Instead of trying to do full static code analysis of like JDT, use clever heuristics for code navigation and "learn" form users choices.
  • Provide a simple integration with command line debuggers
    • Debugging scripting languages is often much simpler than e.g. C, C++, or hardware debugging
    • It might be enough to provide a simple integration for a command line debugger. (In the 90ies I wrote an extension to the python command-line debugger that made the commands act like gdb, so I could use the gdb integration in emacs and SNiFF+). 
These are just bullet points and if there is interest, I could expand on each of them. The underlying idea is to embrace the text based "unstructured" nature of lots of systems and go back to a simple editor that can progressively be more clever as the user needs it. Do context-based search and navigation and try to syntax highlight as many languages as possible. Instead of being the super-capable IDE that knows everything and contains lots of feature, the user never uses, be the editor that progressively becomes an IDE as the user needs it.

If eclipse cannot be used as a strong editor, the chances are low that we will attract all those developers that simply use and need a capable editor. The world is changing fast, and I wonder how many projects today can ignore the web and mobile apps that use all those dynamically typed "languages" and set-up files.

Promising future for eclipse

I think, eclipse has a bright future! I see some good attempts to go in a promising direction. The risks is not lack of ideas. The risks are lack of resources and money to fund the work that needs to be done. There are a lot of freelancers and small companies, that form the eclipse eco system, making most contributions and working very hard to keep eclipse successful. They all act very intelligently, which means they have to balance their own survival and freedom of future action with the eco system they live in.

Is that enough? How to increase the "power" to act to make eclipse as a whole more "intelligent"? What do you think?




by Michael Scharf (noreply@blogger.com) at October 15, 2014 04:13 PM

RAP 3.0 M2 – What’s new in Widgets

by Tim Buschtöns at October 15, 2014 02:45 PM

Once again these are exciting times for RAP as we are preparing for the next major release, RAP 3.0. We continue to clean up code, work on the look and feel, and integrate matured Incubator components. The RAP 3.0 M2 milestone build is available for download since October 03, 2014. Here’s a list of the most interesting M2 changes specifically in the widget set.

Nebula Grid migrated to RAP Core

The RAP port of the Nebula Grid (including GridViewer) has been moved from the RAP Incubator to the RAP repository. It supports a subset of the API from the Grid found in the Nebula Release, now also including setAutoHeight.

nebula2 RAP 3.0 M2   Whats new in Widgets

Resizing a column with AutoHeight and WordWrap enabled

The Nebula Grid also works with RWT.MARKUP_ENABLED. It is included in the RAP target platform and can be used simply by importing the org.eclipse.nebula.widgets.grid package, making it single-sourcing capable. The Nebula Grid ports for RAP 2.x versions will remain in the Incubator.

  • Why the Grid instead of the NatTable?
    The Nebula Grid API is by its nature much better suited for the RAP architecture than the NatTable. The Grid is also closer to the SWT Table and Tree, allowing us to use the same mature JavaScript code for all three widgets.

Markup support for Button and Tree/Table ToolTips

The Button widget now supports RWT.MARKUP_ENABLED, allowing you to use an HTML subset in its text. Also, Tree and Table now fully support RWT.TOOLTIP_MARKUP_ENABLED. This was previously not the case if the tooltip text was provided by a ColumnViewer.

For the rest of the new features, take a look at the RAP project documentation: RAP 3.0 M2 New & Noteworthy.

M3 is planned for November 14, and 3.0 for December 19, 2014. Stay tuned on Twitter, Facebook and Google+ and be the first to learn about the new arrivals in RAP.


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, new & noteworthy, rap, widgets, eclipse, new & noteworthy, rap, widgets


by Tim Buschtöns at October 15, 2014 02:45 PM

The Final Four

by kingargyle at October 14, 2014 06:57 PM

The proposed Android Tooling Project for Eclipse has narrowed it down to four possible names. It needs the eclipse community to help chose which one will win out. A straw poll has been created to select the winner.

http://strawpoll.me/2781013

The four finalists are in no particular order:

  • Reuben
  • Eldon
  • Oragami
  • Andmore

The original bug tracking the nominations can be found here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=446172

Polling is open until October 21, 2014.



by kingargyle at October 14, 2014 06:57 PM

IoT Unconference at EclipseCon Europe

by Ian Skerrett at October 14, 2014 06:32 PM

At EclipseCon Europe, we will be hosting an IoT Unconference on Monday, October 27. This is a great opportunity for anyone to better understand what is happening in the Eclipse IoT community.  We will have updates from some of the key projects in the community, a technical deep dive into a recent project proposal from Bosch and lots of time to network and discuss IoT related topics. The details agenda is now available.

You can just attend the 1-day unconference or better attend the entire EclipseCon Europe event. I hope to see you there.

iot_logo_medium



by Ian Skerrett at October 14, 2014 06:32 PM

OM2M: Standardized service platform for M2M interoperability

by Eclipse Foundation at October 14, 2014 03:48 PM

Machine-to Machine (M2M) promises to interconnect billions of devices in near future covering various domains. However, M2M is suffering from a high vertical fragmentation of current M2M markets and lack of standards. To bridge this gap, we propose the Eclipse OM2M project, a horizontal ETSI-based service platform for M2M interoperability. OM2M follows a RESTful approach with open interfaces to enable developing services and applications independently of the underlying network. It proposes a modular architecture running on top of an OSGi Equinox layer, making it highly extensible via plugins. It supports multiple protocol bindings such as HTTP and CoAP. The TLS-PSK protocol is considered to enable secure communication based on pre-shared keys, and various interworking proxies are provided to enable seamless communication with legacy devices such as Zigbee and Phidgets technologies.

by Eclipse Foundation at October 14, 2014 03:48 PM

How to configure Mylyn Task Queries for an Atlassian JIRA Connector with Oomph Installer

by aurelien.pupier at October 14, 2014 11:26 AM

Oomph is a great tool to automate the setup of an Eclipse development environment. It provides basic default tooling for Mylyn Queries. But:

  • JIRA plugins are not available by default in Eclipse repositories.
  • There is no UI - at least I didn't find one - to extract the correct attributes value of the query. Mylyn hides the complexity behind great tooling.

So here are the steps to configure it in Oomph.

Mylyn Query information

Define the query with Mylyn tooling by following the steps explained in the documentation https://wiki.eclipse.org/Mylyn/User_Guide#Creating_new_Queries Then export the configuration by right-clicking on it:

mylyn export queries

In the exported configuration you will find a file named tasklist.xml. This file contains information required to complete the Oomph Mylyn Queries.

mylyntask.xml

Provide P2 configuration

Add P2 Director information for the Mylyn JIRA connector. Check the following screenshot:

p2director

Note the usage of the Orbit Repository.

Configure Oomph Mylyn queries

  1. Create Oomph Variables for username and password for JIRA access. The user can specify them in the Oomph Installer.
  2. Add Mylyn Queries and configure global properties:
    Mylyn Global Properties
    Note the usage of previously defined variables. The Connector Kind which is "jira" and the Repository URL can be found in mylyntasks.xml file.
  3. Add the Mylyn query with attributes based on mylyntasks.xml:
    Mylyn query attribute

Ta Da! When a user installs your project with Oomph, she/he will have the Mylyn queries ready to use!


by aurelien.pupier at October 14, 2014 11:26 AM