build2be/com/e something is going on over there

For those of you that have been trying to integrate BIRT into JavaServer Faces (JSF) applications, the jsf4birt component library should make things easier. This library was created by Exadel and supports the rendering of BIRT-based reports on pages wthin JSF web applications. There are two components; a birtWrapper, and actuateWrapper.  The birtWrapper component displays BIRT reports [...]

Eclipse, Equinox and OSGi training wherever you are.

I had a great time at CeBIT (although it was very busy, we barely had time to breath). We had a great BIRT event on Thursday where more than 20 people showed up and I was really impressed on how the German audience was really BIRT savvy. This was the first time Eclipse was at CeBIT [...]

In my current project, I need to launch an external application and maybe execute some additional commands on this external application. Due to the very nature of the project, the whole system will always be run on Mac OS X. So I thought, "why not use AppleScript"? Turns out using AppleScript to launch applications is fairly

After reading the article Gregg posted I saw the comments at the bottom and wanted to pass them on from Karen.  I am not sure who Karen is but this is a pretty nice comment about their choice and the comments about Microsoft’s service consultants. Article link is here. from Karen: I wanted to share that we are [...]

Finally I accomplished what I planned to do for a long time: I updated my Eclipse RCP course materials to be test driven. I have included JUnit and SWTBot testing for almost a year now as a separate unit and I feel it’s time to take this to the next step. Every exercise is accompanied by a unit test method now which becomes green when the participant solved the tasks. This way, the participants learn good software engineering practices AND Eclipse RCP at the same time: In the first training units, all the tests are given. In the later chapters there is a fail("do it yourself") here and there to make the whole thing a bit more challenging. Fortunately, only 3 people registered so far, so I can improvise if things don’t work as expected (they never do when I try something the first time). If you want to jump right in and take part in the class, you’ll have to hurry up: The course is next week from Monday to Friday in Frankfurt am Main/Germany (unfortunately, I can only offer courses in German currently). More information about it: Eclipse RCP course (in German) If you want to learn about testing Eclipse RCP applications, you can also visit Eclipse UI Test Automation with SWTBot at EclipseCon 2010 - I’m looking forward to demo Eclipse UI testing together with Ketan, the author of the SWTBot framework. I would love to hear your feedback, do you think programming classes should be test-driven? Any other ideas what contributes to a good training class? 2010-03-08T17:51:00Z

The Eclipse Foundation and Eclipse member companies are pleased to announce the spring 2010 training class series. The training is an excellent opportunity for software developers and architects to learn more about Eclipse Rich Client Platform (RCP), Equinox & OSGi and Modeling technologies. Eclipse experts will lead the sessions, providing practical experience through classroom instruction and hands-on labs. Virtual and on-site classes have been scheduled in several countries from April 12 to May 28, 2010. Students who register at least 3 weeks in advance will receive a 10% discount on the registration price. 2010-03-08T09:25:00Zhttp://www.eclipse.org/org/press-release/20100308_training.php

My favorite time of year is about to start soon when it comes to open source development, Eclipse’s involvement with the Google Summer of Code (GSOC) program. All people involved in the Eclipse community should post their ideas here. It’s a good time to start posting ideas, as students will start looking at mentoring organizations in [...]

I read an interesting book over the weekend.  Groundswell  is a book from the Harvard Business Press written by Charlene Li and Josh Bernoff.  It discusses how to use social media to open up communication channels with your customers. For instance, how to harness the wisdom of the crowds to design better products and improve technical support.  The book describes the approaches of several companies and shows the ROI calculations for the investment in social media.One of the companies that was profiled was the Lego Group.   I learned that Lego is the sixth largest toy manufacturer in the world. Over a billion dollar a year business.  And somewhere between 5-10% of their sales go to AFOLs.  Adult fans of Lego.  In fact, they have an executive in charge of marketing to AFOLs because it is such a significant market.  AFOLs hang out in an online community called LUGNET.  The Lego Group's approach to social media is to have Lego Ambassadors in the AFOL community listen to the needs of the people who view Lego as a building material, not just a toy. And these amabasadors are paid for their services in Lego bricks, not money.  Pretty cool.So what does this have to do with Eclipse?  EclipseCon 2010 is having a e4-Rover Mars challenge where you have the chance to use Eclipse technology to maneuver Lego robots.  Go to EclipseCon and add four letters to the end of your name without paying for tuition.  AFOL at EclipseCon!

New version of the OSGi and Equinox book samples released.

The Eclipse Foundation today announced new initiatives to support the ongoing growth of the Eclipse Mylyn ecosystem. The open source Mylyn project is a widely extended framework for integrating task and application lifecycle management (ALM) tools with the Eclipse IDE. The project will create new sub-projects representing key IDE/ALM integration categories. New projects include: the "Tasks" project for integrating task and change management; "SCM" for integrating source code management; "Build" for integrating build management and continuous integration; and "Review" for collaborative code review. The new sub-project leadership will support a broader range of leading Agile vendors contributing to the ongoing evolution of Mylyn. 2010-03-08T14:20:00Zhttp://www.eclipse.org/org/press-release/20100308_mylyn.php

In the New Scientist's "Seven Theories of Everything" article:Causal dynamical triangulations (CDT) looks pretty similar to loop quantum gravity at first glance. Just as loop quantum gravity breaks up space into tiny "building blocks", CDT assumes that space-time is split into tiny building blocks – this time, four-dimensional chunks called pentachorons.The pentachorons can then be glued together to produce a large-scale universe – which turns out to have three space dimensions and one time dimension, just as the real one does. So far, so good, but there's a major drawback: CDT as it currently stands cannot explain the existence of matter.Yes, this sounds a lot like the CDT I know (s/pentachorons/plug-ins/g). And I look forward to CDT 5.0 and the explanation for the existence of matter!

I just come back from Cambodia, and it has been a wonderful time to think about how to simplify modeling technologies ;-) ;-) I have focused on the language we use everytime to make automation tools with modeling technologies : OCLThe OCL OMG specification has been released several times in the last 5 years. We use OCL at Obeo to make automation tools with Acceleo and ATL, and we think that OCL queries should be as short as possible to improve the template readability... We have defined several common OCL queries that are always used in our tools. We would like to have these queries in the standard library because we must define them each time we have to make a new tool with Eclipse modeling technologies.Here are some ways to simplify OCL I have discussed a couple of days ago with OCL experts. It isn't really easy to think about how to improve OCL because there were a lot of work on it and we can't change everything for compatibility reason. But, it is really possible to improve the language with little thing without breaking the compatibility.The first way for me to improve OCL is to add in the library the common stuff we define every time in our code generation and model transformation projects. When we navigate on models, the main things we do is to navigate around the current node, up and down : to get the children, the children of the children, the parent, and the siblings... OCL should propose shortcuts to go in these directions... Do we need a new function in the library or a new syntax element like in XPath? I don't know, but both will be better than what we have today. We often need to filter the types of the objects we would like to keep during this navigation. We spend a lot of time to explain how to get some specific children of the current node. As an example, here is the expression we have to write in OCL to get the descendant list of an object where we only want to keep the named elements :myCollection->select(oclIsKindOf(NamedElement))-> collect(oclAsType(NamedElement))It would be strictly equivalent to eAllContents(NamedElement) if the query eAllContents(OclType) was defined. Of course, we can define this query in one common library for all the projects of my company. I'd prefer to have such a useful service in the OCL standard library to prevent naming ambiguities. Today, everybody gives its prefered name to this query and it isn't possible to understand easily the work of someone else.For the same reason, we would like to simplify the syntax used to make filters on collections. myCollection->select(name ' ') could be replaced by myCollection[name 0]. The "select" function is used everywhere in OCL queries. This new shorter syntax could really improve readability. To be extreme, [...] should be the way to filter every kind of thing, for example if I want to filter the types of the objects in the current collection, I would write something like that : myCollection[Class].name myCollection[Class or Interface].nameIn the second example, "name" could compile because there is a common attribute called "name" both in "Class" and "Interface". The goal is to replace the oclAsType() function as often as possible.Another way to improve the readability of the OCL expressions is to add operators like '+' or '-' between collections :(property + method)->size() (list - element)->size() list + elementSome researchers think that we can already do that with operator overloading, but to go further, we would probably need generics in OCL.The opinions of the OMG guys would be interesting ;-)

A miss in the ATL syntax has just been corrected: the in keyword is now available for both input and output patterns. This enhancement will be available in ATL 3.1. It mainly allow to specify in which model you want to create elements, when the old semantics forbade the use of several output models conforming to [...]

It has been quite sometime since I wrote anything on this blog, twitter probably spoiled me. If you are following me on twitter, you probably noticed announcement of  a small eclipse plugin for automated refactoring for Legacy Code.  Before few months, I wrote an LTK refactoring mainly in Scala (yes, eclipse plugin in Scala language) to forward static method calls in a Java method to an 2010-03-07T18:04:28Z 2010-03-07T17:58:00Z Nirav Thaker noreply@blogger.com http://www.blogger.com/profile/07204297663478577248

With the emerging software craftsmanship movement, I have been noticing a lot of confusion out there as to what it is, whether it has any value at all or is just another fad, and whether it is the new silver bullet that trumps the older ways. To help sort some of the confusion out, I wrote a blog post last year titled: Software Craftsmanship vs Software Engineering.Did my opinion change since that blog post?So much has changed in the craftsmanship world since then, especially given that Obtiva, the Chicago agile consulting company I work with, hosted the first Software Craftsmanship conference here in Chicago, which ran at the same time as the Agile 2009 conference. And as a result, I certainly learned a few new things about the differences and similarities between software craftsmanship and engineering.Let's start with the summary of last year's blog post:... Software Engineering is not about over-engineering or heavy-weight processes like Waterfall; it is about delivering economical software that is reliable and efficient. Software Craftsmanship is therefore not in conflict with Software Engineering, yet in fact in harmony with it as it helps accomplish its goal through practical learning of software development with the guidance of experienced developers.Since that conclusion, a few more differences have emerged:Engineers often seem to believe that they can completely streamline the process of building software, with complete control and predictability. And, this belief seems to be process independent. In other words, even engineers who are strong advocates of agile often believe that if you do a, b, and c, you will get the results you want.Engineers often think that one has to learn all, most, or many best practices before successfully building software.Some engineers seem to think that best practices apply everywhere or in every situation. More experienced engineers are aware that different contexts require different best practices though.On the other hand, here are some observations I made from observing developers who have not had much software engineering background and thus have a bit more laissez-faire attitude that leans towards learning your skills through craftsmanship as opposed to a systematic study of best practices:Craftsmen see software development more as an art that emerges and less as a science that can be controlled, so they let time and experience shape up their skills in successfully completing software projects.Craftsmen often discover their own best practices from their experiences, which often better fit their situations.Craftsmen do not religiously follow even their own best practices, often transcending them when they do not make sense in a new situation anymore. They thus rely more on their intuition and gut feelings to succeed.It was not easy for me to spot these differences. They only started to become apparent after observing the way our top craftsmen at Obtiva have worked over the last year. After all, they often relied more on common sense and experienced intuition than industry best practices, and yet still succeeded at delivery as demonstrated by Mad Mimi (http://www.madmimi.com) for example.Even Tom DeMarco, one of the early key figures in the software engineering world, famous for the quote "You cannot control what you cannot measure", recently renounced the controlled development approach in an article posted by the IEEE, titled "Software Engineering: An Idea Whose Time Has Come and Gone?"Although I noticed these differences, let me clarify that nothing in software engineering's original definition or goals necessarily states that you must follow certain best practices or processes to succeed. It just happened that people who adopted the software engineering approach tended to gravitate more towards a controlled measured fashion to software development.For example, one of the common practices in eXtreme Programming is to develop features within iterations and then measure the velocity at the end of each iteration in order to determine your velocity and have a better estimate for your stakeholders. Software engineers following that process would often take that practice as gospel and believe that you will not succeed unless you build your software iteratively and measure velocity consistently. I know I have made that assumption in the past, and did not change my mind till I saw projects that succeeded without any iterative scheduling or measuring.As a software engineer who likes to question everything, I definitely wondered why. If I were to solve this following the software engineering discipline, I may ask what is the cost of iterative planning and what are the benefits offered by it? Then, I would check our current environment and see if it fits the cost/benefit of iterative planning. Though this is an important software engineering practice, many engineers often forget about it and just follow a process blindly out of comfort and past experience with it.To bring it back to my example, if the project is in the maintenance phase and all what the stakeholders want is bug fixes and tiny feature additions here and there, then why would they need to know the team velocity or do iterative development at all? The Kanban approach, which loses them the benefit of more accurate estimation, may fit them better since most software changes at that point would take no longer than two weeks anyways if not just a couple of days.However, as you notice, I was able to figure that out by applying software engineering disciplines only without having craftsmanship come into play. So, how does software craftsmanship fit into the story?Well, as stated before, software craftsmen often learn their best practices from their environment, their personal experiences, and their mentor's experiences. So, if an apprentice worked in some environment where most projects were in maintenance mode and far-term planning was rarely necessary, they would naturally succeed without any iterative development or velocity measuring, which may potentially baffle even some of the most experienced software engineers. However, the moment they hit a green field project, they will realize that their older methods are not working anymore because the stakeholders now need to know how long the next 20+ features will take for budget reasons. That is when they are forced to learn a new estimation approach, such as iterative velocity-based estimation.So whereas software engineering teaches you to learn as many best practices as available out there and gain the skill of analyzing any situation objectively to prescriptively apply the best practice that fits, software craftsmanship actually encourages you to learn best practices gradually out of your own experiences and mentor experiences, and thus naturally apply the best practices that fit without much analysis.So, what are the trade-offs between these two approaches?With software engineering, you have to work really hard at learning processes, best practices, and analysis techniques, and then spend quite some time gaining applied experience, before you can be a good software engineer. However, once you have gone through that hump, you have a very wide perspective on how software can be developed, which will make your opinion quite valuable to your team.On the other hand, with software craftsmanship, you can start developing production quality software much quicker by apprenticing with a few experienced craftsmen and learning the ways that worked for them and their projects. That will keep you motivated to keep learning and thus widening your perspective gradually to the different software development methods out there. The trade-off though is you may end up having to fail really hard at applying a practice that does not work anymore in a new situation before you learn another way. That happens even though the better way may have been discovered 15 years ago by other people who have faced the same situation long ago.In any case, one of the things that experience has taught me over the years is to try to stay as unbiased and detached as possible from any approach instead of defining myself through one. So although I have a master degree in software engineering, that does not stop me from learning the ways of software craftsmanship or becoming a software craftsman myself. And, I encourage you to do the same. 2010-03-07T12:49:00Z Annas "Andy" Maleh

There's a new API sample contributed to the Xerces-J code-base (in the schema-dev XSD 1.1, branch), which allows us to serialize a Xerces-J XSModel. This should be available in the upcoming Xerces-J release, 2.10.0.This could be invoked by using the Java class, xs.XSSerializer.Here's one of the use-case for this, as asked by colleagues in the community:http://mail-archives.apache.org/mod_mbox/xerces-j-users/200611.mbox/%3c4557B05A.6000808@gael.fr%3e

A few days ago, I started of a pretty length discussion on xml-dev mailing list about the following topic,"Should the W3C XML specification specify XML Schema (a.k.a XSD) also as a XML validation language, as it specifies DTD (Document Type Definition)."The XML spec seems to convey, that an XML document is valid, *only* if it's valid according to a DTD. I had a contention to this point, and started of a debate on xml-dev list related to this question. I argued, that since there are now newer XML validation languages like XSD, RelaxNG, Schematron etc, the XML spec now can modify the XML validation definition to refer to other XML Schema languages as well, rather than saying, that XML document is valid *only* if DTD is associated with the XML document.Unfortunately, may people who spoke on xml-dev, who have been working with XML for long, did not agree to this idea. But alas, I still feel I had/have a valid point about this :(I am referring to this threaded discussion again here, for records of this blog. Please follow this link, if anybody wants to read this whole discussion.

I'm trying to put up a post here, with few examples for assertions on XSD simple types, and also for complex types with simple contents, and testing them with Xerces-J XSD 1.1 implementation. The previous couple of posts on this blog, described assertions on XSD complex types having complex content (i.e, elements having "element only" or mixed content, and/or attributes).1) Here's an example, taken from Roger L. Costello's collections of XSD 1.1 examples, which he's published on his web site:XML document [1]: 100 XSD 1.1 document [2]: The above XSD 1.1 schema [2] constrains the XSD integer values, to only even ones (this works fine with Xerces!). XSD 1.1 defines a new facet named, assertion on XSD built in simple types, which the above example describes.Please note that, "assertion" facet (applicable both to XSD simple types, and complex types with simple contents) is conceptually different than "assert" constraint on complex types (some of the explanation, about this is also given below as well).The XSD 1.1 spec mentions, that the assertions XPath 2 "dynamic context" get's augmented with a variable, $value. The XSD type of variable, $value is that of the base simple type (in this example, the type of $value is xs:integer). The detailed rules, for using variable $value in XSD 1.1 schemas are described, here.It looks to me, that the ability to have an assertion facet on simple types, significantly enhances the XSD author's capability to provide many new constraints on simple type values, which were not possible in XSD 1.0 (for e.g, an ability to constrain integer values to be even, was not possible in XSD 1.0).For the above example, we could specify assertions to something like below, as well:(i.e, a set of two assertion facet instances)Or perhaps, specifying only one assertion facet instance as following, if user wishes, which realizes the same objective. This enforces that the simple type value should be even, and also should be less than 500. Also, there are no limits to the number of assertion facet instances that can be specified. To my opinion, an ability to specify unlimited number of assertion facets (and also the assert constraints on complex types), makes assertions a tremendously useful XSD validation constructs.Notes: Interestingly, the following facet definition achieves the same results as met by the 2nd assertion facet instance, that's described above:(this was available in, XSD 1.0 as well)2) Complex types with simple contents, using assertions:XML document [3]: 2 4 Here, the element "x" should have an attribute "label" with type xs:string. But the content of element "x" is simple (of type, xs:int for this example).Additional we also want, that the simple content value of "x", should be an even number.The XSD document for these validation constraints, is as follows [4]: The use of xs:assert instruction is stressed in this example.It's interesting to see, that if we change value of one of "x" elements as follows:21(I changed the first "x")Xerces fails the validation of XML instance, and returns following error message to the user:test.xml:2:22:cvc-assertion.3.13.4.1: Assertion evaluation ('$value mod 2 = 0') for element 'x' with type 'X_Type' did not succeed.Here, the XML validation did not succeed, because the value 21 is not an even number.3) The last example of this post is following:This describes the scenario of Complex types with simple contents. But here, the simple content get's its value by "restriction of a complex type". The previous example described Complex types with simple contents, using derivation by extension.The XML file remains same [3], while the new XSD document is following [5]: Please notice, how assertions are specified on the complex type, "X_Type" (shown with bold emphasis). Here, we have two assertion instructions (xs:assertion and xs:assert). In this example, xs:assertion is a facet for the atomic value, of the complex type (the value of complex type is simple in this case!). While xs:assert is the assertions instruction on the complex type (which has access to the element tree).The complexType -> simpleContent -> restriction, type definition can specify assertions with following grammar:... assertion*, ..., assert* (i.e, 0-n xs:assertion components can be followed by 0-n xs:assert components (this ordering is significant, otherwise the XSD 1.1 processor will flag an error).There could be other constructs as well, before xs:assertion here (and some after it. But anything after xs:assertion*, needs to be before the trailing xs:assert's). This is described in the relevant XSD 1.1 grammar at, http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/#dcl.ctd.ctsc.Notes: The XML Schema WG decided to have two different names for assertion instructions (xs:assertion and xs:assert), for this particular scenario, so that the XSD Schema authors could decide, whether they are writing assertions as a facet for simple values, or assertions for complex types (which have access to the element tree). If this naming distinction was not made in XSD 1.1 assertions, then specification of asserts in XSD documents, in this case would have caused ambiguity (i.e, the XSD 1.1 processor could not tell, which assertion is a facet, and which is an assertion for the complex type).Acknowledgements:I must mention that XSD 1.1 examples shared by Roger L. Costello, helped us fix quite a bit of bugs in Xerces assertions implementation. Our sincere thanks are due, to Roger. References:1. Reader's could also find this article useful, http://www.ibm.com/developerworks/library/x-xml11pt2/ about XSD 1.1 co-occurence constraints, which describes XSD 1.1 assertions facility in detail.I hope that this post was useful.