Maven is a build tool that provides a uniform build system with guidelines for best practices. It uses a Project Object Model (POM) XML file to define project information, relationships, and build settings. Maven projects have a default directory structure and life cycle made up of phases and goals. It supports multi-module projects to organize builds. Maven uses a local then remote repository to resolve dependencies. Artifactory is a repository that can host internal libraries. A complete build solution integrates Maven, source control, continuous integration, repositories, and code quality tools.
A brief overview on Apache Maven2. About the lifecycle, core concepts and how to setup a project. Presented with demos about Eclipse integration and reporting customization.
Stay productive while slicing up the monolith Markus Eisele
DevNexus 2017
Microservices-based architectures are en-vogue. The last couple of
years we have learned how the thought-leaders implement them, and
every other week we have heard about how containers and
Platform-as-a-Service offerings make them ultimately happen.
The problem is that the developers are almost forgotten and left alone
with provisioning and continuous delivery systems, containers and
resource schedulers, and frameworks and patterns to help slice
existing monoliths. How can we get back in control and efficiently
develop them without having to provision complete production-like
environments locally, by hand?
All the new buzzwords, frameworks, and hyped tools have made us forget
ourselves—Java developers–and what it means to be productive and have
fun building systems. The problem that we set out to solve is: how can
we run real-world Microservices-based systems on our local development
machines, managing provisioning, and orchestration of potentially
hundreds of services directly from a single command line tool, without
sacrificing productivity enablers like hot code reloading and instant
turnaround time?
During this talk, you’ll experience first-hand how much fun it can be
to develop large-scale Microservices-based systems. You will learn a
lot about what it takes to fail fast and recover and truly understand
the power of a fully integrated Microservices development environment.
The world is moving from a model where data sits at rest, waiting for people to make requests of it, to where data is constantly moving and streams of data flow to and from devices with or without human interaction. Decisions need to be made based on these streams of data in real-time, models need to be updated, and intelligence needs to be gathered. In this context, our old-fashioned approach of CRUD REST APIs serving CRUD database calls just doesn't cut it. It's time we moved to a stream-centric view of the world.
How Class Data Sharing Can Speed up Your Jakarta EE Application StartupRudy De Busscher
Java Byte code is OS independent, which means that your application's startup takes more time than a native image. Using the Class Data Sharing functionality introduced in more recent versions of the JVM, you can prepare your application so that it will load very fast.
In this presentation, I'll go into more detail what Class Data Sharing is and the differences between the OpenJDK and OpenJ9 versions. With some Jakarta EE demo applications, you will see gains that you can achieve and reduce memory footprint a lot in Docker containers by sharing memory.
A brief overview on Apache Maven2. About the lifecycle, core concepts and how to setup a project. Presented with demos about Eclipse integration and reporting customization.
Stay productive while slicing up the monolith Markus Eisele
DevNexus 2017
Microservices-based architectures are en-vogue. The last couple of
years we have learned how the thought-leaders implement them, and
every other week we have heard about how containers and
Platform-as-a-Service offerings make them ultimately happen.
The problem is that the developers are almost forgotten and left alone
with provisioning and continuous delivery systems, containers and
resource schedulers, and frameworks and patterns to help slice
existing monoliths. How can we get back in control and efficiently
develop them without having to provision complete production-like
environments locally, by hand?
All the new buzzwords, frameworks, and hyped tools have made us forget
ourselves—Java developers–and what it means to be productive and have
fun building systems. The problem that we set out to solve is: how can
we run real-world Microservices-based systems on our local development
machines, managing provisioning, and orchestration of potentially
hundreds of services directly from a single command line tool, without
sacrificing productivity enablers like hot code reloading and instant
turnaround time?
During this talk, you’ll experience first-hand how much fun it can be
to develop large-scale Microservices-based systems. You will learn a
lot about what it takes to fail fast and recover and truly understand
the power of a fully integrated Microservices development environment.
The world is moving from a model where data sits at rest, waiting for people to make requests of it, to where data is constantly moving and streams of data flow to and from devices with or without human interaction. Decisions need to be made based on these streams of data in real-time, models need to be updated, and intelligence needs to be gathered. In this context, our old-fashioned approach of CRUD REST APIs serving CRUD database calls just doesn't cut it. It's time we moved to a stream-centric view of the world.
How Class Data Sharing Can Speed up Your Jakarta EE Application StartupRudy De Busscher
Java Byte code is OS independent, which means that your application's startup takes more time than a native image. Using the Class Data Sharing functionality introduced in more recent versions of the JVM, you can prepare your application so that it will load very fast.
In this presentation, I'll go into more detail what Class Data Sharing is and the differences between the OpenJDK and OpenJ9 versions. With some Jakarta EE demo applications, you will see gains that you can achieve and reduce memory footprint a lot in Docker containers by sharing memory.
Architecting for failure - Why are distributed systems hard?Markus Eisele
Devnexus 2017
As we architect our systems for greater demands, scale, uptime, and performance, the hardest thing to control becomes the environment in which we deploy and the subtle but crucial interactions between complicated systems. And microservices obviously are the way to go forward with those complicated systems. But what makes it so hard to build them? And why should you embrace failure instead of doing what we can do best: Preventing failure. This talk introduces you to the problem domain of a distributed system which consists of a couple of microservices. It shows how to build, deploy and orchestrate the chaos and introduces you to a couple of patterns to prevent and compensate failure.
Taking the friction out of microservice frameworks with LagomMarkus Eisele
Lagom is a new framework for Java designed with microservices in mind. It aims to simplify the process of building microservice-based systems that communicate asynchronously, self-heal, scale elastically and remain responsive under load and under failure.
Many of the challenges of microservices are caused by the fact we use tools designed without them in mind. So, how can a framework made to build systems composed of microservices from the start offer us a better solution? Because Lagom is a tool that is highly opinionated and explicitly designed to make development and production with microservices easy, it brings back all the fun and productivity into programming while still enabling you to build a reactive, distributed, highly scalable and rock solid application.
By the end of this presentation, you'll have experienced first hand how creating systems of microservices on the JVM using Lagom is dead-simple, intuitive, frictionless and a lot of fun! And we’ll ask whether reactive microservices are potentially so much better than, for example, Java EE?
DevoxxUK https://cfp.devoxx.co.uk/2016/talk/UZA-8885/Taking_the_friction_out_of_microservice_frameworks_with_Lagom
Microservices architecture has many benefits. But it comes at a cost. Running microservices and monitoring what’s going on is tedious. That’s why MicroProfile adopts monitoring as a first-class concept. In this session, learn how MicroProfile runtimes collect metrics and how to seamlessly collect them with tools like Prometheus and Grafana. Learn how MicroProfile makes it easy to connect information about interrelated service calls, how to gather the information and analyze system bottlenecks, how to deploy and scale MicroProfile applications with Kubernetes and how to react to their health status to detect and automatically recover from failures.
Check out the talk to the slides:
http://bit.ly/1ReY8uJ
Talk Abstract:
Using Swarm, you can select “just enough app server” to support each of your microservices.
In this session, we’ll outline how WildFly Swarm works and get you started writing your first microservices using Java EE technologies you’re already familiar with.
You’ll learn how to setup your build system (Maven, Gradle, or your IDE of choice) to run and test WildFly Swarm-based services and produce runnable jars. We will walk from the simple case of wrapping a normal WAR application to the more advanced case of configuring the container using your own main(…) method.
Continuous Integration Fundamentals: Maven - OFM Canberra July 2014Joelith
Slides from the July Oracle Middleware Forum held in Canberra, Australia. Covers the next step in our continuous integration journey, namely the introduction of the build tool Maven. For more information, check out our blog at http://ofmcanberra.wordpress.com
It was year 1999 when EJBoss made it’s debut as an alternative opensource J2EE implementation. 15+ years is more than a lifetime in technology terms and yet the JBoss Application Server project, renamed in 2013 into WildFly has managed to thrive and stay relevant by evolving into the Swiss Army Knife of Application Servers.dandreadis
In this talk we are going to look at the latest developments in WildFly and get an introduction to it’s sister project called WildFly Swarm. WildFly provides a robust, modular, lightweight, fully manageable and fast runtime, implementing the complete set of Java EE7 APIs. WildFly Swarm on the other hand gives you the ability to pick and choose only the server parts you need and bundle them with your application to create fat jars easy to deploy as microservices.
Thus with WildFly & WildFly Swarm you get the richness and maturity of Java EE combined with extreme flexibility about your deployment options in traditional setups or dynamic cloud environments.
Who’s said Java EE needs to be boring?
Puppet & Perforce: Versioning Everything for DeploymentsPerforce
We all want faster deployments – but how? Learn how to use Perforce to manage everything that goes into deployments, how to use Puppet to manage the state of nodes with Perforce, and how integrating Perforce and Puppet speeds up the adoption of DevOps practices.
WildFly AppServer - State of the Union
as presented at SoftShake Geneva, Oct 2015
http://soft-shake.ch/2015/en/
Covering the whole WildFly v8/9/10 series and the key aspects of the base AS7 architecture.
Training Slides: 303 - Replicating out of a ClusterContinuent
Watch this 33min training on how to replicate out of your cluster using the standalone Replicator. This covers a walkthrough of what a Cluster Extractor is and what you can do with it, including a demonstration on how to install it.
TOPICS COVERED
- Explore the Cluster Extractor
- Review possible targets
- Discuss Use Cases
- Demonstrate an installation
Architecting for failure - Why are distributed systems hard?Markus Eisele
Devnexus 2017
As we architect our systems for greater demands, scale, uptime, and performance, the hardest thing to control becomes the environment in which we deploy and the subtle but crucial interactions between complicated systems. And microservices obviously are the way to go forward with those complicated systems. But what makes it so hard to build them? And why should you embrace failure instead of doing what we can do best: Preventing failure. This talk introduces you to the problem domain of a distributed system which consists of a couple of microservices. It shows how to build, deploy and orchestrate the chaos and introduces you to a couple of patterns to prevent and compensate failure.
Taking the friction out of microservice frameworks with LagomMarkus Eisele
Lagom is a new framework for Java designed with microservices in mind. It aims to simplify the process of building microservice-based systems that communicate asynchronously, self-heal, scale elastically and remain responsive under load and under failure.
Many of the challenges of microservices are caused by the fact we use tools designed without them in mind. So, how can a framework made to build systems composed of microservices from the start offer us a better solution? Because Lagom is a tool that is highly opinionated and explicitly designed to make development and production with microservices easy, it brings back all the fun and productivity into programming while still enabling you to build a reactive, distributed, highly scalable and rock solid application.
By the end of this presentation, you'll have experienced first hand how creating systems of microservices on the JVM using Lagom is dead-simple, intuitive, frictionless and a lot of fun! And we’ll ask whether reactive microservices are potentially so much better than, for example, Java EE?
DevoxxUK https://cfp.devoxx.co.uk/2016/talk/UZA-8885/Taking_the_friction_out_of_microservice_frameworks_with_Lagom
Microservices architecture has many benefits. But it comes at a cost. Running microservices and monitoring what’s going on is tedious. That’s why MicroProfile adopts monitoring as a first-class concept. In this session, learn how MicroProfile runtimes collect metrics and how to seamlessly collect them with tools like Prometheus and Grafana. Learn how MicroProfile makes it easy to connect information about interrelated service calls, how to gather the information and analyze system bottlenecks, how to deploy and scale MicroProfile applications with Kubernetes and how to react to their health status to detect and automatically recover from failures.
Check out the talk to the slides:
http://bit.ly/1ReY8uJ
Talk Abstract:
Using Swarm, you can select “just enough app server” to support each of your microservices.
In this session, we’ll outline how WildFly Swarm works and get you started writing your first microservices using Java EE technologies you’re already familiar with.
You’ll learn how to setup your build system (Maven, Gradle, or your IDE of choice) to run and test WildFly Swarm-based services and produce runnable jars. We will walk from the simple case of wrapping a normal WAR application to the more advanced case of configuring the container using your own main(…) method.
Continuous Integration Fundamentals: Maven - OFM Canberra July 2014Joelith
Slides from the July Oracle Middleware Forum held in Canberra, Australia. Covers the next step in our continuous integration journey, namely the introduction of the build tool Maven. For more information, check out our blog at http://ofmcanberra.wordpress.com
It was year 1999 when EJBoss made it’s debut as an alternative opensource J2EE implementation. 15+ years is more than a lifetime in technology terms and yet the JBoss Application Server project, renamed in 2013 into WildFly has managed to thrive and stay relevant by evolving into the Swiss Army Knife of Application Servers.dandreadis
In this talk we are going to look at the latest developments in WildFly and get an introduction to it’s sister project called WildFly Swarm. WildFly provides a robust, modular, lightweight, fully manageable and fast runtime, implementing the complete set of Java EE7 APIs. WildFly Swarm on the other hand gives you the ability to pick and choose only the server parts you need and bundle them with your application to create fat jars easy to deploy as microservices.
Thus with WildFly & WildFly Swarm you get the richness and maturity of Java EE combined with extreme flexibility about your deployment options in traditional setups or dynamic cloud environments.
Who’s said Java EE needs to be boring?
Puppet & Perforce: Versioning Everything for DeploymentsPerforce
We all want faster deployments – but how? Learn how to use Perforce to manage everything that goes into deployments, how to use Puppet to manage the state of nodes with Perforce, and how integrating Perforce and Puppet speeds up the adoption of DevOps practices.
WildFly AppServer - State of the Union
as presented at SoftShake Geneva, Oct 2015
http://soft-shake.ch/2015/en/
Covering the whole WildFly v8/9/10 series and the key aspects of the base AS7 architecture.
Training Slides: 303 - Replicating out of a ClusterContinuent
Watch this 33min training on how to replicate out of your cluster using the standalone Replicator. This covers a walkthrough of what a Cluster Extractor is and what you can do with it, including a demonstration on how to install it.
TOPICS COVERED
- Explore the Cluster Extractor
- Review possible targets
- Discuss Use Cases
- Demonstrate an installation
This presentation provides a comprehensive overview of Maven 3 including lifecycles and a detail of the default lifecycle and the associated phases within.
The presentation is related to the firm where I rebuilt an existing non-maven project to the maven-based project with the best willingness of a proper modularity designs.
The Demos in this presentation are related to source code which is not attached.
Maven is a build automation tool used primarily for Java projects. This presentation will cover the basics of Maven and its usage while developing Java application.This is for anyone interested to learn Maven especially the Java developers.
Similar to How maven makes your development group look like a bunch of professionals. (20)
3. What’s the Problem?
• Manual handling of external Jars
• Inter-project dependencies
• Running tests
4. What is Maven ?
• A build tool
• Uniform build system
• Provides quality project information
• Transparent migration to new features
• Guidelines for best practices development
5. Conceptual Model
• Maven maintains model of a project
• Unique set of coordinates to a project
• Almost zero effort
• Encourages modular design
6. Default Directory Structure
Structure is based on the archetypes
definition
Source folders
Test related
Source folders
Generated class files
and artifacts
7. POM
• Fundamental unit of work in maven
• An XML file
• Consists
– Project information
– Project relationships
– Build settings
– Build environment
8. POM <project ...>
<parent />
<groupId />
• Fundamental unit of work in maven
<artifactId />
<version />
<packaging />
<modules> … </modules>
• An XML file <propertie> ... </properties>
<developers />
<contributors />
<scm> ... </scm>
• Consists <build>
<plugins> ... </plugins>
– Project information
</build>
<dependencies> ... </dependencies>
– Project relationships </repositories>
<repositories> ...
<pluginRepositories> ... </pluginRepositories>
– Build settings ... </profiles>
<profiles>
<reporting> ... </reporting>
– Build environment
</project>
9. POM
• Convention over Configuration
• Maven incorporates this by providing
default behavior for projects
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>my.fazreil.projects</groupId>
<artifactId>fireglass</artifactId>
<version>0.0.1</version>
</project>
Just put your sources in the
correct directory
10. Life Cycle
• Contains phases in specific order
• Phase is made up of goals
• 3 built-in life cycles
– default
– clean and
– test
11. Life Cycle - Default
validate
initialize
test-
compile test package
compile
deploy install
12. Multi-Module Projects
• Why use a modular architecture ?
– Separation of concerns
– Easier to test
– Flexible
• Reusing the configuration
– Inheritance
– Dependencies
• Aggregation
13. Multi-Module Projects
Organization or team wide
properties
archetype
Project wide properties
Project
Aggregation
module1 module2
Module specific properties
15. Maven Repository
• Holds the build artifacts and dependencies
• Two types of repositories
– Local
– Remote
16. Local Repository
• Local cache for artifacts
• Can erase it completely
• Useful for offline builds
• Resides in User home’s .m2/ folder
17. Remote Repository
• Central repository to host all artifacts
• Local repository downloads from the
central repository hosted @ maven.org
Local Repository
Search order
(.m2repository)
Remote repository
(http://repo1.maven.org/maven2)
18. Internal Repository
• Corporate repository
• Proxy for remote repositories
Local Repository
(.m2repository)
Search order
Internal Proxy
(http://{repository url})
Remote repository
(http://repo1.maven.org/maven2)
19. What is Artifactory?
• It is a MAVEN repository
• Think of it as the ‘SVN’ for libraries.
• It is the place to obtain this information:
<dependency>
<groupId>my.fazreil.project</groupId>
<artifactId>fireglass</artifactId>
<version>0.0.1</version>
</dependency>
20. Do we need our own maven
repo?
• Because we want to host our own
libraries.
• And we would like to make our libraries
available to the local network
• Yes, we can control the access.
21. Extra notes
• Artifactory acts as a proxy to the outside
repository.
• Dependencies requested to Artifactory will
be cached in Artifactory for quick retrieval.
24. Maven Release Cycle
• Develop against snapshot versions
• Release stable versions
• Automated releases
– Update version numbers to next SNAPSHOT
versions
Editor's Notes
Teaming as a way of life!!
Maven IntroductionWhat is maven ?why ?Maven vs AntBasicsDependenciesMaven customizationIDE integrationMulti-module projects - creating multi module projects - naming conventions - Group id, artifact id
External jarsWhere to store themWhat versionDependency on other jarsRunning test - developers don’t have time or forget tests before commit
Majorityof the maven users call maven as a “build tool” – A tool used to build deployable artifacts from source code.Build tool such as Ant is focused solely on preprocessing, compilation, packaging, testing and distribution.Uniform build system (POM)this definition of a model for every project enables features such asDependency managementRemote repositoriesUniversal reuse of build logicTool portability / integrationLife CycleCompiling source codeExecuting test casesPackaging distributionAnd many others
Model – Provides default behavior for projectsZERO effortPut sources in source directoryDefine relationships between modulesModularDefine the relationship between modulesInherit properties and behavior from parent projectsOrganize build with multi-module projects
Archetype is a Maven project templating toolkit.An archetype is defined as an original pattern or model from which all other things of the same kind are made.
POMIt is what makes your project a maven project
POMIt is what makes your project a maven project
Convention over configurationSystems, libraries, and frameworks should assume reasonable defaults.Source, resources, test, classes and etc…Defined life cycle and a set of common pluginsSet of common plugin’s knows how to build and assemble the software …
Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.Phase represents a specific stageGoal represents a specific taskDefault : handles your project deploymentClean: project cleaningSite: project’s site documentation
WHY?Separation of concernsEasier to testFlexibleDependenciesDefine the relationships between modules InheritanceInherit properties and behaviour from parent projectsAggregationOrganize builds with multi-module projects
Inheritance in actionSuper POM is always the base parent like Object in java
Organize : - coordinates builds and stage build process (build pipelines)Test process:Not only unit tests.Integration test, parallelize long running integration tests
Why not store JAR’s in CVS ?Maven tries to promote the notion of a user local repository where JARs, or any project artifacts, can be stored and used for any number of builds.Uses less storageMakes checking of a project quicker
It is a MAVEN repositoryThink of it as the ‘SVN’ for libraries.It is the place to obtain this information:<dependency> <groupId>my.mimos.util</groupId> <artifactId>dbutil</artifactId> <version>0.1</version></dependency>
Because we want to host our own libraries.And we would like to make our libraries available to the whole MIMOS networkYes, we can control the access.
Artifactory acts as a proxy to the outside repository.Dependencies requested to Artifactory will be cached in Artifactory for quick retrieval.Log in using MIMOS AD Login.
Maven:Describe project, generate artifacts, artifact versioningSubversion:To collectively own code and integrate often, source code repository is necessaryCI server:After check-in, a CI server will check the code out, compile and run all the unit tests.Artifactory:It enables both release and snapshot artifacts. It is valuable to keep metrics about source code (code quality).
To automate, needMaven release plugin and scm details in POM xmlEach release produces a new time-stamped artifactSnapshot versions are identified by the SNAPSHOT keywordStable, tested releaseEach artifact is unique