In this article, consultant Sebastian Tardif looks at how component-based solution can help manage the diverse aspects of software development, from promoting reusability awareness to better communication and better documentation.

Read the article here.

Its a reasonable article as it goes, but doesnt worry about the negative consequences of modular development.

The key one is that you need good clean interfaces between modules, because if not then they arent really modules, they are just bits of source built in different places. If you plan to release stuff to different schedules (as the article implies is sometimes good), then these interfaces had better be stable. Refactoring across modules only works if all modules are released in perfect-sync.

That miracle that is java classloading introduces another problem: accidental version mismatch. If you add version metadata to every JAR you can catch this. You should also version tag every jar you use "myapp-1.3.4" as this makes it much easier to diagnose problems from a classpath, directory listing or over the phone.

Note that both Maven2 and Ivy have ant tasks to do library management, in which you declare in XML files or build files which JARs you want. In a big project you should not only use one of these, you should try and unify your version declarations to one place, so that you can upgrade to a new version of log4j or even j2ee by changing one file; all modules picking up on the change.



It is hinted at where the paper says "it's better to release the shared components independently". Once you have shared code that is released as separate, sel

Note that both Maven2 and Ivy have ant tasks to do library management, in which you declare in XML files or build files which JARs you want. In a big project you should not only use one of these, you should try and unify your version declarations to one place, so that you can upgrade to a new version of log4j or even j2ee by changing one file; all modules picking up on the change.

<p/>
Better yet, build your applications on top of a framework that supports component-based development.
<p/>
I have the great fortune to work for a company that builds everything on top of the Eclipse OSGi framework. The Eclipse OSGi kernel is not just for developing IDE-like applications - we use it as the kernal for web applications and desktop applications. Our applications consist of a bunch of 'bundles'. We customize and extend our applications for each client by adding or subtracting bundles.
Each bundle declares version and dependency information. The Eclipse runtime and update facilities manage the dependencies for us, making sure that bundles always get access to the correct version of thier required bundles.
<p/>
It has got so that I could not even think about developing anything significant without using Eclipse/OSGi.

Note that both Maven2 and Ivy have ant tasks to do library management, in which you declare in XML files or build files which JARs you want.

And has the capability too via 'dependencies' task. Works like champ with Maven repositories.
http://kgionline.com/annoying/java/case_for_cjan.jsp

And there is JSR277 that addresses modularity in Java.

Note that both Maven2 and Ivy have ant tasks to do library management, in which you declare in XML files or build files which JARs you want.

Ant has the capability too via 'dependencies' task. Works like champ with Maven repositories.
http://kgionline.com/annoying/java/case_for_cjan.jsp

And there is JSR277 that addresses modularity in Java.

Its a reasonable article as it goes, but doesnt worry about the negative consequences of modular development.The key one is that you need good clean interfaces between modules, because if not then they arent really modules, they are just bits of source built in different places.

I wouldn't count this as a negative. I really believe that you need good clean interface design regardless of how you organize your code. Otherwise you just end up with a tighly coupled mess. Version numbering is one way to deal with 'breaking' the contract between clients and components. If you need to change the interface all that much then you may really need to consider writing an entirely new component.

If there's one design pattern that should be "abused" regularly then it's the strategy pattern.

Open sourcing components provides free code reviews, bug reports, and bug fixes, which results in better quality and more flexible and cheaper components.

In order for the above to be true, you need to have a product or framework that is widely used. Just because you open source some code does not necessarily mean that anyone will use it, review the code or report bugs.

However, using a component based approach, allows for developers to more readily use existing open source components.

Check these articles for more details (especially "the why" behind the scenes):

http://www.jaxmagazine.com/itr/news/psecom,id,21908,nodeid,146.html

Cheers,
Lofi.

Maintaining 2 versions of buildpath and project definitions, one for IDE(eclipse) build and one for batch build is a pain. The article does not describe the best soulution to this problem:

c:\cmd>maven eclipse

This way you have ONE source for your project definition in maven and kan generate a mirror project for eclipse.

You only need once to set MAVEN_REPO variable in eclipse to point to the location of your maven repository.

Thank you Sébastien for putting this domain in focus with a short and to the point article.

Me and several colleagues have in various situations for several years worked with issues concerning componentization, versioning, dynamically building etc, and have in many iterations evolved ideas and processes.

At the present time we're working hard with a project derived from all this that we call 'Buckminster', which is an Eclipse technology project. Please visit us at Buckminster/Eclipse and judge for yourselves. We're more than happy to answer any questions you may have.

I took a brief look at Buckminster. I found neither an open source project that uses it nor a document that walks me through a simple situation but complex enough to begin to see some benefits.

I’m a little worried about the fact than in Windows the command line application, AMTOOL 0.1.0, was an EXE and not a Java application. Now it’s all around Eclipse. How usable is Buckminster without Eclipse in a scripted environment?

Why should I care if Maven and Ivy are already doing most of what I need and I know that they are implementing new features faster? The case could be made for Buckminster’s usefulness by showing that its exclusive features solve problems that repeat themselves often.

There is an added benefit when a framework that manages recursive dependencies has broader support. For example, Maven Project Object Model (POM) that includes dependencies has already been created by many of the open source projects/components: http://www.ibiblio.org/maven/

Buckminster could greatly increase its user base if it manages to make itself the best/first tool/framework to support OSGi and JSR 277 while the popularity of Eclipse and JSR 277 (Java Module System) increases, which will publicizes the need for runtime support like OSGi provides.

However, Maven already has some OSGi support via a plug-in that generates the manifest for OSGi bundles: http://mavenosgiplugin.berlios.de/. Maven has also some support in Eclipse, such as http://mevenide.codehaus.org/mevenide-ui-eclipse/index.html; Ivy has this one http://www.jayasoft.org/ivyeclipseui.

Let me know if I overlooked something.

References:

JSR 277: Java Module System, http://www.jcp.org/en/jsr/detail?id=277

OSGi: http://www.osgi.org/osgi_technology/index.asp?section=2, http://www.eclipse.org/equinox/,
http://en.wikipedia.org/wiki/OSGi

When Maven encounters Eclipse: https://www6.software.ibm.com/developerworks/education/os-mavenecl/index.html

Eclipse goes Server-side!: http://www.infonoia.com/en/content.jsp?d=inf.05.07

Let me first state that things are considerably different than what they we're when my post was made. In particular, we work on documentation on our wiki, see http://wiki.tada.se/display/buckminster/Home.

I took a brief look at Buckminster. I found neither an open source project that uses it nor a document that walks me through a simple situation but complex enough to begin to see some benefits.

This is not unexpected, simply because we're not at a release stage yet - there are several people and organizations that we have close contact with and discuss how to reach that goal. We're well aware of the need to provide 'walkthroughs' of various kinds. We are investigating how best to provide that - for example, we're impressed by the JBoss concept of 'trailblazers' so that is the tentative approach.

The intention of my post was mostly to spark some interest and discussion in light of the article points made.

I’m a little worried about the fact than in Windows the command line application, AMTOOL 0.1.0, was an EXE and not a Java application.

I fear this stems from a point I perhaps was not clear about in my separate mail to you - 'amtool' is the prior generation (which we started as 'assembly manager' and then unfortunately dubbed 'buckminster') but resides on tigris.org. That project is effectively dead, really never used. The relevant main link is http://www.eclipse.org/buckminster/.

Now it’s all around Eclipse. How usable is Buckminster without Eclipse in a scripted environment?

Very! We put special emphasis on the fact that Buckminster must be runnable from the command line. Search the wiki for 'headless'.

Why should I care if Maven and Ivy are already doing most of what I need and I know that they are implementing new features faster?

Well, the reason to select Buckminster instead of something else is by merit, of course. And whether such merits makes sense for you is for you to decide obviously.
We believe we approach the problem with innovative, different and more far-reaching solutions, thus enabling Buckminster to tackle more/different problems. A (perhaps somewhat dated) document trying to compare some issues between Buckminster/Maven/Ivy/Eclipse core is here: http://wiki.tada.se/display/buckminster/Buckminster+Compared.

For example, Maven Project Object Model (POM) that includes dependencies has already been created by many of the open source projects/components

Yes - which is why Buckminster can read and use components from a Maven repository (among several others, both repository types and component types). Furthermore, Buckminster may be implemented in Java, but is agnostic as to what it manages (the world consists of more than jar files).

Buckminster could greatly increase its user base if it manages to make itself the best/first tool/framework to support OSGi and JSR 277 while the popularity of Eclipse and JSR 277 (Java Module System) increases, which will publicizes the need for runtime support like OSGi provides.

I'd say that Buckminster shines in this area already. Since we're being part of Eclipse and thus a user of OSGi, we are OSGi compatible. In fact, the main built-in version scheme we use is OSGi.

As for JSR-277, we follow the mailing list with interest and has also been part of the discussion. Given the high level of abstractness and extendability of Buckminster, we're confident to be able to work with whatever the final result will be. Currently though, JSR-277 is more aimed at runtime/deployment issues and not with the peculiarities of development.

However, Maven already has some OSGi support via a plug-in that generates the manifest for OSGi bundles...(snip)...

A major point of Buckminster is that it doesn't stipulate how a component is described, nor does Buckminster have to generate anything in the general case. We can recognize the Eclipse component types (plugins, features etc). We can also recognize Maven component types - as well as others, and we can extend Buckminster as needed. That said, with Buckminster being rich in what it can handle, the 'native' component description can be added to.

As we're doing true Eclipse plugins, there is no need for even talking about 'integrating' - Buckminster *is* part of Eclipse. Or, if you absolutely don't wish to use the IDE, just use the headless stuff and your favourite text editor.

There is more - but please see the wiki for more in depth!