All about Java
Peter Severin
Abstract:
A short demo that shows how to install the WireframeSketcher plugin and start creating UI mockups.
delicious | digg | dzone
RAP-Team
Abstract:
Did you ever want to know what the Rich Ajax Platform is without spending too much time on it? For all of those we did a screencast that shows what RAP is in about a minute.
delicious | digg | dzone…
thescreencast.com
Abstract:
In this two-part screencast you are going to see how to install and use the Eclipse based SpringSource Tool Suite with Google Web Toolkit Tools to develop a working web application. Screencast is…
Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …
Needham, MA, USA and Ottawa, ON, Canada – February 3, 2010 –
OMG™ and the Eclipse Foundation have issued a Call for Participation for the 2nd
Biannual Symposium on Eclipse Open Source Software and OMG Open Specifications to be held
June 23, 2010 in Minneapolis, Minn., USA. The submission deadline is February 24. For more
information visit http://www.omg.org/eclipse-cfp.
Eclipse is an open source community whose projects are focused on building an open development
platform comprised of extensible frameworks, tools and runtimes for building, deploying and
managing software across the lifecycle. Many Eclipse projects implement one or more OMG
specifications. This symposium follows two successful one-day events that Eclipse and OMG
jointly organized in 2008 to promote and build on the partnership between Eclipse’s open
source software and OMG’s open specifications. It will include a series of discussion
sessions on OMG standards and corresponding Eclipse projects, to facilitate alignment between
current specifications and implemented software, and identify areas where the cooperation
could be further improved in future.
Eclipse Foundation and OMG invite position papers on any of the topic areas below, or any
other area where an OMG specification relates to Eclipse software. The Program Committee
will publish all submitted position papers, and invite selected paper authors to lead
individual discussion sessions.
Topics may include (but are not limited to) the following:
The Program Committee particularly welcomes papers that deal with specific problems and
solutions that may benefit from a wider discussion than that available though Eclipse Bug
Reports or OMG Issue reporting.
Interested individuals or organizations are invited to submit a brief (up to 600 words)
position paper by February 24, 2010 using this web form (please select “Presentation”):
http://www.omg.org/abstracts.
The Program Committee will send invitations to prospective session leaders in early March
2010. The final symposium agenda and registration details will be available on March 17,
2010 and posted at:
http://www.omg.org/news/meetings/tc/mn/special-events/Eclipse.htm.
About the Eclipse Foundation
Eclipse is an open source community, whose projects are focused on building an open development
platform comprised of extensible frameworks, tools and runtimes for building, deploying and
managing software across the lifecycle. A large, vibrant ecosystem of major technology vendors,
innovative start-ups, universities and research institutions and individuals extend, complement
and support the Eclipse Platform.
The Eclipse Foundation is a not-for-profit, member supported corporation that hosts the Eclipse
projects. Full details of Eclipse and the Eclipse Foundation are available at www.eclipse.org.
About OMG
OMG™ is an international, open membership, not-for-profit computer industry standards
consortium. OMG Task Forces develop enterprise integration standards for a wide range of
technologies and an even wider range of industries. OMG’s modeling standards, including the
Unified Modeling Language™ (UML®) and Model Driven Architecture® (MDA®),
enable powerful visual design, execution and maintenance of software and other processes,
including IT and Systems Modeling, and Business Process. OMG’s middleware standards and
profiles are based on the Common Object Request Broker Architecture (CORBA®) and support
a wide variety of industries. For more information, visit
www.omg.org.
There is a jurisdictional issue brewing over the future of internet standards – I know because I’m stirring the pot. The dispute is between the WHATWG and the IETF regarding the specification process for the websocket protocol (which I have some concerns about, but none the less is supported by Jetty).
The IETF
is the body that has been responsible for developing and/or
standardizing the vast majority of protocols which run the internet:
HTTP, FTP, SMTP, etc. It has an open collaborative based process based
on working code and rough consensus and is overseen by the Internet
Society, a non profit organization with membership open to all.
The WHATWG
was formed in response to concerns about the W3C’s evolution of HTML
and has been instrumental in developing the HTML5 standards. It is
essentially a browser vendor consortium that is governed by an invitation only committee
and lead by a Google employee. While it’s process is conducted openly
and all are invited to participate, only the appointed editor has any
power in the actual decision making process. The editor is appointed by
the browser vendors.
The majority of the
WHATWG efforts have been about HTML5, and most welcome the advances
they are driving in the browsers. However, the websocket API and
protocol have also come out of the HTML5 work and specify a new
protocol that will run over ports 80/443, that will start off looking
kind of like HTTP, but is expressly not HTTP.
Making
the internet work well by producing quality standards is exactly the
mission statement of the IETF. So a new protocol running over port 80
is definitely something that falls within the scope of the the IETF
mission. The WHATWG were invited to submit their protocol as a IETF
draft document, which they did and the IETF after due process has
formed the hybi working group to ” take on prime responsibility for the specification of the WebSockets protocol”. This appears to have shocked
the WHATWG and they saying that they do not wish to relinquish
editorial control of the protocol. It appears they were hoping for a
rubber stamp from the IETF.
Meanwhile,
Google’s Chrome browser has started shipping with the websocket
protocol enabled and it is expected that other browser vendors in the
WHATWG consortium will soon follow. The argument has been made that
it’s “already shipping”, so it’s too late to make any significant changes to the protocol.
The
problem is that the protocol has been developed by only a fragment of
the internet industry, and essentially by a single company within that
fragment. There has been no consensus sought or obtained from the wider
internet community – ie servers, routers, bridges, proxies, firewalls,
caches, load balancers, aggregators, offloaders, ISPs, filters,
corporate security policies, traffic monitoring, billing, accounting,
shaping, application frameworks etc. etc. These communities and
vendors are waking up to a world where the traffic they expected over
port 80/443 aint what it used to be. Their products and services will
be broken, bypassed or at best co-opted for unintended usage. They had
no real voice in this change. Many would not have even realized that
the HTML5 effort was going to substantially change the wire protocol.
It is easy to present this state of affairs as a takeover of port 80 by Google so that they can get Wave
to work better. That google expect the rest of the industry to
scramble to make the changes necessary to allow websockets to tunnel
through the infrastructure unhindered by any concerns other than
connectivity to Google. I know that this characterization of the
situation will be taken as personally insulting to the individuals
involved, who I’m sure are acting in good faith and not as part of some
conspiracy. However, the power of group-think is significant and
individuals are greatly affected by the environment that they operate
in. Conflicts of interest are avoided by not by peoples best
intentions, but by not creating processes that are inherently
conflicted.
I don’t mean to be too
Machiavellian about this, but if the IETF does not assert is roll as
the primary internet standards body, then the outcome will essentially
be that a Google led consortium has taken over port 80. Note that
Google are also doing some great research on a HTTP replacement
protocol called SPDY, which
is showing some excellent promise. SPDY might be the way of the future,
but do we really want it to arrive by having google simply start
shipping it in Chrome? If we let port 80 be taken by websockets
without consensus, then could happen with HTTP as well (mwah ha ha ha)!
The
websocket protocol as specified by the WHATWG might indeed be
wonderful, but unless we follow due
process, we will not really know that it is. The IETF has a truly open
process based on rough consensus in which all are welcome to
participate. They have a proven track record and have overseen the
standards that have withstood the unprecedented growth in the
internet. The IETF are the natural body to oversee standardization of
internet protocols and there is no evidence that this task would be
better handled by a closed industry consortium lead by Google.
My
suggestion of how to break this impasse, is for the WHATWG to continue
to be the editor of the current specification and to push forward with
the deployment of 1.0, which essentially ignores intermediaries and
proxies anyway. In parallel, the IETF should continue with their
working group to develop the 1.1 specification based on 1.0, but with
an all-of-industry rough consensus.
In short, not much. At least, externally visible. There’s the possibility that it’s a duck, with limited visibility on what’s happening above the surface but furious paddling underneath; or it could be an iceberg with a similar differentiation between what’s externally visible and what’s under the covers. (Let’s just hope there’s no Titanic passing close by…)
In my previous post on JSR294, where to misquote Mark Twain “The news of JSR294’s death has been greatly exagerated”, it seemed that JSR294 is alive and well. In the jsr294-modularity-observer list, I triggered a discussion on the inactive status (which turned out to be an automated red herring). I got cited for spreading misinformation on the web:
It has come to my attention that someone is spreading false information
with respect to JSR 294 [1,2].Frankly, there are too many cleverly-worded points in this
misinformation to address individually here. The observer list remains
available for any observer to send questions and comments to.The “inactive” flag set on JSR 294 by the JCP Program Management Office
is unfortunate. I explained its origins to Peter Kriens earlier today.
It will be removed as soon as I publish an Early Draft Review, as per
PMO rules.I expect to publish an EDR within days [AlBlue: of 11th Dec 2009], and am confident it will meet
the Expert Group’s approval.
It should be noted that upon receiving updated information I edited in place both of the articles; and in the InfoQ piece, I specifically referred to JSR294 as ‘inactive’ although the blog post took its title from the well-known phrase The King is Dead! Long live the King!, also the title of an Enigma album. So both posts now correspond to reality, cleverly worded or otherwise.
But what of the promised EDR? Days turned to Weeks; Weeks turned into Month(s), and Sun turned into Oracle (or is about to be). Yet there’s still no sign externally that an EDR has been published, nor has there been any info to update on the public JSR 294 page. The easy conclusion to jump to is that the EDR is delayed (whether through choice, accident or unexpected event is speculative). Either way, there has been no EDR to speak of.
Meanwhile, Alex Buckley has published version 0.1 of the Project Lambda JLS draft, along with follow up comments there. Arguably the additions of lambdas is a more important end goal to Java than an incomplete module specification; so perhaps that is a better focus. Or it could be that the Oracle/Sun merger, now that it’s finally about to happen there may be a culling of useless JSRs. Jigsaw will still continue, but other than the addition of the module package-like protected interface to fields – which arguably OSGi already does by virtue of its exported packages – there wasn’t much overlap or use with JSR294.
Incidentally, speaking of Jigsaw, there’s a new proposal for a Jigsaw module-file format. Rather than using a standard JAR for containing data, the module-file format is a brief header (with some generally useless information), the (uncompressed) module-info.class file (which turns up from time-to-time in JSR294), followed by a Pack200 representation of the rest. The idea is to be able to parse some information from the module before it’s all finished downloading (JARs are based on the ZIP file format). ZIP’s standard reliance on the Central Directory at the end means that in order to parse a ZIP ifle, you need to jump to the end to be able to parse it (and in addition, be able to figure out all the intervening chunks). Arguably, there’s nothing that would prevent the central directory being written out first, but this tends not to be the case for automatically generated headers. Tools that introspect a single entry (like the MANIFEST.MF or INDEX.LIST) might be able to guess at the first two entries (which, after all, have the data and filename) and most JARs are built with the MANIFEST.MF up front. In other words, we don’t technically need to download a whole OSGi bundle to find out what it’s dependencies are too.
What’s more interesting, is that one of the goals for moving the module dependency to executable code (rather than having a declarative specification of the OSGi bundle, for example) was to allow code to extend the dependency list. Yet in the module-info class case, if that refers to any non-local classes (such as those that are coming down in the following Pack200 JAR file) it will either (a) not be able to create its dependency list, or (b) have to wait until the entire file is downloaded before having that information. Flexibility can be such a double-edged sword at times.
(It’s probably worth noting here that Pack200 completely reorganises the layout of the JAR file – it’s a non-streamable format. You have to load the entire file in before you can even extract one component, so if you have Pack200 JARs – either as part of a P2 update site, or as part of a Jigsaw module – you have to load the lot before you can do anything. (And that’s aside from problems with how you compile module-info.java in the first place.)
So, we all still wait to see what the outcome of the JSR294 EDR proposed proposal is. Alex was confident in its adoption, so perhaps it’s been trimmed down to just a single keyword; though the thorny issue of irrational version numbers, even as Semantic Versioning is already the de-facto standard, still holds. As Stephen J. McConnell noted, a version numbering system that permits “point-free @ braindead” and “point-free @ pathetic” as valid (but yet incomparable) version numbers is one that really means nothing at all. And yet, even though the spec offers a free-for-all naming convention (for both the module name and the version number), it mandates the @ be used – an operator overloaded with annotations in a Java class. It seems that whilst JSR294 is supposed to be independent of Jigsaw, it’s firmly driven by Jigsaw’s requirements.
Interestingly, a recent update by Alex Buckley on the difference between JSR294 and module systems, tries to focus what JSR294 is supposed to deliver – language and VM features for the benefit of module systems such as OSGi and Jigsaw. Although it would be tempting to read too much into the PDF at the moment, the key is the module-level visibility (without actually defining what a module boundary is) is encoded in the .class files. A generic way of specifying modules, whilst ignoring the module-info.java and the versioned dependencies that introduces, seems like a necessary step towards source-level module awareness.
One could argue, though, that this is entirely pointless. The goal of a module system is to express (versioned) dependencies of the things you depend on. Whether a field is accessible or not, or whether it’s enforced by the VM at runtime, is a bit of a moot point. Indeed, OSGi already provides this out of the box (at package-level granularity) by preventing you from accessing classes that are not visible. And if you have the Java source file for your code (to put the restricted module keyword in) then you can just as easily move the code into an internal (non-exported) package. Module-crossing boundaries (think Eclipse’s ‘internal’ or ‘friendly’ classes) are a use case which is not used well at the moment; they’re exported, but not really supposed to be used by other bundles. Having a module keyword, such that classes in the JDT packages are all in the same module, might provide a way of sharing internal details without having to expose their innards to the rest of the world.
But in reality, internal classes (or modules spanning bundles) are themselves a sign of a problem, rather than a symptom which should be treated. Having internally shared code between (say) JDT and JDT UI is the problem; get rid of that, and you don’t need to have bundle-spanning-modules.
Ultimately, JSR294 is a tricky thing to solve. Sun want to have a module system without OSGi’s so-called-but-not-qualified ‘problems’ (more realistically; one developed in-house to avoid intellectual property rights), whilst OSGi is the de-facto standard module system for Java at the moment. Given OSGi’s more restrictive nature (particularly in the form of version numbering) makes a combined proposal – like the earlier Simple Module System – less likely to be acceptable to both parties.
Of course, the people who ultimately get hurt by this are the Java developers of tomorrow. There won’t be a format that is accessible to both OSGi and Jigsaw module systems, which means developers will have to pick which one to support. Quite aside from the fact that OSGi bundles are already backwardly-compatible JAR files (and thus can be used inside or outside of a module runtime), the choice of using Jigsaw is to lock yourself into one manufacturer’s VM and from an as-yet-unreleased point forwards. It’s not difficult to do the math of where the biggest customer base is.
Finally, because someone always mentions it, OSGi is not too complex. Actually, arguably it makes development easier – particularly when considering things like the Blueprint service or Declarative Services, which provide a dependency-injection way of configuring modules without needing any code references to org.osgi packages in source. This, of course, makes them trivial to mock, both at testing time and then later at run-time as well. And, as noted in December’s Bundle.update, the Enterprise Expert Group Draft 4 was previously made available and is nearing completion. This will give an OSGi way of binding JNDI references and JDBC drivers to running OSGi applications, making an OSGi runtime into a JavaEE type container with late binding of databases. Whilst the spec isn’t yet finished, the direction of the group (including the WAB web bundle format) will make it trivial to deploy web-based applications that lean on the OSGi runtime.
What is complex, however, is the concept behind modularity. How you split apart a system into smaller modules, how to reference the components’ dependencies, how they hook together in the face of a non-flat classpath are all problems that Jigsaw will face just as much as OSGi will. Problems reported between “Hibernate and OSGi” will be just as applicable as “Hibernate and Jigsaw”. At least OSGi was defined with services in mind (allowing cross-module communication to occur); it’s just not clear whether Jigsaw will discover that down the line or not. Factories (like the URL parsers) in the JDK are currently in the same module as the net stuff anyway; so that’s an internal reference. But you can bet that a Jigsaw module ringfenced around the Java net classes will face exactly the same problems of how to depend on third-party supplied factories (c.f. JDBC, XML parsers…) in a non-flat classpath. Of course, the way it’s likely to happen is by using a non-non-flat classpath, or exactly the same classpath as we get outside of module systems at the moment. However, a compile-time checked classpath but with a flat runtime classpath (albeit one with ‘module’ keyword checking done on the fly) is going to prevent any kind of duplicate version being loaded into memory, or dynamic reloading of classes for that matter.
Modular Java is complex. Solutions to complex problems can be simple, or they can be complex; but if you don’t understand the problem, then everything looks complex. Kirk Knoernschild recently declared that 2010 is the year of Java Modularity and followed up with Java Modularity: Time to Set Sail. Modularity is something that we all need to pick up, regardless of which module system is needed. Ultimately, it may all boil down to today’s Oracle/Sun conference:
So it may come down to this. The future of OSGi, Jigsaw, and modularity on the Java platform comes down to the direction that Oracle intends to take Java technology going forward. Of course, their decision will have a tremendous impact on the entire Java ecosystem. We should have direction sometime soon. Time to set sail!
What do the following people have in common? Ed Burnette, Linda Watson, Alain Magilore, Chris Aniszczyk, Kimberley Peter, Tim Schindl, Ed Merks, Dainel Megert, Remy Chi Suen, Eric Rizzo, Nick Boldt, Paul Webster, and Benjamin Cabe.
Or the following products: Gumtree, Lombardi TeamWorks, RadRails, BEA Worksship Studio, Jigsaw Interactive, PSICAT, Tibco Business Studio, eclipse-cs Checkstyle, QNX Momentics, JPMorgan Chase, Wind River Workbench, EclEmma, Cyrano, XMIND, MyTourbook, Instantiations WindowBuilder Pro, Acceleo, ProSys mBedded Server, ModuleFusion, CHord Scate Generator and Apache Directory Studio.
Answer: They are all past winners of an Eclipse Community Award. Since 2006 we have recognized some of the leading individuals and products that make Eclipse a great community.
At EclipseCon 2010, we will once again announce the winners of the Eclipse Community Awards. Nominations for both the Individual Awards, Project Awards and Technology Awards close end of day Friday, January 29. We already have great individuals, projects and products nominated but please take the time now to recognize who you feel has made a difference this pass year.
Ottawa, Canada – January 21, 2010 – The technical program and gold sponsors for EclipseCon
2010 have been announced. Cisco, IBM, Oracle, Red Hat, SAP and Sonatype have agreed to be Gold sponsors for
the 7th annual Eclipse conference, to be held March 22-25, 2010 in Santa Clara, CA.
“Our sponsors provide the support necessary to make EclipseCon a continued success,” said Mike
Milinkovich, Executive Director of the Eclipse Foundation. “The conference provides a vital
opportunity for Eclipse users, developers and adopters to collaborate and advance the Eclipse
platform. We’re privileged to have the support of Cisco, IBM, Oracle, Red Hat, SAP and Sonatype to enable
us to put on each year a fantastic community event.”
The technical program will feature over 160 sessions and over 90 speakers. Session tracks include
EclipseRT, Modeling, OSGi DevCon, e4 and many more. In addition, the conference keynotes include:
The complete conference program is available at www.eclipsecon.org/2010/sessions.
Registration for EclipseCon 2010 is now open, with a 20% early discount being offered until February
14. To register, visit www.eclipsecon.org/2010/registration.
About the Eclipse Foundation
Eclipse is an open source community, whose projects are focused on building an open development
platform comprised of extensible frameworks, tools and runtimes for building, deploying and
managing software across the lifecycle. A large, vibrant ecosystem of major technology vendors,
innovative start-ups, universities and research institutions and individuals extend, complement
and support the Eclipse Platform.
The Eclipse Foundation is a not-for-profit, member supported corporation that hosts the Eclipse
projects. Full details of Eclipse and the Eclipse Foundation are available at www.eclipse.org.
All company/product names and service marks may be trademarks or registered trademarks of
their respective companies.
| Summary: | Learn how to become a master of the Eclipse Change Set Toolset, increasing your individual effectiveness and improving your team’s communication. |
| Applies to: | Tasktop Pro, Eclipse Mylyn |
| Supported Connectors: | Bugzilla, ClearQuest, CollabNet, JIRA, Mingle, Rally, ScrumWorks Pro, Trac, VersionOne (coming soon) |
| Supported SCMs: | CVS, Subversion (SVN), ClearCase (coming soon) |
“An apprentice carpenter may want only a hammer and saw, but a master craftsman employs many precision tools. Computer programming likewise requires sophisticated tools to cope with the complexity of real applications, and only practice with these tools will build skill in their use.
–Robert L. Kruse, Data Structures and Program Design
Eclipse is one of the most sophisticated toolsets ever offered to developers. Its plethora of available tools can eliminate many headaches from a developer’s day. Unfortunately, there are days when headaches still occur, as developers struggle to discover and use all Eclipse has to offer. A great technique for discovering the most useful tools in Eclipse is to watch an experienced developer work. In this post I’ll be sharing my change set toolset knowledge, gained from watching others, in hopes of eliminating unnecessary clicks and frustration from your workday.
The (Small) Cost of Change Set Support
Contrary to many spammers’ beliefs, everything in life has some costs, and the advantages offered by Tasktop and Mylyn’s change set tooling are no exception. To enable the benefits of the change set tooling you will need to:
Once you develop the habit of working in this way (see Task-Focused Tutorial for details) then you will be able to:
The following sections will walk you through different aspects of the change set tooling and show you how to maximize your benefits.
| Change Set – ..the set of changes made in a single commit. |
| http://en.wikipedia.org/wiki/Revision_control |
| In (hopefully) all software development organizations there is repository for storing your code. For Eclipse users this often means using a Software Configuration Management (SCM) system like CVS or Subversion. When working with an SCM developers usually download the entire code base and then submit updates to this code base in the form of change sets, or a set of files that they have changed. |
Tip #1: Tracking Current Changes
Tasktop and Mylyn automatically track the changes that you make as you work on a task, thus automatically creating a change set. You can view all of your current changes by opening the Synchronize View. Be sure to toggle the view model (circled below) until you are viewing changes as change sets.
Viewing changes using the Synchronize View makes it easy to quickly review others’ changes and to manipulate your own. The left pane in this example contains four change sets, one of which is expanded.
As you make changes when working on a task a new change set will be created and shown in the Synchronize View. Thus, when you have completed a task it is easy to commit only the relevant code. Open the Synchronize View, right-click on the change set, and select Commit. Occasionally you will work on a task and then abandon it, either because it seems infeasible or because priorities have shifted. In this case it is easy to remove all the changes you’ve made for that particular task by selecting the change set in the Synchronize View and selecting Override and Update (see screenshot above).
Tip #2: Connecting Commits with Tasks
All source code was written for a reason, but when viewing a particular file the original reasoning is not always clear. Fortunately, when using Tasktop/Mylyn tasks to track your work you can easily connect every line of code with the reason it was changed. This connection makes interpreting individual files easier and reviewing changes after-the-fact possible.
Creating and Configuring Automatic Commit Messages: When using tasks to track your work meaningful commit messages will be attached to every commit that you make. When you attempt to commit a set of files Tasktop/Mylyn will automatically populate the commit dialog with tasks that were active when you changed these files.
In the above example you can see that the file AbstractTaskAssociation.java is the only file in this change set and that bug 5256 was active when it was changed. To establish a connection between this change set and your task simply do not erase the commit message. Later, when viewing the changed lines in file AbstractTaskAssociation.java it will be easy to trace back to the relevant task (discussed below).
| Advanced Tip: Changing Your Commit Message |
| If your team decides that these commit messages are not exactly as they would like them to be they can configure the template by selecting Tasks -> Team in Window -> Preferences. They can use the following variables as well as any text to alter the commit message. You must keep the task URL in the commit message to enable easy task lookup, all other variables are optional. |
| Commit message variables: connector.task.prefix, repository.kind, repository.url, task.assignee, task.cc, task.description, task.id, task.key, task.keywords, task.lastmodified, task.notes, task.priority, task.product, task.reporter, task.resolution, task.status, task.summary, task.type, task.url, task.completiondate, task.creationdate, task.reminderdate |
From Code to Task: Enabling the automatic commit messages allows your team to trace from any line of code back to the last task that changed that line of code. Starting from a source file, use the context menu in the editor to select Team -> Show Annotations. This will populate the gutters of the editor with a line to task mapping.
In the example above you can see that method isValidUrl was last changed to ensure that URLs did not contain spaces. To open the relevant task use the context menu in the History View (automatically opened for you) and select Open Corresponding Task.
Viewing the task has several advantages for understanding a particular line of code.
Tip #3: Sharing Changes with the Team
In the open source community developers often need to submit a patch, essentially a change set, to address a particular bug. The developer in charge of that component will review the patch and either apply it or ask for improvements. The process of creating, reviewing, applying, and reapplying a patch is painless with Tasktop.
When a developer is creating a patch he (or she) usually begins with an up-to-date workspace. He then changes a few files to implement the fix. Once complete, he can use the Synchronize View to create the patch (left), which he can then attach to the bug using the Task Editor (right).
Sharing Changes with Your Team (click to enlarge)
Once the patch is attached to the bug he can revert to a clean workspace by Overriding and Updating his change set in the Synchronize View. If the patch is not approved he can, directly from the task, reapply the patch (below) and begin working on the necessary changes, again submitting an updated patch to the bug.
The developer reviewing the task also has the advantage of reviewing the changes in his workspace instead of reviewing a text file. He can apply the changes to his workspace and download the context (below) so that only the relevant files are shown in his package explorer. Reviewing changes in this way allows the developer to focus on only the changed code while reviewing, testing, and applying the patch.
Attach Your Context!
In this post I’ve shared with you the toolset that Eclipse and Mylyn/Tasktop offers for change sets. There are many opportunities to eliminate extra clicks and improve collaboration by taking advantage of this tooling. A great way to start using this tooling is to activate your Mylyn/Tasktop tasks and attach your context when submitting a patch. Attaching your context when submitting a patch makes it easier for other developers to review your patch, actually increasing its odds of being accepted.
 |
| Next time that you submit a patch… do not forget to check “Attach”! |
Nexus is more than just a repository manager. It is a project that has been developed using the same underlying infrastructure of Maven, and it has forced us to think about the different ways in which the components that comprise Maven can be integrated with other, more complex systems. It is a critical step toward a more mature Maven ecosystem which starts to encompass much more than just software builds. You can think of Nexus as the second major project to emerge from the Maven ecosystem – an ecosystem which includes both commercial interests as well as open source volunteers and community participants.
Sonatype is focused on improving the foundational infrastructure which will allow us to improve the quality of artifacts and their accompanying metadata in Maven Central and Maven repositories around the world. A lot of this is not especially glamorous work and though many people complain about the state of some of the Maven repositories, very few take action. Here are some of the things Sonatype is doing with Nexus to improve the state of the Maven ecosystem and expand its scope.
Any effort to improve the quality of the Central Maven repository needs to begin with the major feeder repositories. For years, we have been giving rsync access to many of the organizations with large feeder repositories like Apache and Codehaus. When we started this effort, we were optimistic that these organizations would take care of their Maven repositories. We thought that repository maintainers and projects would make sure that all artifacts were signed and that all POMs contained a bare minimum of useful elements such as “license” and “description”. With hundreds of projects pushing artifacts into their respective repositories on a daily basis, it has become obvious that without some mechanism to guarantee quality, without a well-defined process, the Central Maven repository will contain artifacts and metadata of questionable status. While the vast majority of artifacts have appropriate PGP signatures and metadata, the fact that a minority of (often very popular) artifacts lack proper dependency definitions or license elements means that we see a steady stream of complaints about the quality of the repository from our users.
These problems can be anything from one project trying to publish another project’s artifacts because they weren’t in Maven Central, incorrect, bad, or missing metadata, missing javadocs or source JARs, to invalid transitive closures. Whatever the problems are, the overall issue stems from the lack of process surrounding how artifacts are published to our feeder repositories, and how these artifacts are then certified to be published to the Central Maven repository.
Sonatype’s answer to this problem has been to provide tools that can automate the process of repository maintenance for Central’s largest customers – the main feeder repositories. We’ve provided a solution to the largest of the feeder repositories which allows them to use the Nexus Staging Suite to validate that all release artifacts contain the bare minimum of metadata, javadoc, and a valid PGP signature. As Ate Douma wrote in Monday’s post about using the Nexus Staging suite to support the Apache Portals project, we’ve supplied a solution that reduces the amount of error-prone, manual work associated with software releases, and we’re going to continue to find ways to address the needs of large, open-source enterprises with Nexus by providing Open Source projects and organizations with a free license and free support. Here is a list of some of the organizations with large feeder repositories that we are supporting directly:
With all of these organizations and projects using the Nexus Staging Suite, we are confident that the quality and reliability of artifacts and metadata will increase over time. The PGP signatures provide the security assurances organizations need, and the sources, javadocs and correct POM information like SCM information make for a better developer experience in the IDE. In M2Eclipse, for example, javadocs and sources can be dynamically retrieved as required and binary dependencies can be materialized to source from from SCM coordinates. This makes contributing patches to an dependent project an order of magnitude easier.
We are also fortunate to be working closely with Atlassian. We have Atlassian Crowd support in Nexus, so Nexus is an ideal fit for Atlassian and for organizations that make use of Atlassian’s compelling products. You can find Atlassian’s Nexus instance here. It’s just another validation point for us that Atlassian sees fit to use our products as part of their daily development. We have a lot of respect for the Atlassian folks, and we’ve standardized our entire development environment on tools like JIRA , Greenhopper, and Confluence.
Many users and projects have complained that it can take a while to get their artifacts in Maven Central so we’re starting to focus on reducing the time to reach Central. The biggest obstacle to automating the process of publishing artifacts to Central is one of quality. Artifacts would reach central faster if there was a better way to enforce a minimal set of quality standards. The legacy process involved projects uploading “bundles” to a JIRA project and repository maintainers manually inspecting the bundles to see if they complied with a set of standards.
In the previous section, I described how Nexus is already powering the major feeder repositories for the Central Maven repository. What we offer projects is described here. Basically we will help you cleanup, and migrate your project’s Maven repository to our hosted infrastructure and help you setup your project POMs to use Nexus’ Staging. Projects are setup with the default staging rules which ensure the presence of PGP signatures, javadocs, sources, and a POM which contains decent information. We provide all the instructions for the setup on the Maven side so there is little work you have to do in order to take advantage of this service. We are also providing a mechanism by which the standard bundle uploads, typically done via JIRA, can be handled by Nexus. Internally within Nexus the upload bundle is exploded and placed in a staging repository, as would happen if you performed the release against Nexus from your Maven build. We then apply the same staging rules to ensure quality.
We have already started rewarding projects with good Maven releases by automating their synchronization with Maven Central. Over time we are going to start enforcing standards for security and quality of metadata. If you have proper project metadata, PGP signatures, javadocs and sources your artifacts will fly into Central as quickly as possible. Projects that submit poor Maven releases are going to have a more difficult time getting artifacts into Maven Central. We’ll start to enforce these standards gradually and we’ll give the community time to adapt. Any tool that creates bundles for deployment to Central is capable of producing these artifacts. The staging rules don’t care how the releases were constructed. So use whatever tools you like, you’ll just have to pass a minimal set of requirements to make it into the Central repository. Over time this should greatly improve the quality of Maven Central.
For a long time we have been providing a way, through Nexus, and the stand-alone Nexus Indexer, to produce the Maven repository index. The repository index contains information about all the artifacts in the given repository including class file information and project identifiers. It is primarily used as part of IDE integration to help developers find dependencies based on artifact coordinates or class references, like import statements. Using m2eclipse, all you need to do to add a new dependency is type the name of a class into your code and search the index for matching dependencies. You can also search the repository index for all of the available Maven archetypes when you are creating a new Eclipse project. Both of these IDE use cases are possible because of the standard repository index format that was defined as part of the Nexus project.
The Nexus index format is also storing information about the presence of PGP signatures, javadocs, sources, and checksums. Using Nexus and other tools that can read the Nexus index format, you can aggregate multiple repository indexes together and perform quick searches across multiple public repositories (as well as your own hosted repositories). The Nexus indices from the OSS repositories around the world are proving to be a critical resource, we can tell because it is the most requested item from Maven Central. Index downloads amounted to 28TB of transfer last month.
The explosion of language choices has transformed the way most developers approach problem solving. Just four years ago it would have been normal to walk into a corporation and see Java at all levels of the stack. In 2010, most businesses have started to incorporate multiple languages and hybrid architectures into enterprise systems. A system designed today might use Ruby on Rails (running under JRuby) to power a web site which interacts with a set of services coded in Java. Services like Twitter rely on a foundation of Scala code executing on the JVM while other portions of the Twitter architecture use different languages and different technologies where they are most appropriate.
We are a polyglot industry, and while our software enterprises are run on a mixture of different languages, our development tools and build technologies are often locked into a single language or a single technology. A Ruby application is built using Rake, a Scala application is built using Sake or the Maven Scala plugin, and Java or OSGi applications are built using Maven. A Ruby library might generate and consume gems while a Java application might generate and consume JAR files. There is currently no single, consolidated “Tower of Babel” to help developers translate between different types of software artifacts. We’ve put a lot of effort into making the foundation of Nexus as agnostic as possible about what it is storing, and, because of this, we’re moving to add support for even more artifact types.
Nexus currently supports the two OSGi formats of P2 and OBR and we are just finishing our first draft of RubyGems support. Polyglot Maven will drive us toward a Polyglot Nexus. As part of the work we’re doing on Polyglot Maven we may find that different scripting language implementations have slightly different requirements for dependency management or provisioning runtimes, and we’ll be ready for that.
Next we’re thinking about ways to make statistics for a given project’s artifacts available to the project’s developers. We have already implemented user signup in Nexus and we are currently working on project signup as well. What this means is that projects can register with a given groupId, or set of groupIds, and optionally be provisioned a repository which can be operated by a set of users. Once a project registers we will know what slice, or slices, of the statistics they need to see. Our initial thought is that project statistics, number of downloads should only be made available to the public with the permission of each individual project. Brian and I along with Greg Luck and Dain Sundstrom have been working on a simple statistics mechanism that we hopefully can provide to projects early this year.
We’ve said it before (Bad Robot!), but after the Android 2.0/Nexus One developments, it really bears repeating: Google either do not understand or do not care about community once their immediate corporate goals have been met.
In the Bad Robot! blog, Greg commented on the disparity between Google’s talk of Android’s openness and their provision of early candidates of the cupcake release only to selected customers with NDAs. Google needed to get Android into the hands of developers to create the rich library of apps that would make Open Handset Alliance’s handsets attractive to customers and compete with the iPhone. Yet, by holding back on the releases, they left a lot of these developers in limbo, not knowing what the future held and being unable to plan how to allocate scarce resources or whether their work would even have to be thrown away. Bear in mind that most mobile developers are small companies or individuals, and so are greatly effected by this kind of treatment. Why screw with the very people you need for your success?
Eventually the cupcake release was made public and everyone picked themselves up, dusted off the software and got on with it. I, for one, was hoping that Google had learnt a lesson from the understandably angry reaction on the android developer lists. However, the launch of the Nexus One handset and Android 2.0 shows that Google have not. In fact, they probably weren’t even paying attention the first time around.
Other commentators have remarked upon the numerous ways in which Google’s release of their own-brand handset screws over their partners in the Open Handset Alliance and others in the industry, but what has been missed from most media commentary is the callous disregard Google have shown (again) for their developer “community” with Android 2.0. The fact is that the 2.0 release was announced on 27th October 2009, but yet it is still not available on the ADP1 development handset, and indeed may never be.
About a year ago developers were encouraged to pay $US500 for the handset in order to try out their apps on a real phone. In conjunction with HTC, the producer of the handset, Android updates for the ADP1 were made available for web download. Yet, despite repeated pleas from the community such as here and here, no release of 2.0 is forthcoming. Indeed, Google has not even had the courtesy to make an official announcement on the future of the ADP1.
So here we developers are again – cold shouldered by the corporate giant and yet expected to provide apps to lure customers to buy their phone. Google’s behaviour is also rather contemptuous of customers – some developers are receiving feedback that their widgets don’t work properly under 2.0, and yet are unable to recreate and fix the problem because there is no access to 2.0 on a dev handset.
So whilst I heartily agree with the rhetoric of Android and the Open Handset Alliance, I like the Android UI, API and linux/java-like platform, and I enjoy developing i-jetty, the realization of the rhetoric falls far, far short of what we should expect of a company like Google. Or …. is it exactly what we should expect of a company like Google?
This judge awards you nul points, Google.
This past weekend I wrote an app for my local town: it displays a route, and schedule information, for the town’s jitney. (In local terms, a jitney is a township-sponsored shuttle service for resident commuters to and from the train station.) You can see it at http://myjitney.appspot.com.
I’d like to discuss the short development history of this web application.
The original plan was to write a public, custom Google Map to be shared with the other residents using My Maps, a tool that allows users to create customized maps.
The problem with My Maps is that each marker had be placed individually, and that’s tedious: at least to me. What I needed was a programmatic way to feed a set of addresses, determine each address’ coordinates (you know, latitude, longitude) and place markers in a custom map.
For that I wanted the Google Maps API in Javascript, and if I had to use the Javascript API for determining coordinates, I might as well use it to build the map from scratch.
The prototype was written in pure Javascript, using the Google Maps API. It was really basic; routes were stored in JSON (natch), and the whole app lived inside a Google Maps widget.
To get started with the API I found an excellent Google Maps API Tutorial written by Mike Williams. The relevant entries were the entries on Markers and info windows, Polylines from XML and Geocoding Multiple Addresses.
In fact, I hacked a version of the geocoding example by adding all the jitney stop addresses, and from that I got the coordinates of most of the map markers. For those addresses that the API couldn’t parse, I used a tedious trial and error process.
The prototype took five hours to write: one hour to parse and codify the data, one hour for figuring out how to get reasonable coordinates for each address, and three hours to get my head around Javascript. For me, writing Javascript is like this: trial, error, trial, error, google, trial, trial, error, trial, error, google, but by the end, I got a map that showed all the jitney stops and their paths.
Two issues with writing the app in Javascript were my basic lack of comfort with Javascript, and also, the app didn’t render on my Android phone. I dreaded debugging a web app on an Android phone.
So I needed to rewrite the app, and by need, I mean want. 24 hours earlier I could have just manually built a damn custom map with My Maps, but now I was committed to code and more code. For the rewrite, I chose GWT. The Google Web Toolkit is a terrific piece of technology; you can write web applications using Java in Eclipse, my preferred IDE, and with a debugger. Since Google provides a GWT implementation of the Google Maps API, it was reasonable to port the existing prototype to GWT. The Google Plugin for Eclipse, a fabulous tool that combined GWT, AppEngine, and Eclipse, made it dead simple to deploy the app to to appspot.com which meant a permanent home to the app, along with a back-end infrastructure in case there was ever a need for servlets or a back-end data store.
(This is a great time to point out that I think that GWT is magic, and the GWT team are a bunch of magicians.)
It took four hours to write a feature-equivalent version of the application using GWT. Most of that time was spent familiarizing myself with the various APIs and getting reacquainted with GWT.
I didn’t want to go through the effort of learning how to work with the AppEngine database, so the rewrite still shipped the route data as java source turned into javascript. One of the great benefits of this turned out to be that the map loaded super-quick. So I moved the CSS to the HTML <style> tag, removing yet another server request.
Thanks to GWT the app ran perfectly fine on Android. But more important, thanks to GWT I could write code in a more familiar style, and easily manipulate the DOM outside the web page’s map object.
So I did.
I spent two more days adding features and polish: a pretty display of the schedule. A list of the routes so each could be viewed independent of the others. A visual indicator of when a jitney will next stop at a certain route.
One of the features was to replace the straight lines from stop to stop with paths along the street. The township had a map that laid out the supposed bus paths, so the trick was finding the coordinates where the paths turn. That turned out to be surprisingly easy with this small piece of Java:
map.addMapClickHandler(new MapClickHandler()
@Override
public void onClick(MapClickEvent event) {
System.out.println(event.getLatLng());
}
});
Then it was just a matter of running the web application and clicking each spot along the path, feeding the console output back to the web application as intermediate points.
 |
 |
|
Before
|
After
|
By Sunday night the app was done, and so was I. But it’s still not done. Even with such a small one-off project, there so many features that could be added. For instance, while the app runs on Android (and reportedly the iPhone) it’s not really built for small phones. The individual links are too small to be useful.
But also, I’d like to use Street View to show each stop. Unfortunately, while a Street View API exists in the Javascript API, there’s no equivalent in the GWT API. I probably spent about two hours before I recognized that it would involve another painful, endless cycle of trial, error, trial, error, google. Too bad.
<!–
–>
ANTLR 3.x tutorial Part 9: Interpreting Expressions using an ANTLR TreeWalker
See http://javadude.com/articles/antlr3xtut for more information.
delicious | 
digg | 
dzone
<!–
–>
<!–
–>
ANTLR 3.x tutorial Part 8: Interpreting Expressions using the GoF Interpreter Pattern
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
ANTLR 3.x tutorial Part 7: Interpreting Expressions while parsing the grammar
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
I went to a party last night. In the spirit of Christmas, we made donations to the Salvation Army, had some soup, and listened to a vibrant solo artist with a guitar. She had thirteen songs on her repertoire, each one covering some important aspect of life. In her hearty presentation of one of the songs, she talked about Ubuntu. That immediately caught my attention since I never bothered to find out why the well known Linux distribution is using that name. A name that I’m sure many of us encounter very frequently.
One of the sayings in our country is Ubuntu – the essence of being human. Ubuntu speaks particularly about the fact that you can’t exist as a human being in isolation. It speaks about our interconnectedness. You can’t be human all by yourself, and when you have this quality – Ubuntu – you are known for your generosity.We think of ourselves far too frequently as just individuals, separated from one another, whereas you are connected and what you do affects the whole world. When you do well, it spreads out; it is for the whole of humanity.
Desmond Tutu, 2008 (source Wikipedia)
I don’t confess to any religion. I believe that we alone (as opposed to some god) need to be held responsible for who we are and how we act. I don’t think there’s any judgment when we die. I do however, strongly believe that we are defined by our relationship to other people. Judgment is fairly immediate. And so is the reward.
A traveler through a country would stop at a village and he didn’t have to ask for food or for water. Once he stops, the people give him food, entertain him. That is one aspect of Ubuntu but it will have various aspects. Ubuntu does not mean that people should not address themselves. The question therefore is: Are you going to do so in order to enable the community around you to be able to improve?Nelson Mandela on Ubuntu (source Wikipedia)
Yesterday, I learned that Ubuntu goes way beyond Linux. Ubuntu is actually the foundation of all decent collaboration and as such, much, much bigger then a distribution brand.
What can you do to bring Ubuntu (in it’s original sense) into Eclipse.org?
In the previous entry, I covered the details and motivation behind using Property Simulation for the CDT’s static analysis. Now we will move onto the implementation details. The first thing we needed was a control flow graph. Luckily the Parallel Language Development Tools sub-project of the Parallel Tools Platform already provides a control flow graph implementation for the CDT. I modified this to encapsulate control flow edges since they are crucial to the Property Simulation algorithm. Thus the modified control flow graph properly contains both vertices (blocks) and directed edges. The version of the Property Simulation algorithm I implemented is the simple intra-procedural case. This means the control flow of each function in the C/C++ project is processed separately.
The algorithm traverses the control flow graph in a breadth-first manner, populating state information in a dictionary that maps control flow edges to sets of Symbolic States (each is a set of Property States and an Execution State). Each block in the control flow graph represents a node (either an expression or statement) in the AST. To model Execution States I have created a structure that operates on Boolean formulas. The trick is to then break if conditionals into atoms that are either true or false. I chose IVariable objects as the basis for these atoms. These objects are obtainable from the AST and have the advantage of maintaining a binding to their declarations. Therefore all references to a variable have the same IVariable instance associated with them. So an Execution State is conjunction of IVariable atoms and negations of atoms.
The performance benefit of Property Simulation comes from the way it groups Symbolic States and discards branches that cannot occur. The grouping function partitions all Symbolic States by their Property State, then the Execution States for all Symbolic States with a given Property State are joined. For example, suppose at a merge point we have two Symbolic States [opened, xy] and [opened, x!y]. Since they have the same Property State, we will group them into one Symbolic State. The Execution State is then a disjunction of xy and x!y. However, Execution States are conjunctions of variables and as such, disjunctions must be distinct Execution States. The goal is to find a minimal set of terms that imply the original Execution States. For our example, xy + x!y simplifies to just x since x implies xy + x!y. This leaves us with one Symbolic State [opened, x]. Every Symbolic State must be processed for each block in the control flow graph. Thus the fewer Symbolic States we have, the faster the algorithm performs. To minimize a set of Execution States we use the Quine-McCluskey algorithm for Boolean minimization, which works much like I just demonstrated. We further simplify this by substituting in any truth assignments we have learned from assignment statements.
Property States are the extender’s customizable component. A checker tracks some temporal property that is encoded as a Finite State Machine of Property States. Property States are implemented as an abstract class where the subclass handles decisions about state transitions by examining a statement or expression. A Finite State Machine of Property States is defined via an interface with methods to get all Property States in the FSM, along with the special initial and error states. To define your own checker, use the org.eclipse.cdt.codan.core.checkers Extension Point and have your checker class extend AbstractPropSimChecker. Provide your checker with the finite state machine encoding of your temporal property and the framework handles the rest.
We report errors via a callback by the algorithm with the AST node that triggered the problem, and the Execution State that causes the error condition to occur. The Execution State’s toString method displays the Boolean form in a formatted String. Here is an example checking for cases where fclose is called on an unopened file:
Checking for closing unopened files
The test program is a modified excerpt from the md5sum program. Notice in one branch the file is not opened if binary is false.
Of course, this implementation is not complete. The analysis needs to be extended to consider the global control flow of the program, rather than just individual functions. We can do this by generating summaries for each function, which contain mappings from input Symbolic States to where the function takes them upon its return. We consult the summaries at function call sites to simulate executing the function.
Unstructured code is another hurdle to consider. break/continue, goto, switch/case statements and multiple return statements all cause problems in analyzing the control flow. We have an assumption that a branch block has two children and a merge block has two parents, which the mentioned constructs break. Conditional and assignment parsing also need to be improved. Currently, we can only recognize conditionals that take the form: (var == literal), (var != literal), (var) or (!var). Similarly, pointer operations (dereferencing, arithmetic) cause parsing issues. Lastly, we need to be able to analyze more than one file handle at a time. This requires an implementation of a value flow graph to track file handles.
I have hosted my code in a Git repository on Fedora People. My Property Simulation implementation along with the open/close example checker are in the org.eclipse.cdt.codan.extension plug-in. My modified PLDT plug-ins are also in the repository. The stock static analysis framework is also included.
To check out the code:
git clone git://fedorapeople.org/~ebaron/codan.git
…or browse the Gitweb interface.
I have submitted a talk for EclipseCon that covers Property Simulation and the CDT. If you are interested, please comment. Thank you.
<!–
–>
Part 6 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
Part 5 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
Part 4 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
Part 3 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
Part 2 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
Part 1 of my video tutorial on ANTLR 3.x.
See http://javadude.com/articles/antlr3xtut for more information.
delicious | digg | dzone
<!–
–>
<!–
–>
<!–
–>
