Here are the steps to filter the resource properties in the example: 1. Define the my.filter.value property in a filter file (e.g. src/main/filters/filter.properties): my.filter.value=hello 2. Define the command.line.prop property in the pom.xml: <properties> <command.line.prop>hello</command.line.prop> </properties> 3. The settings.offline property will be filtered from the <offline>true</offline> value defined in settings.xml 4. Add filtering configuration to the pom.xml: <build> <filters> <filter>src

1. S/W Design and Modularity
using Maven 2
Tibor Digaňa

2. Goals
• Modularity
• Maven
• Demos

3. Agenda
• Necessary understanding of modularity helps you
better understand the Maven features;
• Mandatory Maven theory with demos;
• Solving Real Project Problem;
• Extra Demos: Maven plugins, FTP
Deployment, SCM, Site, Javadoc, JIRA in
Maven, Query Builder project and other, building
WAR in JEE, Maven vs. corporative build
process, TeamCity, Ant in Maven, classpath via
dependency plugin, …

4. Modularity and the Maven?
• Without feeling for Modularity you are doing
in Maven something that you do not know
what it is;
• If you consider the Maven as a build tool, then
you are completely wrong;
• Maven like other tool, e.g. Apache Ivy, helps
you building a modular application.

5. What is Maven?
Maven is a software project management and
comprehension tool. Based on the concept of
a Project Object Model (POM), Maven can
manage a project's build, reporting and
documentation from a central piece of
information.

6. Maven is just a tool!
• Just like JDK and Java programming language, does not
guarantee right design in your hands, using the same
twice you can produce useful or bad design;
• Using Maven right way, whatever corporative rule;
• The Maven solves information hiding in modular
application, and provides dependencies inheritance;
• Maven solves compile-time dependencies in modular
application;
• Maven has runtime scope in dependencies as well;
• Maven controls build life cycle in specific packaging;
• If you only want to compile pure sources, use the Ant.

7. Maven is just a tool!
• OOP has attributes for information hiding and the
Maven has attributes of information hiding in
modularity as well;
• Builds an artifact based on module POM;
• Encapsulates POM with dependencies in e.g. JAR
package;
• Inheritance of dependencies;
• Overrides dependencies;
• Includes/Excludes dependencies;
• Polymorphic behavior of artifact does not exist;
• Only configuration using profiles;

8. Granularity and Modules
• Classes are “somehow” logically grouped in to
packages (unit);
• Granularity is the measure of a convenient
unit for organizing small and large applications

9. Design Patterns and Principles
• For a concrete problem definition, the design
principle specifies the relationship between
object reference types;
• Design Principles help you design units like
modules, packages and classes in the package
in favor of reusability, maintainability and
robustness.

10. Granularity as a General Problem of Design
Two bad concepts in packaging
• One package in entire application
• Over-packaging
Both lead to a disorder (hell of the classes)
where packages have no context and domain
is missing.
Hard to find rules in visibility of the classes.
So, information hiding must apply to packages in
compile-time and run-time!

11. Design Principles go with UML
• The Open Closed Principle (OCP)
• The Liskov Substitution Principle (LSP)
• The Dependency Inversion Principle (DIP)
• The Interface Segregation Principle (ISP)
• The Reuse/Release Equivalence Principle (REP)
• The Common Reuse Principle (CRP)
• The Common Closure Principle (CCP)
• The Acyclic Dependency Principle (ADP)
Reference: http://www.objectmentor.com/resources/articles/granularity.pdf
http://www.objectmentor.com/resources/publishedArticles.html

12. Composite/Structured Design by Glendford J. Myers

13. Demo
Using Maven in Real Application

14. Fine grained Modularity
• Each domain package is a module
• Domain package is atomic –indivisible context
• Pros/cons
• Continuous development on modules which
are not able to compile

15. Dependencies Matrix of a Real
Application without Maven

16. Can we apply fine grained modularity
in this s/w design ?
• No, we cannot apply it without redesigning
dependencies
• Reason: For instance
the interface parser.ISheetParser depends
on data.SheetDocument and vice-versa.
• Current s/w design has cyclic dependencies in
packages.

17. Data depends on Parser Package

18. Parser Depends on Data Package

19. How to prevent from Cyclic
Dependencies?
• Acyclic Dependency Principle (ADP)
• Add an extra module/package with
an abstract Class or an Interface

20. Let’s prevent from cyclic dependencies
in continuous development
• Make custom dependency rules unbreakable
in package hierarchy

21. Let’s prevent from cyclic dependencies
in continuous development

22. Let’s prevent from cyclic dependencies
in continuous development
Unfortunately you cannot successfully export
Dependency Violation settings to
“Project_Default.xml” either to settings.jar via
File|Export Settings.
Thus you still need IDEA project files in your CVS.

23. Let’s prevent from cyclic dependencies
in continuous development

24. In the Maven this is more
sophisticated
• The key is relationship between modules
• Maven is a build tool
• Maven controls the build life cycle
• Maven can be used in IDE without IDE’s
project files (including some global
settings.jar)

25. Applying Maven as a Tool
• A bad design of POM.XML when modularity is
not properly considered;
• POM.XML reflecting a good modularity
concept

26. Minimum information for modular app
• pom.xml
• mvn idea:idea
(mvn org.apache.maven.plugins:maven-idea-plugin:idea)

27. Demo
Let’s create the IDEA project files from pom.xml

28. Minimum information for modular app
Using Maven in IDEA we Do NOT need IDEA
project files in CVS.
Mainly you need Maven command line,
pom.xml and settings.jar

29. Development using IDEA and Maven
Two approaches to get IDEA/Maven project
1. Having pom.xml create IDEA project files
mvn idea:idea
2. Create pom.xml altogether with project files
directly in IDEA
Create New Project|Create project from scratch|Maven Module|…

30. Demo
Now follow the second approach in IDEA.

31. Demo with complete project
• Setting Maven Home directory in IDEA
• Maven settings.xml in IDEA
• Specifying local repository in IDEA

32. Introduction to the Standard Directory
Layout

33. As a convention we use these files
in ${basedir}
• LICENSE.TXT
• NOTICE.TXT
• README.TXT

34. Maven Project Settings in IDEA

35. Demo Started Build
• Start the build in profile “development”
• Start the build in profile “release”

36. Maven 2 Installation Package
• ${maven.home}/bin/*.*
runtime and debugging scripts
• ${maven.home}/boot/*.jar
classloading framework
• ${maven.home}/conf/settings.xml
• ${maven.home}/lib/*.jar
Maven 2 core library for core classloader

37. Maven 2 Core Classloader
• The Apache Codehaus Classworlds JAR is used
to boot the classloader graph.
• The core classloader uses libraries in
${maven.home}/lib and extensions.
• These libraries in Maven 2 are visible to
current and subsequent projects.
• Changes in Maven 3.1 + OSGi
References
http://maven.apache.org/guides/mini/guide-maven-classloading.html
http://www.parleys.com/#st=5&id=1630

38. Maven 2 Plugin Classloader
• Has plugin’s dependencies list as specified by
plugins/plugin section in POM XML;
• Does not use project’s classloader, but may
require using custom class loader of projects
compile, runtime, and test class path.
References
http://maven.apache.org/guides/mini/guide-maven-classloading.html

39. Building Phases in Maven Core
• *uber.jar!/**/*.*/components.xml
contains default phases per packaging type
Reference
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

40. Demo
Super POM
• In Maven 2 installation dir (by default: $(user.home)/.m2/) with model
version 4.0.0
• lib/maven-2.2.1-uber.jar/org/apache/maven/project/pom-4.0.0.xml
• Each POM and parent POM extends Super POM
• Super POM defines central-release-plugin/repository
http://repo1.maven.org/maven2
• Standard Maven Directory Layout and properties
${directory} == ${pom.basedir}/target
outputDirectory == classes
finalName == ${project.artifactId}-${project.version}
testOutputDirectory == test-classes, etc.
• pluginManagement for phases of default build life cycle including
clean, and site phases and their plugin versions

41. What did we create?
<groupId>com.idsscheer</groupId>
<artifactId>spreadsheet</artifactId>
<version>2.0.1</version>

42. Identifying Artifact
• Min required fields is groupId:artifactId:version
so-called standard coordinate. The groupId and
artifactId might be inherited from parent POM;
• The Maven sometimes print out coordinates
groupId:artifactId:packaging:version
groupId:artifactId:packaging:classifier:version
• More generally ‘fileName’ of deploy library
${artifactId}-${version}-${classifier}.${packaging}
e.g. spreadsheet-2.0.0-jdk1.5.jar
Unless fileName is overridden in build section.
• Dependency type can be jar, war, etc., or
combined with an extension, e.g. test-jar.

43. Demo
• Newly created structured using Maven
• Compare with old project structure of
directory layout
• Clarity and minimum info in new structure

44. Offline Command Line Options
• -o #maven build in offline mode
• -npu #no plugin updates
• -npl #no plugin latest

45. Maven Project Model
Explaining XML tags in POM
Reference:
http://maven.apache.org/ref/2.2.1/maven-model/maven.html

46. settings.xml
http://maven.apache.org/settings.html

47. Modularity Pros
• Asynchronous project flow
• A project module in IDE without the rest
• Easier maintenance
• Minimizes coupling
• Using interfaces/mock object testable design
• Reusability
• Error prone
• Conceptual diagram
References:
http://www.objectmentor.com/resources/articles/granularity.pdf
http://www.infoq.com/articles/modular-java-what-is-it
http://java.dzone.com/articles/java-modularity-2-why

48. Modularity only If no pure Reusability?
• Still makes sense to have modular app if pure
reusability (one usage of a module).

49. Modularity sustains a continuous
Progress of Development
• From Spaghetti code to modular app

50. What is NOT Artifact Reusability
• Textually inserted bunch of program to
another program; (junit, junit-dep);
• Re-assembly library into another library;
(Reusability is the most often claimed goal of OOD.)
Reference:
http://www.objectmentor.com/resources/articles/granularity.pdf

51. What is Artifact Reusability
• My project links with another dependency.
• Whenever a new dependency artifact is fixed
or enhanced, I receive new version.
Reference:
http://www.objectmentor.com/resources/articles/granularity.pdf

52. Modularity Cons
• Hell of classes if wrong separation concept.
Means mismatched domain package/module.
• Hell of transitive dependencies.
• Runtime scope different from compile scope.
• People assigned to a module development
may not necessarily have a global picture of
view, which on the other hand improved work
concentrations in current project of module.

53. Artifact Versioning
• <major>.<minor>.<incremental>-<qualifier>
• 1.3-beta-01
• 1.3.5
• 1.3.5-SNAPSHOT
• 1.3.5-1234567890
References:
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges

54. Notice
Separating build number/qualifier is broken.
Versions are naturally ordered as strings.
Thus alpha-2 is greater than alpha-10.
Therefore prefix with preceding zeros: alpha-02

55. Notice
If specifying dependency or plugin version like:
<version>1.2.3</version>
This is Maven’s freedom to prefer version 1.2.3
or take other in conflicts.
Explicit version must be encapsulated:
<version>[1.2.3]</version>
Reference (conflicts resolution):
http://maven.apache.org/guides/introduction/introduction-to-dependency-
mechanism.html

56. Artifact Versions in Range
• [4.0,)
• (,2.0)
• [2.0]
• [3.8,4.0)

57. Two contradictory goals
• Need for an overall of “big picture” in multi
module projects.
• The goal of high module independence is to
know as little as possible of system reminders

58. Conclusion on what has changed in
p4://Modules/libs/spreadsheet/Develop/2.0.x
• Added LICENSE.TXT; NOTICE.TXT; README.TXT;
src/main/config/settings.xml
• Added directories src/main/java, resources; src/test/java;
• Modified spreadsheet.iml; *.ipr; *.iws;
• Moved ./build/gen/**/*.java to src/main/java/**/parser/…
• Moved ./source/*.java (except for applications) to
src/main/java/…
• Moved applications from ./source/*.java to src/test/java/…
• Moved JUnit tests from ./testsource/*.java to
src/test/java/…
• Moved one resource ./build/gen/**/SheetParser.tokens
to src/main/resources/…

59. What to do when tests fail
See the logs and localize the detailed error desc.
• running ASheetOperationTestCase
Tests run: 5, Failures: 1, Errors: 4, Skipped:
0, Time elapsed: 0.07 sec <<< FAILURE!
• Localize the report in ./target/surefire-reports
• ASheetOperationTestCase.txt or xml
• And analyse the Java stack trace

60. Demo
What to do when tests fail
• ASheetOperationTestCase.txt
• ASheetOperationTestCase.xml

61. How do I add resources to my JAR?
Intended storage (or override by property in build)
• ${basedir}/src/main/resources
• ${basedir}/src/test/resources
A good practice is to create and use META-INF.
Regarding the Java Services create in basedir:
src/main/resources/META-INF/service/<interface>

62. Standard Maven Directory Layout

63. Notice
JAR packaging plugin creates
• Directory META-INF
• File META-INF/MANIFEST.MF
And additionally
target/classes/META-INF/${pom.groupId}/${pom.artifactId}/
• pom.properties
• pom.xml

64. Retrieve Resource in Source Code
InputStream is = getClass()
.getResourceAsStream("/META-INF/application.properties" )

65. How do I filter resource files?
As in the previous slides the resource file is
“application.properties”.
Put a reference to the property that will contain
a filtered value using the syntax
${< property name >}
Property names must be unique in a profile.

66. Filtering Resources
Resource content examples:
# application.properties
application.name=${project.name}
application.version=${project.version}
jdk.path=${env.JAVA_HOME}
application.root.dir=${user.dir}
message=${my.filter.value}
command=${command.line.prop}
isOffline=${settings.offline}

67. Notice
• Semantics ${project.xyz} == ${pom.xyz} == ${xyz}
• Semantics ${pom.xyz} and ${xyz} are Deprecated

68. Filtering Resources
Three properties references must be obtained:
• my.filter.value
• command.line.prop
• settings.offline

69. Filtering Resources by a Filter File
<project>
<build>
<filters>
<filter>src/main/filters/filter.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>

70. Filtering Resources by a Filter File
• An example of filter file content:
# filter.properties
my.filter.value=hello!
What about language specific properties.
Use a custom profile for specific language build.

71. Filtering Resources
How to filter resource property command.line.prop ?
POM.XML:
<project>
<properties>
<command.line.prop>hello</command.line.prop>
</properties>
</project>
Or use system property handled in phase process-resources
mvn process-resources "-Dcommand.line.prop=hello again"

72. Notice
• System property has higher priority than a
property with same name defined in POM;
• Properties must be unique in certain profile.

73. Filtering Resources
How to filter resource property settings.offline ?
SETTINGS.XML:
<settings>
<offline>true</offline>
</settings>

74. Filtering Resources
Resources are processed in phase
process-resources
Example: mvn process-resouces

75. After Installing the Release Versions
custom the command (-Prelease is profile name)
mvn -s src/main/config/settings.xml clean install –P release
1. First we installed version 2.0.2
2. And then 2.0.1
LibRepository/com/idsscheer/spreadsheet/

76. Artifact Installation the Release
Versions

77. Artifact Installation the Release
Versions

78. Artifact Installation the Snapshot
Version
Installation 2.0.2-SNAPSHOT
mvn -s src/main/config/settings.xml clean install