Netbeans+platform+maven

Efficient development
of large NetBeans Platform
applications
with Maven
Fabrizio Giudici, Senior Java Architect
Tidalwave s.a.s - fabrizio.giudici@tidalwave.it

Friday, September 24, 2010

Agenda

Efﬁcient development of large NetBeans Platform applications with Maven 2

Agenda

• Introducing the NetBeans Platform


Agenda

• The NetBeans Platform Ant Build Harness


Agenda

• Limitations of the NetBeans Platform Ant Build Harness


Agenda

• Introducing Maven


Agenda

• The NetBeans Platform Maven Plugin


Agenda

• Optimizing NetBeans Platform Maven projects


Agenda

• Reuse of third parties’ libraries (NBPWR project, optional)


Agenda

• Reuse of third parties’ libraries (NBPWR project, optional)
• Conclusions


About the speaker


About the speaker

• Senior Software Architect, Mentor, Technical Writer
• Fourteen years of Java Experience (JSE, JEE, JME, etc...)
• Sun Consultant since 1998, Oracle consultant since 2010
• Author of a number of open source projects
• Speaker at JavaOne, Devoxx, Jazoon, JAX Italia and other events
• Member of the NetBeans Dream Team
• Co-leader of JUG Milano
• Java.Net blogger at http://www.java.net/blogs/fabriziogiudici


Ant vs Maven?


Ant vs Maven?

• What this presentation is not:


Ant vs Maven?

• A “X is better than Y” sermon


Ant vs Maven?


• What this presentation is:


Ant vs Maven?


• An analysis of scenarios where Maven may serve better than Ant
• An analysis of Maven-based NetBeans Platform projects


Ant vs Maven?



• Some basics about the NetBeans Platform and Maven assumed


Ant vs Maven?



• Some basics about the NetBeans Platform and Maven assumed
• Based on the speaker’s experience of four years with Ant &
the Platform, then replaced by Maven


Related talks at JavaOne 2010

• S314388: Maven 3.x: The Evolution of Enterprise Java Build
Infrastructures
• S314711: Building Software with Rich Client Platforms
• S313667: Swing OSGi Modular Desktop Application Framework
• S314266: The Cutting Edge of Desktop Software: The
NetBeans Platform in Practice
• S314141: Patterns for Modularity
• S313338 Getting More Out of Your Hudson


The NetBeans Platform



• The best framework for Swing desktop applications



• Provides “plumbing” for many common tasks



• Modular, plugin-oriented, scalable



• Since 6.9 provides integration with the OSGi framework



• Used also as the foundation of the Oracle NetBeans IDE



• Very popular in all the industrial segments


... more success stories at
http://netbeans.org/features/platform/showcase.html

• Very popular in all the industrial segments


The Platform Ant Build Harness


• By default, the NetBeans Platform uses Ant


• for building itself (together with the IDE)


• for building Platform-based applications



• NetBeans Platform Ant Build Harness



• Set of standard Ant scripts, tasks and extensions



• Can be used from the IDE or by the command line



• A minimum preliminary setup is required




• Very good starting point for beginners




• Very good starting point for beginners
• Many people use it even for complex applications


Using the Ant Build Harness



• Two ways of using the harness



• Supplied with the IDE and referred to by the project



• Needs a local environment setup to “point” to the IDE installation folder




• Embedded with the project




• Possible clashes if the used Platform version is different than the
NetBeans IDE version




• Possible clashes if the used Platform version is different than the
NetBeans IDE version
Key concept: the Ant build harness is
a speciﬁc build system for the Platform projects


When Ant might not scale



• With a large number of modules



• Good design practices lead to many small packages




• With multiple projects with many inter-dependencies




In other words: how to reuse modules?




• Might be a single project that’s worth while splitting





• What’s a module of the NetBeans Platform, BTW?





• A collection of cohese packages exposing an API





• Packed in .nbm ﬁles (.jar + metadata)


Only a subset of dependencies shown

OpenBlueSky

• With a large number blueMarine
blueMarine
of modules
blueMarine blueMarine
Metadata Semantic Media PDF

blueMarine blueMarine blueMarine blueMarine

•
Core Catalog Gallery LightTable
With multiple projects with many inter-dependencies
forceTen
blueMarine
Geo

blueMarine

• Packed in .nbm ﬁles (.jar + metadata) for
blueOcean blueBill Server
blueBill
Android


Pushing the Ant Build: Suite Chaining

Slide in a graph showing a
dependency graph: Suite
--> Platform



• Platform: a self-contained set of .nbm modules

--> Platform



• The NetBeans Platform is obviously one example of a platform

--> Platform




• Module Suite: a set of .nbm modules depending on a Platform

--> Platform




• Any NetBeans Platform-based project is a suite

--> Platform





• It is possible to have a Suite depending on a Platform +
another Suite (“Suite Chaining”) Slide in a graph showing a
--> Platform





--> Platform
• Doable, but cumbersome





--> Platform
• Doable, but cumbersome
• Doesn’t scale well with multiple suite levels


Reusing modules with the Ant build harness



• It’s possible to create a custom platform, assembling
arbitrary .nbm modules



• Of course, dependencies must be satisﬁed




• You can assemble a Platform feeding the .nbm artifacts from a
project to another project




• This approach (apparently) scales well beyond the ﬁrst level




• http://weblogs.java.net/blog/2007/11/03/netbeans-rcp-beyond-suite-chaining





• NetBeans 6.7 introduced support for reusing modules





• NetBeans 6.7 introduced support for reusing modules
• http://wiki.netbeans.org/DevFaqHowToReuseModules


Limits of Custom Platforms with Ant


• Conceptually simple, the cumbersome part is automating the
“feed” of NBM artifacts from a project to another


• Personal experience


• Wrote a couple of custom Ant tasks to enhance the original
harness with artifact management facilities


• Reached some high complexity when trying to share javadocs and
sources too


sources too
• Sources in particular are important, e.g. for proﬁling etc...


sources too

• At this point I moved to Maven...


sources too

• At this point I moved to Maven...

• I’m recommending to customers - of course your mileage may vary

Introducing Maven


Introducing Maven

• A different building tool than Ant


Introducing Maven

• Standard lifecycle (= sequence of phases) applied to projects


Introducing Maven

• Projects are described by a POM (Project Object Model)


Introducing Maven

• Composed of plugins attaching goals to phases


Introducing Maven

• Provides efﬁcient artifact management with repositories


Introducing Maven

• more info later


Introducing Maven

• more info later
Ant: interpreter
to create build scripts


Introducing Maven

• more info later
Ant: interpreter Maven: standard, well deﬁned
to create build scripts build system that can be customized


Introducing Maven

• more info later

Programmatic

Introducing Maven

• more info later

Programmatic Declarative

Inheritance and composition



• “Object model” means it implies some typical OO practices



• Inheritance



• Inheritance
• A module POM can inherit from a parent POM



• Inheritance

• Composition



• Inheritance

• Composition
• A module POM can import parts of other modules POM



• Inheritance

• Composition

• Both practices reduces entropy (DRY)



• Inheritance

• Composition

• Still verbose because of XML (but it’s syntax, not semantics)



• Inheritance

• Composition

• Still verbose because of XML (but it’s syntax, not semantics)
• Maven 3 allows for more compact syntaxes (e.g. Groovy)


Artifacts, dependencies, repositories



• Each module



• Each module
• Possibly depends on other modules artifacts



• Each module
• Produces a single artifact (which might consist in multiple ﬁles)



• Each module

• Each artifact



• Each module

• Each artifact
• Has got unique coordinates: groupId, artifactId, version, packaging, classifier



• Each module

• Each artifact
• Can be retrieved from a local / remote repository



• Each module

• Each artifact
• Can be retrieved from a local / remote repository
• Can be published to a local / remote repository


The NBM Maven Plugin



• A speciﬁc Maven plugin for the NetBeans Platform



• Deﬁnes the ‘nbm’ packaging



• Creates nbm artifacts



• Manages branding



• Creates .zip and JNLP distributions



• Properly runs the project being developed



• Properly runs the project being developed

• Out-of-the-box support by the IDE, better integration with 6.9


Further beneﬁts If you have time, demonstrate e.g. FindBugs integration.
In any case, connect to the Tidalwave Hudson instance
and show some stuff


and show some stuff

• Your project becomes just a standard Maven project


and show some stuff

No more NetBeans speciﬁc “build harness”



and show some stuff


• No special build instructions: mvn clean install


and show some stuff


• IDE - neutral (IDEA, Eclipse)


and show some stuff


• Immediately available for CI without any speciﬁc setup


and show some stuff


• Easy to augment with QA plugins (e.g. Cobertura, FindBugs)


and show some stuff


• Just conﬁgure the plugin in the Master POM


and show some stuff


• Just conﬁgure the plugin in the Master POM

• Run it (e.g. mvn findbugs:findbugs)


Project structure


Project structure

• Modules Master POM

• Master POM
• Application module 1 Branding
Module POM

• What and how to assemble as ﬁnal app
1
• Branding module Application
Module POM

• e.g. i18n resources, customization of
existing platform resources *
Other NBM POM

• One or more .nbm modules


Demo


Demo

• Show forceTen Example 1


Dependency caveat!


Dependency caveat!
• Maven dependencies are transitive


Dependency caveat!
• NetBeans Platform dependencies are not transitive


Dependency caveat!
• The Maven plugin:


Dependency caveat!
• automatically translates direct Maven dependencies on NBM
modules to Platform dependencies


Dependency caveat!
• performs a consistency check about missing transitive
dependencies and dependencies on non-public classes


Dependency caveat!

• OSGi bundles allowed as dependencies since IDE 6.9 + NBM plugin 3.2


Dependency caveat!

• Old versions of the plugin behaved in a different way


Dependency caveat!

• Old versions of the plugin behaved in a different way
• Not mentioning some deprecated practices still available in 3.x

Reuse of NBM modules in non-platform projects



• The NBM Maven plugin produces both a .nbm and a .jar
artifacts (different packagings)



• This means that a non-platform project can reuse a NBM
module



module
• E.g. Java SE, Android, etc...



module

• Just declare a dependency as usual



module

• Projects whose packaging is nbm automatically depend on nbm artifacts



module

• Projects whose packaging is nbm automatically depend on nbm artifacts
• Projects whose packaging is jar automatically depend on jar artifacts


Demo

• Show forceTen Example 2


Module versioning strategies



• Every module artifact shares the same version of the project



• Simpler to manage



• Used by NetBeans for publishing Maven artifacts (e.g.
NETBEANS691)



NETBEANS691)
• Trick - indeed every NetBeans module has got its own version



NETBEANS691)

• Every module artifact has got its own version number



NETBEANS691)

• Slightly more complex to manage



NETBEANS691)

• Slightly more complex to manage
• Required if your modules might move from a project to another


Smart dependency convergence



• The <dependencyManagement> section



• Declare all the versions of the dependencies used in a project just
once, in a parent POM (DRY)



• Declare all the versions of the dependencies used in a project just
• Children POMs won’t need to declare the version again


<dependencyManagement>

<dependencies>
<dependency>
<groupId>it.tidalwave.netbeans</groupId>
<artifactId>it-tidalwave-netbeans-capabilitiesprovider</artifactId>
<version>1.1.26</version>
</dependency>
<dependency>
<artifactId>it-tidalwave-netbeans-docking</artifactId>

</dependency>
...
</dependencies>

•
</dependencyManagement>
Declare all the versions of the dependencies used in a project just



<dependencies>
<dependency>
</dependency>
<dependency>

</dependency>
...
</dependencies>

•

• The <dependencyManagement> section can be imported



<dependencies>
<dependency>
</dependency>
<dependency>

</dependency>
...
</dependencies>

•

• Import a single POM specifying its single version



<dependencies>
<dependency>
</dependency>
<dependency>

</dependency>
...
</dependencies>

•

• Import a single POM specifying its single version
• Maven will “unpack” from it all the declared versions at once



<dependencies>
<dependency>
</dependency>
<dependency>

</dependency>
...
</dependencies>

•
<dependencies>
<dependency>
<groupId>it.tidalwave.semantic</groupId>
<artifactId>semantic</artifactId>

<type>pom</type>
<scope>import</scope>
</dependency>

• <dependency>
Import a single POM specifying its single version
<artifactId>openbluesky</artifactId>

• <version>0.8.4</version>
Maven will “unpack” from it all the declared versions at once
<type>pom</type>
<scope>import</scope>
</dependency>
...
</dependencies>

Optimizing a Maven Platform project



Master POM

1 Branding
Module POM

1 Application
Module POM

*
Other NBM POM



Master POM

Master POM
1
Modules POM

1 Branding
Module POM
1
Branding
Module POM

1 Application
Module POM
1
Application
Module POM

*
Other NBM POM
*
Other NBM POM



Master POM

Master POM
1
Modules POM

Contains
1 Branding
dependencyManagement of
modules imported by this
Module POM project
1
Branding
Module POM

1 Application
Module POM
1
Application
Module POM

*
Other NBM POM
*
Other NBM POM



Contains
dependencyManagement of Master POM
modules exported by this
project

Master POM
1
Modules POM

Contains
1 Branding
Module POM project
1
Branding
Module POM

1 Application
Module POM
1
Application
Module POM

*
Other NBM POM
*
Other NBM POM


A single POM import
retrieves all the correct
modules versions in a
consistent way

Other project
Contains POM
dependencyManagement of Master POM <<imports>>
modules exported by this
project

Master POM
1
Modules POM

Contains
1 Branding
Module POM project
1
Branding
Module POM

1 Application
Module POM
1
Application
Module POM

*
Other NBM POM
*
Other NBM POM


The NBPWR project
From there, it’s optional. If you ran out of
time, just mention the project


The NBPWR project

• The NetBeans Platform needs to “wrap” non-platform jar libraries


The NBPWR project

• Declare public API, dependencies, other platform properties, ...


The NBPWR project


• Not hard, but it’s a waste to redo the same thing over and
over for multiple projects


The NBPWR project


• Not hard, but it’s a waste to redo the same thing over and
over for multiple projects
• The “NetBeans Platform Wrapper Repository” project
provides reusable wrappers for some common FLOSS
libraries


NBPWR issues


NBPWR issues

• Needs an alternate coordinate schema


NBPWR issues

• Can’t use the original artifact coordinates + changing the packaging


NBPWR issues

• Also for having dependencies on a wrapped NBM, not the original JAR


NBPWR issues
org.swinglabs:swingx:1.6
becomes
com.kenai.nbpwr:org-jdesktop-swingx:1.6-201002261215



NBPWR issues
becomes


• Needs a further versioning qualiﬁer


NBPWR issues
becomes


• Errors might be done e.g. in declaring the public API, thus needing
a ﬁx release targeting the same original library version


NBPWR issues
becomes



• It’s possible to attach original sources and javadocs


NBPWR issues
becomes



• It’s possible to attach original sources and javadocs
• Granularity: one .nbm per .jar or aggregates?


NBPWR usage


NBPWR usage

• You might not like some NBPWR decisions


NBPWR usage

• Interested in feedback about this!


NBPWR usage


• Still, a NBPWR-like approach is time-saving inside a given
corporate / workgroup


NBPWR usage


• Still, a NBPWR-like approach is time-saving inside a given
corporate / workgroup
• Cooperating, it could become a standard way of doing things


Conclusion


Conclusion
• The NB Platform is a highly modular and scalable framework


Conclusion
• The And Build Harness might not scale with your needs


Conclusion
• Cross-dependencies in large projects might be a problem


Conclusion

• Maven is a valuable and effective alternative


Conclusion

• Intuitive artifact management and cross-dependency management


Conclusion

• Your Platform project just becomes a standard Maven project


Conclusion

• Can be used with other IDEs - easy QA & Continuous Integration


Conclusion

• Beware: to be effective, Maven needs some pieces of infrastructure!


Conclusion

• Beware: to be effective, Maven needs some pieces of infrastructure!

• Ant vs Maven is partly subjective

Question time


Question time

• Follow me
• at my Java.Net blog
• at DZone

• Useful links
• http://platform.netbeans.org
• http://wiki.netbeans.org/MavenBestPractices
• http://forceten.tidalwave.it/development/tutorials/using-the-geoexplorer-
and-the-geoviewer/
• http://bluemarine.tidalwave.it


Netbeans+platform+maven

More Related Content

What's hot

Similar to Netbeans+platform+maven

More from Fabrizio Giudici

Recently uploaded

Netbeans+platform+maven