Stephane's thoughts corner…

Stephane Bailliez's thoughts on everything

With the abuse of the opensource model by most IT companies, the huge failure rate of software projects and the low rate of software engineers. It has been decided to create a new standard based on the Fair trade principles.

Software engineers employed by affiliated companies will have long-term minimum rate considerably above the long-run average market rate based on the incomes needed to support community projects such as opensource projects. Companies that are certified to meet the standard may for a fee display the appropriate Fairtrade and opensource symbols on their marketing and business documents. (The fee supports the work of the national monitoring body)

Although Fair trade software services are typically somewhat higher-priced than equivalent non-Fairtrade software services, for many services the difference is relatively small (as long as sufficient volumes are involved). This is because although a considerable premium may be paid to software engineers (often 50-100% above market rate), this forms only a small part of the final project price; The Standish Groups reports that most of the price is determined by invalid requirements, unclear business objectives, poor management decisions, unproper planning, lack of executive support and NIH/reinvent-the-wheel syndrom.

Fair trade is incentive-based and rely on consumer choice. Consumers are therefore given the opportunity to increase standard of living and quality of living and quality of life of software engineers working on opensource products through a sustainable market-oriented approach.

Considering the huge success of fair trade goods over the world[1], it is considered that this model could be financially viable. However we suspect that so-called ‘opensource IT companies’ that have been surfing on the opensource wave and indirectly lurring consumers into such a similar idea of fair trade and extorquing huge rates to consumers (including governments) without actually contributing back to community projects may have already doomed such model by losing the thrust and confidence of customers and making them believe that opensource does not work.

[1] See Communication of the European Commission on fair trade

A EUROBAROMETER survey, conducted on behalf the European commission in 1997 reported that 74% of the EU population say they would buy fair trade bananas if they were available in the shops alongside “standard” bananas. A total of 37% of EU consumers said they would be prepared to pay a premium of 10% above the price of normal bananas for bananas of equivalent quality produced according to fair trade standards.

Further analysis of the survey replies revealed that people with previous experience of fair trade products are much more likely to buy fair trade bananas, and would be willing to pay more for them. More than 9 out of 10 (93%) of consumers who had already bought fair trade goods would be prepared to buy fair trade bananas, and 7 out of 10 (70%) would pay a premium of at least 10% over the price of normal bananas.

PS: This stuff is a joke and was devised by myself after a few glasses of Champagne over lunch with a group of friends. Still I believe there is some truth in it.

A report from JavaOne

Two NetBeans core developers had a session on How to Write APIs That Will Stand the Test of Time which was as disappointing as I expected it would be. I sometimes wonder how people have the guts to stand in front of 500 developers and talk about trivialties like they did.
[...]
Netbeans remains as uncool as it has always been, no matter how hard Sun tries to shove it down your throat. They take the route of Wizards, Drag&Drop, Code Generation, etc. and it will be interesting to see how far they can go with this approach regarding development and maintenance of mission-critical enterprise applications.

I installed NetBeans 5.5EAP some time ago and really need to get into it. I was interested to see how the UML and Profiler module stand. Now that Sun managed to understand somewhat that it did not make sense to create 3 IDEs (Creator, NetBeans, Studio) maybe it will get somewhere !

What I can say already from basic superficial use:

• Creating a new project is totally inflexible. Assuming I have a folder populated with some docs or basic empty directory to structure the project. NB will simply refuse to create a project here, because “the folder is not empty”.
• The creation project wizard does not even ask what directory structure you even would think about and it blindly creates a src and test directory. Once the project is created you have to remove them from the projects and add new one.
• A NB project is polluting your workspace with a highly visible ‘netbeans’ directory.
• A NB Java project is tighly integrated with Apache Ant. A generic build file with default properties is created initially. It is extremely unusual at first as there is no possibility of changing anything (such as the name of build directory) from the IDE. You have to go to the ‘netbeans’ directory (in every NB project…) and change directly the properties.
• Obviouslly, you work the NB way or you’re not.
• The NB VCS design is … unusual. There is no abstraction layer at all and for instance, after installing the subversion module (not a default in NB5.5). You find yourself with both cvs and svn menus in your project. I cannot find any sense for this except a NB design flaw, a project is associated to a single VCS, not 2 or 3 of them at the same time, right ?
• NB settings can be changed via the options. As a default it is in ‘basic mode’ which show you nearly nothing, until you realize there is effectively a ‘advanced’ mode that you can switch to. Unfortunately, unlike IDEA, this mode is not persistent and every time you come back to settings, you have to switch again to advanced mode. Highly annoying.
• There is default integration with the bundled Apache Tomcat 5.5.16 and SJSAS 9 (Glassfish). It is not possible to add a generic integration such as in IDEA (with Jetty for example) as you only have a choice of predefined server such as SJSAS, Tomcat 5.0, Tomcat 5.5, Weblogic 9 and JBoss 4.
• Changing settings is a bit baffling. For servers for example, you have to go to Tools/Server Manager and some (few) other related settings are in Tools/Options.
• In the Tools menu a ‘Java Platform Manager’ is actually a repository of J2SE definitions. ’Java Platform Manager’ is a pretty unusual name especially as internally, the root node is call J2SE and the internal name of each ‘platform’ is called ‘JDK’. That’s very inconsistent.
• For any IDEA user, the code analysis is falling short. It is clearly thousand of miles away from all helpful information that IDEA provides through Intentions and Inspections. Sometimes you have some kind of Notepad feeling.

That might not explained fully why Eurotunnel debt is worth $11.77 billion, but the following should give some insight of a serious business flaw, which could be summed up as “How to make customer life difficult and slow down marketshare adoption“:

• It is not possible to pay with a credit-card company or on behalf of someone else. To pickup your ticket at the train station, you need to give your ID (fair enough) AND the credit card used.
• They can send it via mail though… (no, NOT email and no fast-courrier, this is snail mail)
• If you want your company to handle it, you need to call the customer support, ask them to send you a form that you will need to fax so that they check the company credit card.
• You cannot buy 2 return tickets in Business Premier, the daily transaction on a credit card is limited to €860 and a Business Premier return ticket is €499-€580.
• You can buy one ticket every 24h though…

This is not even funny.

I apologize to my fellow Apache friends and Maven committers/PMC members, but let me state that clearly: Maven is absolutely unusable for any projects making heavy use of opensource projects. It supposedly make more you more productive by managing the dependencies but it just hides the fact that you are building using junk.

It could be said that such a mess is the fault of all people writing invalid POMs or using totally stupid naming conventions for their projects and stuffing that into a public repository such as ibiblio or mergere. It certainly is. Looking over the disaster on any maven repository will horrify anyone.

Maven is also guilty of having such a non-lazy dependency mechanism and conflict strategy that it will, as a default, try to pickup as much as it can online including bad POMs of versions it does not even need. Which will be overly difficult to detect, it will then fail every now and then with cryptic messages and no options that trial and error with -X (-X like debug) to figure out by reading questionnable log messages. I’m here also not mentioning the fact that you can find different POMs of the same project on different repositories.

As most people may not know (it is not documented rather than on a wiki page somewhere far away from any place where you would expect to find docs) which says it is, Maven 2 includes somewhere a so-called versioning range with mathematical syntax such as [1.3,) to say x >=1.3. As a default when you write a version on a dependency, it is called a ‘soft version’, which is bound to change as it will resolve with the ‘nearest‘ version found in the graph.

The not-so funny thing, is that POMs need to be maintained over time as, as you would expect, a component A depending on B 1.1 may not work anymore with B 2.0. And 2.0 > 1.1, right ? It may still work, but it may not. How do you know ? Well, for that you would need metadata in B to say that 2.0 breaks the compatibility cycle with previous 1.1 version. But that does not exist. AFAIK. You will find it yourself.

Point of case of what you can find in the central repository (it is used by EVERY maven user). Look over http://repo.mergere.com/maven2/commons-collections/commons-collections, you will find along ‘normal’ versions 2.1, 3.1, some obviously ‘timestamped’ snapshot with version numbers like: 20040102.233541.

As you can expect, 20040102.233541 > 3.1 and that will remain quite a few centuries to get over that.

And depending if you are lucky or not, on the mass of existing invalid POMs. With transitive dependencies, you may not realize that you are actually using a totally invalid version such as the one above. A great news for the build manager out there that tries to make sense of dependencies.

Next, we have the multiproject case. Some pattern that arise is to have a project made of multiple artifacts (jar). In Maven this is better handled by duplicating the structure in the repository so that it becomes even less manageable. Now the worst case I have seen is the following: module-option1-2.7.8.jar, module-option2-7.5.4.jar which are options of module-core-1.0.jar. That are part of the release module 1.0…uh ? why this naming scheme ?

To make it clear of what was done, imagine the following: there is product, which is splitted in sub-modules: core, modulex, moduley. Pretty common right ? You are releasing product 1.0, so you expect to have product-core-1.0.jar, product-module1-1.0.jar, product-module2-1.0.jar, right ? Especially as those adapters are part of the release and depends obviouslly on the core.

Not so fast ! Some think that having product-core-1.0.jar, product-modulex-2.4.2.jar and product-moduley-7.5.2.jar is much better because product-modulex-2.4.2 is an adapter over productx 2.4.2 and product-moduley-7.5.2 an adapter to producty 7.5.2 ! I have yet to figure out how this will work later if there are 2 releases of product and productx or producty has not changed, but…. you tell me what is the difference when you have in your classpath product-modulex-2.4.2 that works and…product-modulex-2.4.2 that does not….because one depend on product-core-1.1 and the other on product-core-1.3… Good luck finding that out !

Maven people used to say that Ivy should avoid duplicating the maven2 repository, but what’s the point ? Most of it is totally invalid anyway. It looks like anyone can actually submit any kind of POM without any validation process and even more sneaky, it is known than in the past (and it apparently is recurring), some people used to replace existing releases with new jars coming out of nowhere for whatever reason. So if you want control over which release you use, the last thing to do is certainly to avoid any using online repository.

As for scope management which could be a good idea in itself is obviouslly not working ‘sometimes’, making things even more black magic. Identifying a consistent behavior between the dependency logic is a challenge and bug reporting not an option.

Spending countless hours managing such mess and having to deal with so many undocumented ‘features’ is NOT a time saving in any way. It may give you a sense of productivity at first by making things magically work without doing too much boostrap effort but you’ll pay 10 times the price later. On this aspect, it is similar to what was the dreadly (un)famous JBoss Unified ClassLoader (UCL) which was initially dumped to ‘make it easier‘ for developers. On the end it opened such a massive Pandora’s box in production environment and with legacy code that Orwell’s ‘War of the Worlds’ vision looks like paradise.

I don’t like the fanatism of some people that blindly think without acknowledging flaws that Maven is the best thing since sliced bread. I have never seen a project other than a pet project run without any problems. Looking over Apache Directory and Apache Geronimo which both handle a reasonable amount of modules seems obvious that there are major deficiencies. Yet again, it benefits from the hard support of Maven core developer to solve any issues and it just breaks every now and then with messages such as “build failure”, “can someone build this ?” etc….

Maven promoting work in total isolation due to the presence of the cache in the user machine, any change in the availability of some dependencies will break everything and people having the dependencies already in the cache for some reasons will simply NOT realize it until someone fresh and clean comes to the project and build it (if you have a continous build environment ALWAYS clean the cache between each build !)

While Ivy is far from perfect it provides a much much much better dependency management. What I don’t like with Ivy is that they make the classic mistakes of doing opensource the wrong way:

• Using a forum rather than a mailing list
• Documentation available only on their (slow) website which comes out of nowhere instead of at least a wiki. And as the documentation is loaded with outdated, invalid or incomplete information it slows down severely its adoption rate and makes it even more difficult to contribute back documentation fixes.
• The code is empty of any comments making it even more difficult to document it.
• Development is not truely open
• Features over features without documentation.

Yet Jayasoft are responsive with bug reports, but the problems above make it really really hard to follow this project and contribute back in an effective manner without doing 3 times the amount of necessary work.

Back to fix and sync ivy files and poms.

Sorry for the rant ! But damn, I’m sooooo pissed off I needed to express it ! @#$* !

Product name omitted to avoid any embarrassement:

The default conf mapping not only defines the conf mapping to use when no conf mapping is specified for a dependency in this PRODUCT file, but it also modify the way PRODUCT interprets conf mapping with no mapped conf. In this case, PRODUCT will look in the default conf mapping and use the conf mapping defined in the default conf mapping for the conf for which there is no mapped conf.