Narative
Examples
Formal Exposition
Sources and links
Style for quoted xml elements
Reference to conceptual terms. How do we tell if the reference is to the concept or to the physical manifestation.
How to refer to executing plugins.
Maven’s principal goal is to facilitate a build operation resulting in the artefacts of the build being placed back in the maven repository ready for deployment or reuse in other builds.
Introduction
It is striking how Maven can build complex apps with so few commands. In the example that we examine here a fairly minimal pom (set of build instructions) compiles the application, runs unit tests and builds a jar.
There are 3 factors in play:
1) Command Line: mvn clean install
This is executed from the directory containing the project’s POM file (typically, pom.xml).
Install turns out not to be install and its brother deploy does not deploy except for those with a very maven-centric view of the world.
2) Minimal.pom:
project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>disappointed</groupId>
<artifactId>minimal</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
The first few lines are metadata setting up the file itself. The lines from groupId to version identify the artefact being built.
The packaging line is usually, rather anomalously, included with the identifiers. It determines the predefined plugins that will be used during the build and is usually the file extension of the ultimate output. The dependencies section specifies a library that needs to be included.
The economy of language promoted by maven is somewhat undermined by the use of XML whose verbosity tends to obfuscate the meaning a little.
3) Directory Structure
Maven expects to see the files laid out as follows: (see dir.xml in google docs).
C:\projects\Intro\minimal\.idea
C:\projects\Intro\minimal\files.txt
C:\projects\Intro\minimal\install.txt
C:\projects\Intro\minimal\minimal.iml
C:\projects\Intro\minimal\pom.xml
C:\projects\Intro\minimal\src
C:\projects\Intro\minimal\target
C:\projects\Intro\minimal\.idea\.name
C:\projects\Intro\minimal\.idea\ant.xml
C:\projects\Intro\minimal\.idea\compiler.xml
C:\projects\Intro\minimal\.idea\copyright
C:\projects\Intro\minimal\.idea\encodings.xml
C:\projects\Intro\minimal\.idea\inspectionProfiles
C:\projects\Intro\minimal\.idea\libraries
C:\projects\Intro\minimal\.idea\misc.xml
C:\projects\Intro\minimal\.idea\modules.xml
C:\projects\Intro\minimal\.idea\projectCodeStyle.xml
C:\projects\Intro\minimal\.idea\scopes
C:\projects\Intro\minimal\.idea\uiDesigner.xml
C:\projects\Intro\minimal\.idea\vcs.xml
C:\projects\Intro\minimal\.idea\workspace.xml
C:\projects\Intro\minimal\.idea\copyright\profiles_settings.xml
C:\projects\Intro\minimal\.idea\libraries\Maven__junit_junit_3_8_1.xml
C:\projects\Intro\minimal\.idea\scopes\scope_settings.xml
C:\projects\Intro\minimal\src\main
C:\projects\Intro\minimal\src\test
C:\projects\Intro\minimal\src\main\java
C:\projects\Intro\minimal\src\main\java\disappointed
C:\projects\Intro\minimal\src\main\java\disappointed\App.java
C:\projects\Intro\minimal\src\test\java
C:\projects\Intro\minimal\src\test\java\disappointed
C:\projects\Intro\minimal\src\test\java\disappointed\AppTest.java
C:\projects\Intro\minimal\target\classes
C:\projects\Intro\minimal\target\maven-archiver
C:\projects\Intro\minimal\target\minimal-1.0-SNAPSHOT.jar
C:\projects\Intro\minimal\target\surefire
C:\projects\Intro\minimal\target\surefire-reports
C:\projects\Intro\minimal\target\test-classes
C:\projects\Intro\minimal\target\classes\disappointed
C:\projects\Intro\minimal\target\classes\disappointed\App.class
C:\projects\Intro\minimal\target\maven-archiver\pom.properties
C:\projects\Intro\minimal\target\surefire\surefire5238152605757349043tmp
C:\projects\Intro\minimal\target\surefire\surefire5547984483849284943tmp
C:\projects\Intro\minimal\target\surefire\surefirebooter4245046427534627574.jar
C:\projects\Intro\minimal\target\surefire-reports\disappointed.AppTest.txt
C:\projects\Intro\minimal\target\surefire-reports\TEST-disappointed.AppTest.xml
C:\projects\Intro\minimal\target\test-classes\disappointed
C:\projects\Intro\minimal\target\test-classes\disappointed\AppTest.class
The command line tells maven to execute 2 sets of tasks, one to clean away existing output and the other to create up-to-date output. In maven terms “clean” and “install” are “phases” of maven “life-cycles”. “clean” runs the “clean” phase of the “clean” life-cycle together with all preceding phases and “install” runs the installation phase (copying a completed jar file to the local maven repository) and all preceding phases such as compilation of what is known as the “default” life-cycle but which might reasonably have been called the compile-test-deploy life-cycle.
Files are laid out according to the requirements of the plugins: the compiler, by convention, requires production source to be under src/main/java and test source under src/test/java; the jar packager requires classes to be at target/classes and resources to be at target/classes/resources (CHECK THIS). All paths are specified relative the directory containing the POM.
The objective of this piece is to examine the less intuitive aspects of the POM, in particular the build section and provide some background for novices who are build out the default POM for a new project or need to interpret an existing POM or set of interrelated POMs. The piece concentrates on the plugin architecture and the execution of the build as these are not always intuitive.
How does it achieve this? Maven relies on 3 inter-related patterns:
We return to the question of what it is about Maven that allows so much complexity in the build process to be abstracted away. It comes down to 2 factors which combine to provide a foundation to the technology.
Firstly convention over configuration whereby the location of inputs to the build are specified by the tool’s rules rather than the user’s whim. Not only does this mean that locations can be omitted but the tool is now free to omit the mention of the tools that rely on those locations. i.e if it were not for convention over configuration the names of the tools would need to be specified at least so that their configuration could be detailed?
Secondly the most idiosyncratic feature which is the structure of the build instructions. This architecture is covered in detail below.
Maven has a third feature which turns out to be probably the most convenient feature for the users although it does not contribute much to the issues addressed by this piece. The feature is an automatic download of dependencies and build tools (plugins). It is this feature that gives Maven projects a tremendous portability.
Concentrates on the build cycle for typical Java enterprise projects. The site lifecycle is not considered in any detail. The trivial clean lifecycle is considered in passing. The principal consideration is the default lifecycle for jar and war packagings.
Life-cycles, Phases and Plugins
We have talked so far in terms of plugins used / tasks executed as equivalent. How does this work?
Instead of specifying steps as a set of tasks as in a batch file or having the execution order set by a dependency tree as in a traditional make configuration, the Maven build process is broken up into a number of phases, such as compile and test. Zero, one or more tasks are allocated to each phase. Instead of having a build step as the heading and the tasks listed underneath it the plugins which execute the tasks specify the phase in which they should be executed.
Before we examine the phases in detail we need to talk about life-cycles. There are 3 life-cycles, clean, site and default. The phases of the clean life-cycle (pre-clean, clean, post-clean) by default execute tasks that clean away output from a previous build and site phases (pre-site, site, post-site, site-deploy) execute tasks to build a website documenting the project. We won’t consider the clean and site life-cycles further but be assured they follow the same pattern as the default life-cycle.
The default (build) life-cycle has twenty three phases. Eight of these contain tasks by default (see the example POM above). The project developer is free to use the other 17 or in fact to add tasks (in the form of plugin references) to the eight already occupied. These tasks will be added to the default ones rather than overwriting them. The execution order of the phases is fixed (which is rather the point of them) but the order of execution of tasks within a phase is not guaranteed.
Default Phases for Jar Build
If you are building a jar (that is you set the project packaging element to jar and do not specify a build section in the POM then the following goals are executed by default for the default lifecycle.
mvn help:describe -Dcmd=deploy (or the name of any phase from the lifecycle in which you are interested. This seems to pick up only the predefined plugins.
Phase
Plugin:goal
initialize
generate-sources
process-sources
generate-resources
process-resources
compile
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources
test-compile
process-test-classes
test
prepare-package
package
pre-integration-test
integration-test
post-integration-test
verify
install
deploy
Goals
In maven parlance the goals of no plugins are bound to these phases.
When we talked about the equivalence of plugins and tasks that was not the full story. Plugins can perform a number of tasks. Each capability (task type) is identified as a goal (sometimes referred to as mojo).
For instance the maven-compiler-plugin has two goals: the compile goal is executed in the compile phase and the testCompile goal is executed in the test-compile phase. These two goals execute the same code but operate on distinct source directories and build into distinct target directories.
More about Defaults
The particular plugins and goals to be executed by default during each phase of the build vary according the value of the project’s <packaging> element. As well as the jar packaging, used in our examples so far there is a number of other predefined packaging types. The war packaging changes only the plugin and goal associated with the package phase as do the ejb, ejb3, rar and par package types whereas for the ear is quite different having goals associated with only five phases and not surprisingly featuring the maven-ear-plugin in a couple of those.
List of predefined package types as of maven v3.0.4:
jar, war, ear, pom, ejb, ejb3, maven-plugin, rar, par
from C:\projects\Intro\maven\maven-core\target\classes\META-INF\plexus\components.xml
The Build
We now have enough knowledge to add a line or ten to the build where we need some behaviour that is not predefined. Let us say we need to add scripts that build a database so that we can run our application in our development environment.
If we search for Maven SQL on google we find sql-maven-plugin home page at the top of the results list. You typically find an example of what to include in the build section on the usage page. Copyright?
<project>
[...]
<build>
[...]
<plugins>
[...]
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.5</version>
<dependencies>
<!-- specify the dependent JDBC driver here -->
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
</dependency>
</dependencies>
<!-- common configuration shared by all executions -->
<configuration>
<driver></driver>
<url></url>
<username></username>
<password></password>
[...]
</configuration>
<executions>
<execution>
<phase></phase>
<goals>
<goal>execute</goal>
</goals>
<!-- specific configuration for this execution -->
<configuration>
<!-- specify your SQL commands, can be all of the following configurations -->
<fileset></fileset>
<sqlCommand></sqlCommand>
<srcFiles>
<srcFile></srcFile>
[...]
</srcFiles>
</configuration>
</execution>
<execution>
[...]
</execution>
[...]
</executions>
</plugin>
[...]
</plugins>
[...]
</build>
[...]
</project>
There are 3 main sections for the plugin: dependencies, configuration and executions. In addition the groupid, artifactid and version are provided so that the correct component can be downloaded from the repository.
<project>
<!-- other project stuff -->
<build>
<!-- other build stuff, e.g. location info -->
<plugins>
<!-- other plugins -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.5</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</dependencies>
<configuration>
<driver>com.mysql.jdbc.Driver</driver>
<url>myserver</url>
<username>mike</username>
<password>password1</password>
<delimiter>/</delimiter>
<delimiterType>row</delimiterType>
<srcFiles>
<srcFile>src/main/db/myscript.sql</srcFile>
</srcFiles>
</configuration>
<executions>
<execution>
<phase>generate-test-sources</phase>
<goals>
<goal>execute</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Dependencies
Most dependencies required by the plugin are automatically downloaded. However, in the case of the sql plugin it has no way of knowing, when it is built, what driver will be required for it to its job. The app developer must add that dependency to the plugin section when using it.
There is a slightly different case where a plugin may cause dependencies to be added but in this latter case dependencies are added to the main project rather than to the plugin. The case is where the plugin generates code. For instance, when using Axis a project dependency on axiom will be created as that library is required and build and run time.
The only documentation for such non-transitive dependencies tends to be the plugin’s homepage, if you’re lucky, or the web.
The plugin’s dependencies should be distinguished from the main project’s dependencies but see the para on axiom above.
Configuration
The configuration section allows information to be passed between the project and the plugin. The maven infrastructure has little interest in this.
The most complete source for possible configuration parameters is the output from the Maven command mvn help:describe -Dplugin=<groupid>:<artifactid>:<version> -Dfull. The output for mvn help:describe -Dplugin=org.codehaus.mojo:sql-maven-plugin:1.5 is:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building minimal 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-help-plugin:2.1.1:describe (default-cli) @ minimal ---
[INFO] org.codehaus.mojo:sql-maven-plugin:1.5
Name: SQL Maven Plugin
Description: Execute SQL Statements
Group Id: org.codehaus.mojo
Artifact Id: sql-maven-plugin
Version: 1.5
Goal Prefix: sql
This plugin has 2 goals:
sql:execute
Description: Executes SQL against a database.
Implementation: org.codehaus.mojo.sql.SqlExecMojo
Language: java
Available parameters:
autocommit (Default: false)
Expression: ${autocommit}
Set to true to execute none-transactional SQL.
delimiter (Default: ;)
Expression: ${delimiter}
Set the delimiter that separates SQL statements.
delimiterType (Default: normal)
Expression: ${delimiterType}
The delimiter type takes two values - 'normal' and 'row'. Normal means
that any occurrence of the delimiter terminate the SQL command whereas
with row, only a line containing just the delimiter is recognized as the
end of the command.
For example, set this to 'go' and delimiterType to 'row' for Sybase ASE
or MS SQL Server.
driver
Expression: ${driver}
Database driver classname.
driverProperties
Expression: ${driverProperties}
Additional key=value pairs separated by comma to be passed into JDBC
driver.
enableAnonymousPassword (Default: false)
Ignore the password and use anonymous access. This may be useful for
databases like MySQL which do not allow empty password parameters in the
connection initialization.
enableBlockMode
Expression: ${enableBlockMode}
When true, the whole SQL content in sqlCommand, srcFiles and fileset are
sent directly to JDBC in one SQL statement. This option is for executing
database stored procedures/functions.
Deprecated. Use {@link #delimiterType} instead.
enableFiltering (Default: false)
Expression: ${enableFiltering}
Set to true if you want to filter the srcFiles using system-, user- and
project properties
encoding (Default: ${project.build.sourceEncoding})
Expression: ${encoding}
Encoding to use when reading SQL statements from a file.
escapeProcessing (Default: true)
Expression: ${escapeProcessing}
Argument to Statement.setEscapeProcessing If you want the driver to use
regular SQL syntax then set this to false.
fileset
File(s) containing SQL statements to load. Only use a Fileset if you want
to use ant-like filepatterns, otherwise use srcFiles. The order is based
on a matching occurrence while scanning the directory (not the order of
includes!).
forceMojoExecution (Default: false)
Expression: ${forceOpenJpaExecution}
Setting this parameter to true will force the execution of this mojo,
even if it would get skipped usually.
keepFormat (Default: false)
Expression: ${keepFormat}
Keep the format of an SQL block.
onError (Default: abort)
Expression: ${onError}
Action to perform if an error is found. Possible values are abort and
continue.
orderFile
Expression: ${orderFile}
Set the order in which the SQL files will be executed. Possible values
are ascending and descending. Any other value means that no sorting will
be performed. Refers to fileset and srcFiles
outputDelimiter (Default: ,)
The delimiter used to separate fields in the output when using
printResultSet.
outputFile
Dump the SQL execution's output to a file.
Default value is: System.out.
password
Expression: ${password}
Database password. If not given, it will be looked up through
settings.xml's server with ${settingsKey} as key.
printResultSet (Default: false)
Expression: ${printResultSet}
Print SQL results.
settingsKey
Expression: ${settingsKey}
Server's id in settings.xml to look up username and password. Defaults to
${url} if not given.
skip (Default: false)
When true, skip the execution.
skipOnConnectionError (Default: false)
Expression: ${skipOnConnectionError}
Skip execution when there is an error obtaining a connection. This is a
special case to support databases, such as embedded Derby, that can
shutdown the database via the URL (i.e. shutdown=true).
sqlCommand
Expression: ${sqlCommand}
SQL input commands separated by ${delimiter}.
srcFiles
List of files containing SQL statements to load.
url
Expression: ${url}
Database URL.
username
Expression: ${username}
Database username. If not given, it will be looked up through
settings.xml's server with ${settingsKey} as key.
sql:help
Description: Display help information on sql-maven-plugin.
Call
mvn sql:help -Ddetail=true -Dgoal=<goal-name>
to display parameter details.
Implementation: org.codehaus.mojo.sql.HelpMojo
Language: java
Available parameters:
detail (Default: false)
Expression: ${detail}
If true, display all settable properties for each goal.
goal
Expression: ${goal}
The name of the goal for which to show help. If unspecified, all goals
will be displayed.
indentSize (Default: 2)
Expression: ${indentSize}
The number of spaces per indentation level, should be positive.
lineLength (Default: 80)
Expression: ${lineLength}
The maximum length of a display line, should be positive.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.344s
[INFO] Finished at: Fri Sep 21 08:21:00 BST 2012
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------
More or less the same output can also be produced with mvn sql:help -Ddetail=true -Dgoal=execute. It is slightly more to the point.
You can expect to see primitive data types and arrays (see sourcefiles, above).
Often configuration parameters can be specified by means of maven POM properties. This plugin by plugin, parameter by parameter basis. In the above example of sql, username, password and delimiter and many others can be specified as properties.
Instead of:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.5</version>
<configuration>
<delimiter>/</delimiter>
</configuration>
<!-- other stuff -->
</plugin>
we can have:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.5</version>
<!-- other stuff -->
</plugin>
<proprerties>
<delimiter>/</delimiter>
</properties>
The surefire test controller referenced by default in the test phase provides a better example where:the configuration parameter skip is equivalent to the maven.test.skip.
When trying to suppress unit tests instead of:
<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
<executions>
<execution>
<id>default-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
<configuration>
<skip>true</skip>
</configuration>
</executions>
</plugin>
with:
<properties><maven.test.skip>true</maven.test.skip></properties>
or even just -Dmaven.skip.test on the command line.
This is another mechanism to promote economy of instructions.
Of course this is distinct from doing <skip>${db.skip}</skip>
surefire documentation claims that skip will omit the build stage of tests. How can this be? build is done by compile.
For sql delimiter, username, password and many others can be specified using maven properties.
Which one takes precedence.
Configuration sections may be present for the plugin as a whole and / or the individual execution sections.
Executions
Typically if a plugin section is included in the build/plugins section then it will contain an <executions> section. If it appears in the pluginManagement section then it may not have one in that context.
The execution section allows the phase to be specified, i.e. when it should occur in the build cycle. In our example above we’ve chosen to run our database scripts in the generate-test-sources. Arguably the plugin should be bound to the generate-test-resources phase as databases are more like resources than sources but from Maven’s point of view it makes no difference as long as the task gets executed before the test phase (or to be precise, whatever the first phase is, at which the database will be needed). It does of course matter from a human readability point of view.
Whereas the phase is important to the Maven infrastructure and determines the point at which a task is executed, the goal is important to the plugin and determines what is done. Most plugins have at least two goals (one of which will typically be help) so it is necessary to specify the goal in the execution section.
The other possible attributes of an execution are id and configuration which are both relevant where multiple executions are involved. (Actually there is an inherited attribute which is relevant to pluginManagement (does it apply to build sections within profiles - I should think not).
Multiple Executions
Imagine we also have an sqlite database in play. We may also need to execute scripts against that during the build process.
<project>
<!-- other project stuff -->
<build>
<!-- other build stuff, e.g. location info -->
<plugins>
<!-- other plugins -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.5</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</dependency>
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.7.2</version>
</dependency>
</dependencies>
<configuration>
<username>mike</username>
<delimiter>/</delimiter>
<delimiterType>row</delimiterType>
</configuration>
<executions>
<execution>
<id>mysql_scripts</id>
<phase>generate-test-sources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<driver>com.mysql.jdbc.Driver</driver>
<url>mymysqlserver</url>
<password>password1</password>
<srcFiles>
<srcFile>src/main/db/myscript.sql</srcFile>
</srcFiles>
</configuration>
</execution>
<execution>
<id>sqlite_scripts</id>
<phase>generate-test-sources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<driver>sqlite (verify this)</driver>
<url>mysqliteserver</url>
<password>password2</password>
<srcFiles>
<srcFile>src/main/db/mysqllite_script.sql</srcFile>
</srcFiles>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
We have added a dependency for SQLite. The sql plugin will rely on this for its second execution, the one agains the sqlite database. We have added an extra execution given the executions distinct ids to aid debugging Mandatory?? Finally we have shifted some of the configuration into the execution sections so that appropriate connection strings can be used and the correct source files.
It’s worth noting that one of the plugins used by default in the default lifecycle for the jar packaging, maven-resources-plugin, has multiple executions one for production resources and the other for test resources.
The above scenario can be contrasted with one where multiple goals are specified for the same execution. Multiple goals would operate against the same configuration information, presumably, performing distinct tasks.
Where is the default goal defined?
User Provided Libraries
Builds may need to incorporate libraries that are not available from the artefact repository in use. There are two ways to address this issue: either install the library into the local copy of the repository (link to this) or the dependency can refer to an artefact outside of the maven ecosystem.
Install Artefact Locally
The command
mvn install:install-file <file path and name>
can be used to add a dependency to the local repository
Local Reference
Alternatively you can configure the dependency to reference some arbitrary local file with the following:
<project>
<!—other project stuff -->
<dependencies>
<!—other dependencies -->
<dependency>
<groupId></groupId>
<artefactId></artefactId>
<version></version>
<scope>system</scope>
<systemPath></systemPath>
</dependency>
</dependencies>
<!—other project stuff -->
</project>
Make up some suitable identifiers for groupId, artefactId and version to keep Maven and its plugins happy. A scope of system indicates that the reference is found locally at the location and with the name specified by systemPath.
Will the ear packager pick up the system scoped dependencies?
Multiple Projects
Complex builds can be simplified by segregating parts of a solution into separate project files and by using inheritance to pick up settings from a parent POM.
Multiple Modules
A common pattern that employs multiple modules is a solution to produce an ear file. Typically you would have a POM for a war, a POM for the ear and a POM to control both.
Example of ear and war
Child projects in sub-directories or specified using a relative path http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
Inheritance
What is inherited?
Elements in the POM that are merged are the following:
dependencies
developers and contributors
plugin lists (including reports)
plugin executions with matching ids
plugin configuration
resources
Ancillary Life-cycles
Subsidiary lifecycles
Variety
Executing Goals Directly
So far our command line has specified the phases of life-cycles, for instance “mvn clean install” instructs Maven to execute the plugins in (bound to) all phases up to and including the clean phase of the clean life-cycle followed by the plugins in all phases up to and including the install phase of the default lifecycle.
You can specify other phases on the command line, for instance whereas “mvn install” executes all phases except the deploy phase (the final phase), “mvn compile” will execute no further than the compile phase. If we invoked Maven with “mvn compile” for the minimal configuration mentioned previously it would execute two plugins, firstly to copy resources and then to compile.
The issue is confused by the fact that you can specify goals directly on the command line. For instance when creating a project you invoke Maven with “mvn archetype:generate”. This directly executes the goal generate of the archetype plugin.
The tokens on the command line represent different Maven concepts. In the case of “mvn clean install” or “mvn compile” the values refer to phases whereas in the case of “mvn archetype:generate” ignores phases altogether and concentrates on the plugins.
The command line specification can look very similar. Compare “mvn install” with “mvn install:install-file…”. In the first example “install” refers to a Maven lifecycle phase, in the second to the plugin maven-install-plugin. Another way to express the second example is “mvn org.apache.maven.plugins:maven-install-plugin:install-file”.
Similarly for compile “mvn compile” can be contrasted with “mvn compile:compile”. There is no requirement for the names of the plugins install and compile to be the same as the names of the phases.
Shortcut
The names compile and install in the direct goal example are plugin goal prefixes. Goal prefixes are assigned from two sources. If the name of the plugin artefact has the pattern <name>-maven-plugin or maven-<name>-plugin then the prefix will be <name>. Alternatively, the prefix can be set in the file, maven-metadata-central.xml found in the root directory corresponding to the groupId. These prefix assignments work fine for the predefined plugin groups of maven-plugins and codehaus-mojo. If plugins are added from some other source and you want to use the prefix then there is one more piece of configuration. You can add new prefixes by modifying settings.xml and adding the group id of the plugins to the pluginGroups section.
The final issue to consider is whether when goals are executed previous phases are executed.
Further complicated by goals that cause other phases to be executed.
Execution of dependencies and role of inheritance
Summary
The build section of the POM file specifies the steps required to build the project. You can think of maven as executing the build section of the POM.
The information is not provided in the form of steps to be carried out by maven but rather specified by identifying the tools (plugins) to be used and the tasks (goals), supported by each plugin, to be performed. The selection of tasks from the POM to be executed is controlled by the parameters passed to the maven command line.
The order in which tasks are performed is determined from the phase associated with each goal.
The phases are executed in a fixed order according to a lifecycle.
To summarise: a task to be performed and its timing in the build process are determined by the following five identifiers:
Lifecycle
Phase
Plugin
Goal
Execution Id
A goal can have multiple execution ids. This feature allows the goal to be executed multiple times, each time with different configuration data.
Pre-defined Plugin Bindings
The following plugins are used in the default lifecycle for jar, war, ejb3, maven-plugin, rar and par packagings. That is to say, these are the plugins and goals that get included if you generate a fairly standard POM and don’t make to many changes.
Copy Resources
Group Id: org.apache.maven.plugins
Artefact Id: maven-resources-plugin
Current version: 2.3
Bound to phases: process-resources, process-test-resources
Interesting goals: resources, testResources
Home Page: http://maven.apache.org/plugins/maven-resources-plugin/
Description:
The usage page does not specify http://maven.apache.org/plugins/maven-resources-plugin much - needs some explanation
Two goals from the the resources plugin are executed in the pre-fefined default lifecycle for packagings such as jar and war.
The resources goal is executed in the process-resources phase; the testResources goal is executed in the process-test-resources phase.
In both cases the plugin copies all the data from a well-known source directory to a well-known target directory.
Example
Commentary:
Compile
http://maven.apache.org/plugins/maven-compiler-plugin/
Group Id: org.apache.maven.plugins
Artefact Id: maven-compiler-plugin
Current version: 2.3
Bound to phases: compile, test-compile
Interesting goals: compile, testCompile
Home Page: http://maven.apache.org/plugins/maven-compiler-plugin/
Description:
Example
Commentary:
The compilerVersion parameter can be used to specify the version of the compiler that the plugin will use. However, you also need to set fork to true for this to work. For example:
Testing
maven-surefire-plugin (runs tests)
http://maven.apache.org/plugins/maven-surefire-plugin/
uses dependencies in POM to determine which provider to use
Packaging
maven-jar-plugin
http://maven.apache.org/plugins/maven-jar-plugin/
What is it that it chooses to package? Contents of target?
Install and Deploy
maven-install-plugin
http://maven.apache.org/plugins/maven-install-plugin/
What is it that it chooses to install? What about artefacts built using the assembly plugin?
maven-deploy-plugin
http://maven.apache.org/plugins/maven-deploy-plugin/
Useful Plugins
The following plugins differ from those involved in the predefined bindings discussed in the previous section. In particular, the phase in which the plugins goals were executed were determined by maven (that’s what made them pre-defined. The following plugins are not necessarily bound to a phase and where they are, it is the plugin that has made the choice rather than the maven infrastructure.
Ant (antrun)
Group Id: org.apache.maven.plugins
Artefact Id: maven-antrun-plugin
Current version: 1.6
Bound to phase by default: none
Goal Prefix: antrun
Interesting goal: run
Home Page: http://maven.apache.org/plugins/maven-antrun-plugin/
Description:
The ant plugin can perform operations related to developmentwhich are not provided by other maven plugins. These cover such areas as file manipulation, sending mail, dealing with archive (jar etc.) files. See http://ant.apache.org/manual/tasksoverview.html#log for details.
To ensure that the build fails if an ant task fails you need to include <failOnError/> in the configuration of the plugin.
Example
Invoke maven with mvn install
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mdamay.com</groupId>
<artifactId>bosscat</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>bosscat Webapp</name>
<url>http://maven.apache.org</url>
<properties>
<ws.endpoint>disappointedprogrammer.com/sad.wsdl</ws.endpoint>
</properties>
<profiles>
<profile>
<id>Mike</id>
<activation>
<property>
<name>user.name</name>
<value>Mike</value>
</property>
</activation>
<properties>
<ws.endpoint>dev.disappointedprogrammer.com/sad.wsdl</ws.endpoint>
</properties>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
<build>
<finalName>bosscat</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target name="echo">
<echo>end point is set to ${ws.endpoint}</echo>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Commentary:
The following example addresses the condition in a complex build comprising multiple modules and different profiles. In the last stage of the build, the install phase, it prints out data that may vary according to who is doing the build and may not be easily discernable from an inspection of the POMS. In our case the web-service end point (ws.endpoint) can be overridden by the user specific profile for the user Mike. All users except Mike will be reassured by seeing “end point is set to disappointedprogrammer.com/sad.wsdl” at the end of the build whereas Mike may be conveniently reminded that in the artefacts built by him the “end point is set to disappointedprogrammer.com/sad.wsdl”.
Unlike Maven Ant requires the components on which it relies to be installed by the user (I think).
One of the experiments that we do later is to provide enforcer rules to attempt to check on the presence of the required Ant dependencies.
Alternatives to Ant tend to produce more expressive sets of commands.
Enforcer
Group Id: org.apache.maven.plugins
Artefact Id: maven-enforcer-plugin
Current version: 1.1.1
Bound to phase by default: validate (doesn’t appear to be)
Interesting goal: enforce
Home Page: http://maven.apache.org/plugins/maven-enforcer-plugin/
Description:
The enforcer plugin allows you to make assertions about the project and the environment. For instance you can ensure that maven is running under an appropriate version of the JDK (which may be demanded by plugins or required for the compilation). If an assertion proves to be false the build can be stopped and the issue brought to the user’s attention.
This is particularly useful where you expect many users to access the project casually. It enables them to come up to speed quickly on the pre-requisites for the project. Watch out for <prerequisites/> tag.
Example:
Invoke maven with mvn validate
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mdamay.com</groupId>
<artifactId>bosscat</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>bosscat Webapp</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
<build>
<finalName>bosscat</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.1.1</version>
<configuration>
<fail>true</fail>
<rules>
<requireMavenVersion>
<message>This POM will only run under Maven version 2.0.1</message>
<version>[2.0.1]</version>
</requireMavenVersion>
</rules>
</configuration>
<executions>
<execution>
<phase>validate</phase>
<goals><goal>enforce</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Commentary:
The rules described at http://maven.apache.org/enforcer/enforcer-rules/index.html are not very comprehensive but it is fairly easy to add custom rules following the instructions at http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html.
Assembly
Group Id: org.apache.maven.plugins
Artefact Id: maven-assembly-plugin
Current version: 2.3
Bound to phase by default: none
Interesting goal: single
Home Page: https://maven.apache.org/plugins/maven-assembly-plugin/
Description:
The assembly plugin is quite a beast handling a variety of tasks relating to assembling the final artefacts of a build
Example
Command Line: mvn assembly:single
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mdamay.com</groupId>
<artifactId>bosscat</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>bosscat Webapp</name>
<url>http://maven.apache.org</url>
<properties>
<ws.endpoint>disappointedprogrammer.com/sad.wsdl</ws.endpoint>
</properties>
<profiles>
<profile>
<id>Mike</id>
<activation>
<property>
<name>user.name</name>
<value>Mike</value>
</property>
</activation>
<properties>
<ws.endpoint>dev.disappointedprogrammer.com/sad.wsdl</ws.endpoint>
</properties>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<descriptor>assembly.xml</descriptor>
</configuration>
</plugin>
</plugins>
</build>
</project>
<?xml version="1.0" encoding="us-ascii" ?>
<assembly>
<id>mike</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>src</directory>
</fileSet>
</fileSets>
</assembly>
Commentary:
Configuration must sit outside execution. http://stackoverflow.com/questions/967779/maven-assemblyassembly
Requires an introduction of its own. I can’t do justice to it.
We don’t attempt to bind this to a phase although we could add it in at pretty much any phase.
Release
Group Id: org.apache.maven.plugins
Artefact Id: maven-release-plugin
Current version: 2.3.2
Bound to phase by default: none
Interesting goal: prepare, perform
Home Page: http://maven.apache.org/plugins/maven-release-plugin/
Description:
The release plugin performs housekeeping associated with making a release. It does not deploy the artefacts to a server or build an installation package.
Example
Commentary:
Exec
Group Id: org.mojo.codehaus
Artefact Id: exec-maven-plugin
Current version: 1.2.1
Bound to phase by default: none
Interesting goal: exec, java
Home Page: http://mojo.codehaus.org/exec-maven-plugin/
Description:
The exec plugin can execute external programs through its exec goal or java code through
Handling errors!!
Esample
Command Line: mvn clean install
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mdamay.com</groupId>
<artifactId>bosscat</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>bosscat Webapp</name>
<url>http://maven.apache.org</url>
<properties>
<devtoolsPath>${project.build.directory}\test-classes</devtoolsPath>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>remove_devtools_directory</id>
<phase>clean</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target name="remove_devtools_directory">
<delete dir="${devtoolsPath}"/>
</target>
</configuration>
</execution>
<execution>
<id>make_devtools_directory</id>
<phase>initialize</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target name="make_devtools_directory">
<mkdir dir="${devtoolsPath}"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>build_devtools</id>
<goals><goal>exec</goal></goals>
<phase>generate-resources</phase>
<configuration>
<executable>javac</executable>
<arguments>
<argument>-d</argument>
<argument>${devtoolsPath}</argument>
<argument>${basedir}\src\devtools\disappointed\*.java</argument>
</arguments>
</configuration>
</execution>
<execution>
<id>run_devtools</id>
<phase>install</phase>
<goals><goal>java</goal></goals>
<configuration>
<mainClass>disappointed.SoundPlayer</mainClass>
<classpathScope>test</classpathScope>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
https://github.com/mikedamay/maven_commentary/blob/master/bosscat/src/devtools/disappointed/SoundPlayer.java
Commentary:
The execution run_devtools invokes the sound player using the java goal in the install phase. I have not attempted the more difficult task of running the sound player when maven completes irrespective of the phase of completion.
The build_devtools execution compiles the code. It builds the code in src/devtools into test-classes. The code has to be built into test-classes or classes in order to have it included in maven’s class path for the run_devtools invocation. We could have included the code as test code and avoided a specific compile step but this utility code rightly belongs in a devtools folder and not in the project’s production or test code.
This pig-headed requirement to have a source directory away from the main project source also explains the remove_devtools_directory and make_devtools directory ant executions. As we no tests in the project we cannot rely on the test-compile phase to create the directory.
Archetype
Group Id: org.apache.maven.plugins
Artefact Id: maven-archetype-plugin
Current version: 2.2
Bound to phase by default: does not use POM
Interesting goal: generate
Home Page: http://maven.apache.org/archetype/maven-archetype-plugin/
Description:
This is a shortcut to create project directory trees and skeleton POM.
Esample
None is appropriate
Commentary
This is the first plugin that does not depend on an existing project to operate.
Build Helper
Group Id: org.apache.maven.plugins
Artefact Id: maven-archetype-plugin
Current version: 2.2
Bound to phase by default: does not use POM
Interesting goal: generate
Home Page: http://mojo.codehaus.org/build-helper-maven-plugin
Description:
Example
None is appropriate
Commentary
This plugin allows you to breach some of the constraints of maven.
Experiments
Show how plugins can optionally have a phase to which they are bound
All plugins other than the default ones mentioned previously must be referenced in the build section. The reference there will ensure that the components are downloaded and that the goals are executed in the build cycle.
As a related point the instructions include the dependency
Custom rule to test if ant tomcat or something without a plugin (probably not ant) is present.
Often the best source of information is the plugin via mvn help:describe -Dorg.codehaus.mojo:sql-maven-plugin:1.5 -Dfull
XSLT
link to group id, artifact id and version
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sql-maven-plugin</artifactId>
<version>1.2</version>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>oracle</artifactId>
<version>${oracle.version}</version>
<scope>runtime</scope>
</dependency>
</dependencies>
<configuration>
<driver>oracle.jdbc.OracleDriver</driver>
<url>${db.url}</url>
<username>${db.dba.user}</username>
<password>${db.dba.password}</password>
<delimiter>/</delimiter>
<delimiterType>row</delimiterType>
</configuration>
<executions>
<execution>
<id>drop-db</id>
<phase>generate-test-sources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<skip>${db.skip}</skip>
<autocommit>true</autocommit>
<onError>continue</onError>
<srcFiles>
<srcFile>target/db/drop_ddl.sql</srcFile>
<srcFile>target/db/${db.mviews.drop}</srcFile>
<srcFile>target/db/dbdeploy_drop.sql</srcFile>
</srcFiles>
</configuration>
</execution>
<execution>
<id>create-db</id>
<phase>generate-test-sources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<skip>${db.skip}</skip>
<autocommit>true</autocommit>
<onError>continue</onError>
<srcFiles>
<srcFile>target/db/1_create_tables.sql</srcFile>
<srcFile>target/db/2_create_sequences.sql</srcFile>
<srcFile>target/db/3_insert_data.sql</srcFile>
<srcFile>target/db/${db.mviews.create}</srcFile>
<srcFile>target/db/5_create_views.sql</srcFile>
<srcFile>target/db/6_create_plsql_objs.sql</srcFile>
<srcFile>target/db/7_create_indexes.sql</srcFile>
<srcFile>target/db/${db.mviews.indexes}</srcFile>
<srcFile>target/db/9_create_fk_cons.sql</srcFile>
<srcFile>target/db/10_create_triggers.sql</srcFile>
<srcFile>target/db/11_grant_privs.sql</srcFile>
<srcFile>target/db/dbdeploy_changelog.sql</srcFile>
</srcFiles>
</configuration>
</execution>
<execution>
<id>apply-delta-undo</id>
<phase>generate-test-resources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<skip>${db.delta.skip}</skip>
<autocommit>true</autocommit>
<onError>continue</onError>
<srcFiles>
<srcFile>target/db/delta-undo.sql</srcFile>
</srcFiles>
</configuration>
</execution>
<execution>
<id>apply-delta</id>
<phase>process-test-resources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<skip>${db.delta.skip}</skip>
<autocommit>true</autocommit>
<onError>continue</onError>
<srcFiles>
<srcFile>target/db/delta.sql</srcFile>
</srcFiles>
</configuration>
</execution>
</executions>
</plugin>
A quick search for “axis 2 maven plugin” turns up a page with excellent instructions: http://axis.apache.org/axis2/java/core/tools/maven-plugins/maven-wsdl2code-plugin.html.
XML beans required
http://mvnrepository.com/artifact/org.apache.xmlbeans/xmlbeans/2.4.0
<build>
<plugins>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.5.4</version>
<executions>
<execution>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<packageName>com.sandp.firace.agclient</packageName>
<wsdlFile>http://nj09mhf0270:21201/vfd/services/FinancialStatement.wsdl</wsdlFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
<resource>
<directory>target/generated-sources/axis2/wsdl2code/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test/resources</directory>
<filtering>true</filtering>
</testResource>
</testResources>
</build>
<build>
<plugins>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<packageName>com.foo.myservice</packageName>
<wsdlFile>src/main/wsdl/myservice.wsdl</wsdlFile>
<databindingName>xmlbeans</databindingName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
<version>1.4</version>
</dependency>
Configuration
You might struggle to get the right version of things.
I am frightened by magic and arbitrariness.
How do you know what you need to include jar vs. war or ear..
a) If you are setting out, how do you know what to include in the pom, how do you know how to lay out the files.
b) How to interpret an existing pom or set of poms?
Two types of configuration variable.
Based on maven v3
provide example and then generalise.
convention over configuration frees up the design so that defaulting can be used.
Caught between two ways of thinking. The procedural approach and the “descriptive template” approach.
We’ll use a hypothetical lifecycle which mimics an ETL (Extract Transform Load) process. Our process acquires data, manipulates it in some way and then delivers it, e.g. a batch job to query a database and transform the results into XML files. A lifecycle is associated with the POM’s packaging attribute. In our case we will give packaging a value of “etl”. Adding a packaging and lifecycle requires a custom plugin (a non-trivial task). Our plugin is hypothetical and called org.hypo-plugins:lifecycle-provider-etl-plugin.
Hypothetical Lifecyle Simple Example
We will give our lifecyle 7 phases: init, extract, pre-transform, transform, post-transform, load, terminate. Initially we will uses only three of them.
The phases and associated plugins and goals are summarised in the following table. The implementation is in the form of a POM file, say etl-pom.xml, and they are executed through a command line such as mvn -f etl-pom.xml load. Obviously you’ll be relying upon a hypothetical organisation to provide the plugins that actually perform the processing, not necessarily a guarantee for success.
phase
plugin
prefix
goal
execution id
init
extract
org.hypo-plugins:db-plugin
db
query
default
pre-transform
trasform
org.hypo-plugins:xslt-plugin
xslt
process
default
post-transform
load
org.hypo-plugins:ftp-plugin
ftp
put
default
terminate
Note that goal prefixes, such as db, xslt and ftp, are attributes of the plugins, and effectively hard-coded by them, as aliases for the plugin identity, and not subject to configuration.
The first phase to be executed is init. As no plugins have a goal bound to this phase, nothing happens. Goals associated with the extract phase are then executed. In our case a database plugin will execute some query which we will specify in the plugin’s configuration section of the POM. There follows another empty phase and then transform which will pick up the data and process it by executing the process goal of the xslt plugin. The data will be communicated between the phases via the file system (something that suits a build process but not really our hypothetical ETL process). Format and location have to be agreed between the plugins. The file system is the most obvious choice but anything that’s agreed between the plugins will work. Finally after another blank phase, the put goal of the ftp plugin is invoked to upload the data to some configured location.
The terminate phase is not executed as we specified load on the command line. Maven executes the goals associated with all phases up to and including the phase specified on the command line. See elsewhere for specifying goals rather than phases on the command line.
Below is the POM file for the hypothetical ETL process (etl-pom.xml):
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.hypo-plugins</groupId>
<artifactId>etl-payload</artifactId>
<version>1.0.1-SNAPSHOT</version>
<packaging>etl</packaging>
<name>ETL Payload</name>
<description>Delivers XML files from DB</description>
</project>
Not only can a plugin can have multiple goals which can be executed at different stages of the build process but a goal can be repeated many times potentially in a different phase. The execution id is used to distinguish one instance from another. The primary purpose of the goal identifier is to determine what feature of the plugin is executed. One purpose of the execution id identifier, associated as it is with a phase, is to determine when the feature will be executed during the build. In addition, the execution id will most likely associate different configuration information with each instance of the goal. For instance, the process-resources goal may be repeated each time with a different filter on which files are copied.
Fake packaging with differences between imperative and declarative.
A typical entry might look something like the following:
<project>
...
<build>
...
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
...
</build>
...
</project>
From SonaType’s Complete Reference: http://www.sonatype.com/books/mvnref-book/reference/lifecycle-sect-common-goals.html
For the other two lifecyles provided by maven see ttp://www.avajava.com/tutorials/lessons/what-are-the-phases-of-the-maven-clean-lifecycle.html for a description of the clean lifecycle and http://www.avajava.com/tutorials/lessons/what-are-the-phases-of-the-maven-site-lifecycle.html for the site lifecycle.
Lifecycles and Phases - Bound and Unbound Goals
Maven plugins (software tools written to the maven extensibility specification) can have a number of goals (tasks to be executed by the software). Some goals are a natural part of the software build process, for instance, the execution of tests. Other tasks, still called goals, that can be performed by the plugin are not a natural fit, for instance, most plugins provide a help goal to display information on the console about the plugin.
For a goal to be part of the build process it must be associated with a phase. There are a dozen or so phases, such as compile, test, install, corresponding to traditional steps in the build process. The phases are grouped into lifecycles. Phases effectively determine the order in which goals are executed. There are three lifecycles: default (or build), clean and site (which generates documentation.
Goals that have a phase specified for them are seen as being bound to a life cycle. All other goals are unbound. Because all phases within a lifecycle are named uniquely with respect to all three life cycles maven knows which life cycle a goal is bound to purely from the name of its associated phase.
To execute the build process maven is invoked with a specified phase. For instance “mvn install” will cause maven to execute the goals associated with all phases from validate to test (inclusive). It executes the specified phase and all phases in the lifecycle that precede it.
To execute an unbound goal you pass the name of the plugin, or its prefix (a shorthand identifier for the plugin) together with the goal to mvn. For example mvn org.apache.maven.plugins:maven-archetype-plugin:generate or mvn archetype:generate will start the process of generating the structure of a new project. In this example the archetype plugin has a goal prefix of archetype. In this respect the archetype plugin follows the convention of using the word before “plugin” in the plugin name as its prefix Bound goals behave like unbound goals when specified on the command line. The phase is ignored and the behaviour associated with the goal alone and no preceding goals is executed .
It is instructive to contrast mvn install with mvn install:install. The latter fails.
Execution
Default Behaviour
The specification of exactly what build steps are executed is complicated by the default goals that are included irrespective of what is detailed by the developer in the build section of the POM.
Assuming that your java files are in the conventional location, <project dir>\src\main\java and <project dir>\src\est\java then executing the command mvn -f <pom file> install will cause code to be compiled to the <project dir>\target directory.
Note that most of the phases have no goals associated with them. We can alter the build by adding goals to the unused phases or additional goals to the phases that have a goal, although there can be no execution order dependencies between goals in the same phase. The behaviour of default goals can be varied by specifying in the build section.
Goal based approach gives maven two qualitiies, highlighting differences and inheritance.
Plugin Identification
Command Line
Install Maven from http://maven.apache.org/download.html.
proxy issue???
Generate your first project structure with the following command line: This will layout a structure in the file system and will generate a project build file which will subsequently be used to build the project. You will need to provide some source code in C:\projects\Intro\try-select-arch\src\main\java and your test in C:\projects\Intro\try-select-arch\src\test\java.
The command line is “mvn archetype:generate -DarchetypeCatalog=remote -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=intro.duction -DartifactId=try-select-arch -Dpackaging=jar -Dversion=0.0.1 -DinteractiveMode=false”
If you have an existing project then copy over the sources into C:\projects\Intro\try-select-arch\src\main\java.
This will generate a directory tree as follows:
C:\projects\Intro>dir /s /b try-select-arch
C:\projects\Intro\try-select-arch\pom.xml
C:\projects\Intro\try-select-arch\src
C:\projects\Intro\try-select-arch\src\main
C:\projects\Intro\try-select-arch\src\test
C:\projects\Intro\try-select-arch\src\main\java
C:\projects\Intro\try-select-arch\src\main\java\intro
C:\projects\Intro\try-select-arch\src\main\java\intro\duction
C:\projects\Intro\try-select-arch\src\main\java\intro\duction\App.java
C:\projects\Intro\try-select-arch\src\test\java
C:\projects\Intro\try-select-arch\src\test\java\intro
C:\projects\Intro\try-select-arch\src\test\java\intro\duction
C:\projects\Intro\try-select-arch\src\test\java\intro\duction\AppTest.java
and a project object model file (or pom but understood by Eclipse and IntelliJ, as well as Maven, as follows:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>intro.duction</groupId>
<artifactId>try-select-arch</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<name>try-select-arch</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
All maven commands start with “mvn” to invoke the executable.
“archetype” identifies, by means of a shortcut “prefix”, the plugiin that is to be executed. A plugin is an added in component that is registered with maven to provide some feature. In this case the full details of the plugin are: org.apache.maven.plugins:maven-archetype-plugin. Such identities are understood by the maven infrastructure.
“generate” is a goal provided by the archetype plugin.
The arguments prefixed by -D are configuration parameters which are meaningful to the archetype plugin. Use -X or help:describe.
The project file, pom.xml, enables the developer to build a jar file from sources placed in the appropriate directories.
Below we will look at goals, plugins, dependencies, properties and co-ordinates.
A similar command “mvn archetype:create -DgroupId=myorg.org -DartifactId=myapp -Dpackaging=jar -DVersion=0.0.1” has been deprecated. It’s effectively the same but does
Phases of life cycle can be viewed by adding -X to command line.
Phase to which a plugin goal is bound is available by doing mvn help:describe -Dplugin= -Dfull
Many goals are unbound, e.g. help, archetype
Side bar on the naming of life-cycle phases
from a conceptual standpoint the phases of the install life-cycle, validate, initialise, gnerate-sources...compile...deploy could easily have been called install-phase-1, install-phase-2, install-phase-3...install-phase-7...install-phase-23. Maven imposes no requirement that you do the compilation in the compile phase although your colleagues may be keen for you to follow the convention.
Phase
plugin
goal
execution id
validate
org.apache.maven.plugins:maven-resources-plugin
resources
default-resources
initialize
org.apache.maven.plugins:maven-compiler-plugin
compile
default-compile
generate-sources
org.apache.maven.plugins:maven-resources-plugin
testResources
default-testResources
process-sources
org.apache.maven.plugins:maven-compiler-plugin
testCompile
default-testCompile
generate-resources
org.apache.maven.plugins:maven-surefire-plugin
test
default-test
process-resources
org.apache.maven.plugins:maven-jar-plugin
jar
default-jar
compile
org.apache.maven.plugins:maven-install-plugin
install
default-install
process-classes
org.apache.maven.plugins:maven-deploy-plugin
deploy
default-deploy
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources
test-compile
process-test-classes
test
prepare-package
package
pre-integration-test
integration-test
post-integration-test
verify
install
deploy
For a description of the site lifecycle try http://www.avajava.com/tutorials/lessons/what-are-the-phases-of-the-maven-site-lifecycle.html
For a description of the clean lifecycle try
http://www.avajava.com/tutorials/lessons/what-are-the-phases-of-the-maven-clean-lifecycle.html
document structure
intro showing steps
create lifecytle
map concepts to build lifecytle
show effect of defaults on pom.
alternative structure:
intro explaining mvn install in narrative form with reference to phases in parentheses.
Table of standard build corresponding to the above.
mention effective-pom and -X
---- new section
Examine architecture lifecyle->phase->plugin+goal->execution id. Reference to packaging and adding new packaging. Custom lifecycles and custom phases.
add some plugins and reshow default table.
clean and site lifecycles
How does mvn clean install work
Examine maven infrastructure
Show how default build uses the infrastructure
Show how the pervasive use of default values (convention over configuration) reduces the size of the pom.
Maven Technical FAQ: http://maven.apache.org/general.html
Intro
this piece is intended to demystify the build process and answer questions like why can I type mvn clean or mvn test or mvn archetype but not mvn test-resources or mvn dbdeploy?
What tools are executed, when are they executed and what do they do?
How can I add my own libraries?
why can I sometimes use a goal pefix and sometimes not. Because some goal prefxes are registered or the artefact follows the naming convention to extract the prefix, I think.
Detail how plugins typically have a configuration key:value arrangement which can be short circuited by using a default property. Typically specified on the plugin usage page or whatever it is called
ant 2 execution ids.
echo <executable>${maven.compiler.executable}</executable>
xml with multiple executions
exec-maven-plugin
http://mojo.codehaus.org/exec-maven-plugin/
not executed by mvn install
the POM stored with the artefact in the local repository is used to specify how it should be deployed.
Assembly plugin
distributionManagement - purpose of deploy is not explained in the plugin documentation
List of plugins including PREFIXES.
phase
plugin
prefix
goal
execution id
validate
initialize
generate-sources
process-sources
generate-resources
process-resources
org.apache.maven.plugins:maven-resources-plugin
resources
resources
default-resources
compile
org.apache.maven.plugins:maven-compiler-plugin
compile
compile
default-compile
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources
org.apache.maven.plugins:maven-resources-plugin
resources
testResources
default-testResources
test-compile
org.apache.maven.plugins:maven-compiler-plugin
compile
testCompile
default-testCompile
process-test-classes
test
org.apache.maven.plugins:maven-surefire-plugin
surefire
test
default-test
prepare-package
package
org.apache.maven.plugins:maven-jar-plugin
jar
jar
default-jar
pre-integration-test
integration-test
post-integration-test
verify
install
org.apache.maven.plugins:maven-install-plugin
install
install
default-install
deploy
org.apache.maven.plugins:maven-deploy-plugin
deploy
deploy
default-deploy
Very pale blue and not underlined for links.
A plugin must be placed in the plugins section of the build seciton or of the profiles section or the pluginManager
Trying to avoid contrived examples.
Afterthought
parent
The location of the parent project, if one exists. Values from the parent project will be the default for this project if they are left unspecified. The location is given as a group ID, artifact ID and version.
modelVersion
Declares to which version of project descriptor this POM conforms.
groupId
A universally unique identifier for a project. It is normal to use a fully-qualified package name to distinguish it from other projects with a similar name (eg. <code>org.apache.maven</code>).
artifactId
The identifier for this artifact that is unique within the group given by the group ID. An artifact is something that is either produced or used by a project. Examples of artifacts produced by Maven for a project include: JARs, source and binary distributions, and WARs.
packaging
The type of artifact this project produces, for example <code>jar</code> <code>war</code> <code>ear</code> <code>pom</code>. Plugins can create their own packaging, and therefore their own packaging types, so this list does not contain all possible types.
name
The full name of the project.
version
The current version of the artifact produced by this project.
description
A detailed description of the project, used by Maven whenever it needs to describe the project, such as on the web site. While this element can be specified as CDATA to enable the use of HTML tags within the description, it is discouraged to allow plain text representation. If you need to modify the index page of the generated web site, you are able to specify your own instead of adjusting this text.
url
The URL to the project's homepage.
prerequisites
Describes the prerequisites in the build environment for this project.
issueManagement
The project's issue management system information.
ciManagement
The project's continuous integration information.
inceptionYear
The year of the project's inception, specified with 4 digits. This value is used when generating copyright notices as well as being informational.
mailingLists
The year of the project's inception, specified with 4 digits. This value is used when generating copyright notices as well as being informational.
developers
Describes the committers of a project.
contributors
Describes the committers of a project.
licenses
This element describes all of the licenses for this project. Each license is described by a <code>license</code> element, which is then described by additional elements. Projects should only list the license(s) that applies to the project and not the licenses that apply to dependencies. If multiple licenses are listed, it is assumed that the user can select any of them, not that they must accept all.
scm
Specification for the SCM used by the project, such as CVS, Subversion, etc.a
organization
This element describes various attributes of the organization to which the project belongs. These attributes are utilized when documentation is created (for copyright notices and links).
build
Information required to build the project.
profiles
A listing of project-local build profiles which will modify the build process when activated.
modules
The modules (sometimes called subprojects) to build as a part of this project. Each module listed is a relative path to the directory containing the module.
repositories
The lists of the remote repositories for discovering dependencies and extensions.
pluginRepositories
The lists of the remote repositories for discovering plugins for builds and reports.
dependencies
This element describes all of the dependencies associated with a project. These dependencies are used to construct a classpath for your project during the build process. They are automatically downloaded from the repositories defined in this project. See <a href="http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html">the dependency mechanism</a> for more information.
reports
Deprecated. Now ignored by Maven.
reporting
This element includes the specification of report plugins to use to generate the reports on the Maven-generated site. These reports will be run when a user executes <code>mvn site</code>. All of the reports will be included in the navigation bar for browsing.
dependencyManagement
Default dependency information for projects that inherit from this one. The dependencies in this section are not immediately resolved. Instead, when a POM derived from this one declares a dependency described by a matching groupId and artifactId, the version and other values from this section are used for that dependency if they were not already specified.
distributionManagement
Distribution information for a project that enables deployment of the site and artifacts to remote web servers and repositories respectively.
properties
Properties that can be used throughout the POM as a substitution, and are used as filters in resources if enabled. The format is <code><name>value</name></code>.a
Sections not considered:
Use case is a large set of files that need to be subjected to a set of tasks with intermediate stages.
Class loaders
intteraction with IDEs
It does not have much to say about:
profiles
scm
distribution management / deployment management
profiles.xml alongside pre-defined phase obfuscate POM.
Resources
http://www.ibm.com/developerworks/java/library/j-5things13/
Mention that org.apache.maven.plugins is the default groupId and does not need to be specified in the plugin section although presumably it does in other contexts.


[[pastacademics.fcid]   Past Academics:
PSAT scores 11th Grade:   {{PSATMSNQprint}}   Math Level: [[pastacademics.highestMathCourse]]  Science Level: [[pastacademics.highestScienceCourse]]  Class Rank: [[pastacademics.classRank]]  Grade: [[pastacademics.grade]]   PSAT 10: [[pastacademics.PSAT10]] PSAT 8/9: [[pastacademics.PSAT89]]


Don't try to run the webassembly project directly, because it needs a server to fetch data from. Instead, run the server project which hosts this webassembly application.


SMD (SOT-223) 3.3v Voltage Regulator 1 A - VS231
Summary
Name: SMD (SOT-223) 3.3v Voltage Regulator 1 A
ID: VREG-SO223-X-V33D-A1
Hex ID: VS231
WebPage: https://github.com/oomlout/oomlout-OOMP/wiki/VREG-SO223-X-V33D-A1
Short URL: http://oom.lt/VS231
Revision History: https://github.com/oomlout/oomlout-OOMP/blob/master/parts/VREG-SO223-X-V33D-A1/
| Type |
Size |
Color |
Description |
Index |
VREG Voltage Regulator |
SO223 SMD (SOT-223) |
X
|
V33D 3.3v |
A1 1 A |
Images
About
This part is awaiting a description.
Specifications
| Info |
Value |
| Type |
Voltage Regulator |
| Size |
SMD (SOT-223) |
| Description |
3.3v |
| Index |
1 A |
Extra Details
Spotted a mistake, want to add more? Let us know<EMAIL_ADDRESS>All images and resources are licensed [CC BY-SA] unless otherwise stated (ie. the datasheets)


s6-networking
Software
skarnet.org
libstls is a small support library for the s6-tlsc and s6-tlsd executables when they're built against the libtls API, whether that API is implemented via LibreSSL or via OpenSSL with the addition of LibreTLS. You can use it in your own programs, but since libtls is already relatively high-level, it's probably not very useful.
void stls_drop ()
If the process is running as root, then this function drops its privileges (else it does nothing). The gid to drop to is read from the TLS_GID environment variable; the uid to drop to is read from the TLS_UID environment variable. If those variables are not given, then the uid, or gid, or both, are not changed. If they contain something else than numerical uid/gids, the process exits 111 with an error message.
int stls_send_environment (struct tls *ctx, int fd)
Writes a series of null-terminated strings of the form key=value to file descriptor fd; the series is terminated with an additional null character. The strings represent information about the TLS connection represented by context ctx; it is only valid to call this function after the handshake has completed. The exact keys used will change over time, but at least SSL_PROTOCOL=value and SSL_CIPHER=value are transmitted. The function returns 1 if it succeeds and 0 if it fails.
struct tls *stls_client_init_and_handshake (int const *fds, uint32_t preoptions, char const *servername)
This function initializes a TLS context for a client-side connection, then performs a TLS handshake. It then returns a non-null pointer to a struct tls context for the application to pass to the stls_run function when it wants to run the engine. If the context cannot be initialized or the handshake cannot be performed, the process exits (96 for configuration issues, 97 for context and handshake issues) with an appropriate error message.
If the CADIR environment variable is set, then it must contain the path of a directory containing the hashed names of the public certificates identifying the trust anchors. Else, if the CAFILE environment variable is set, then it must contain the path to a PEM file containing all the certificates for the trust anchors. Else, the process exits 100 with an error message.
The arguments are as follows:
struct tls *stls_server_init_and_handshake (int const *fds, uint32_t preoptions)
Same as the previous function, but on the server side. No servername argument is required. The CERTFILE and KEYFILE environment variables are mandatory, they point to the server's certificate and private key. It is only necessary to set CADIR or CAFILE when bit 0 of preoptions is set, in which case client authentication will be requested, and a list of trust anchors (read from either the directory in CADIR or the PEM file in CAFILE) will be used to verify the client certificate.
void stls_run (struct tls *ctx, int *fds, unsigned int verbosity, uint32_t options, tain_t const *tto)
This function runs a full-duplex TLS/SSL engine, reading/writing clear text from/to two file descriptors, and writing/reading ciphertext to/from two other file descriptors, until the connection is closed both ways (either with a SSL close, or with EOF). It does not return.
stls_run will make the process die with an appropriate error message and exit code if it encounters an unrecoverable error. If there were no problems and the SSL/TLS connection closed cleanly, the process exits 0.


Home
WishList
Men
Women
Kids
Search
Login
Categories
Casual Shoes
Formal Shoes
Sports Shoes
Ballerina Flats
Floaters
Heels
Juti (Ethnic)
Sneakers
Brands
Redtape
Nike
WoodLand
Dressberry
Sparx
Jimmy Choo
House Of Pataudi
Reebok


Click on one of the charts to go to its demo page.
To see the code, view the source, open your devtools, or go to our public Github repository.
Some implementations are available in D3.js and R, as well as in Blockbuilder, D3.js' leading online editor.
A public resource of data viz code and designs


Caring Generations
Registration
Complete your registration by giving us your name and choosing a password for your account. You will log in with your email address and the password you choose!!
Full Name
This is the name that will be shown to other Living Connection users.
Please enter the name
Name is too short
Name is too long
Email ID
New Password
Password must contain 6-14 characters.
Please enter password
Password is too short
Password is too long
Re-Type New Password
Please enter password
Your passwords did not match
Continue


Project Activity
-
Jane smith
@johnsmith
12:45pmPainter Lucian Freud was also born on December 8th a few years later - in 1922. Here's his "Girl with Roses"
-
Jane smith
near florida
8:45pm -
Jane smith
@cobygo
12:45pmPainter Lucian Freud was also born on December 8th a few years later - in 1922. Here's his "Girl with Roses"http://goo.gl/LWmNLq ...
-
You started a new project!
12/23/14Nulla porttitor accumsan tincidunt. Praesent sapien massa, convallis a pellentesque nec,
Nulla porttitor accumsan tincidunt. Praesent sapien massa, convallis a pellentesque nec, egestas non nisi. Donec sollicitudin molestie malesuada. Curabitur non nulla sit amet nisl tempus convallis quis ac lectus. Curabitur arcu erat, accumsan id imperdiet et, porttitor at sem. Vivamus suscipit tortor eget felis porttitor volutpat. Praesent sapien massa, convallis a pellentesque nec, egestas non nisi. Pellentesque in ipsum id orci porta dapibus. Vivamus magna justo, lacinia eget consectetur sed, convallis at tellus. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Nulla porttitor accumsan tincidunt. Praesent sapien massa, convallis a pellentesque nec,


| DOSE: |
|
insufflated |
Cocaine |
(powder / crystals) |
I just wanted to say a little bit about my very first experience with cocaine. Now, before I tried drugs, cocaine never appealed to me, even after I tried other stuff, coke still never appealed to me. I said to myself: 'That is one drug I will never touch.'. Did I honor my promise? No. Basically, one of my best friends who is a coke addict said he really wanted to quit and that he might do it once more and asked if I wanted to try it. I figured, 'You only live once, I may never get the chance again.' I talked myself into it and prepared.
A few minutes after doing it, I was insane! But it was strange, because it was not like anybody said it would be like. In fact, my friend said he never seen anybody react like that before. I was a bit confused myself until I thought about it more today.  It is the opposite of pot because that only slows me down and makes me mellow, but coke, no, it makes me full of electrical energy! The mental effects were not so bad at first but I think it was the body effects that made me so scared. I always heard bad things about coke and was nervous to do it, but too late. I think it was just things like breathing, swallowing, etc, they were a bit hard to do because I was so sped up on energy, it was so weird! Keep in mind that I have ADHD and can be pretty damn hyper anyways so this made me a jolt of electricity!
The thing is, the body effects made me paranoid wondering if I would harm myself physically or become an addict. Then it was like a million thoughts at once, I was trying to analyze each one but it was an information overload! Unlike pot, coke doesn't make things appeal to me and be as artistic. I was trying to view things differently and it just ended up in a huge mess. I started forgetting everything and just racing from thought to thought. Each thought that came to my mind, I said it aloud and then repeated it nervously so I would not overwork myself. The hyperactivity created a paranoia effect that, even though I knew everything would be okay, I still had emotions of fear, but sometimes I feel as if I was going overboard on purpose, but maybe not!
I needed to calm myself down, I was getting way to worked up, I didn't wanna hurt myself! I tried thinking of things I enjoyed, such as girls, music, art, etc, but it just made me spit out nouns and such that sounded like utter nonsense. It was really freaking my friend out at this point! I was just in a daze, I was insane! Was this supposed to happen? Am I normal? I asked myself those questions.
Trying to focus on things like video games, I could only do so for a minute before I was distracted. It felt like a million thoughts charged at once, all me trying to speak at the same time. All I remember is going into the garage with Nirvana playing in the background and me going completely nuts. Eventually, I was calming down and then for the rest of the night, I became very calm, to the point where even if I wanted to speak, I didn't, I just looked around in a daze and thought, trying to take it all in.
All I say is, I don't think I had the normal reaction, I doubt I will ever do it again, and I have heard a few people with minor similar reactions, but man, coke is not the thing for me probably... >_>
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Entering a width and height in these input boxes will set that on the model. Since both the area and perimeter are computed attributes that depend on the width and height, the change:area and change:perimter listeners will be fired and the display will update.


The @angular/cdk/drag-drop
module provides you with a way to easily and declaratively create
drag-and-drop interfaces, with support for free dragging, sorting within a list, transferring items
between lists, animations, touch devices, custom drag handles, previews, and placeholders,
in addition to horizontal lists and locking along an axis.
Start by importing DragDropModule
into the NgModule
where you want to use drag-and-drop
features. You can now add the cdkDrag
directive to elements to make them draggable. When
outside of a cdkDropList
element, draggable elements can be freely moved around the page.
You can add cdkDropList
elements to constrain where elements may be dropped.
Adding cdkDropList
around a set of cdkDrag
elements groups the draggables into a
reorderable collection. Items will automatically rearrange as an element moves. Note
that this will not update your data model; you can listen to the cdkDropListDropped
event to
update the data model once the user finishes dragging.
The cdkDropList
directive supports transferring dragged items between connected drop zones.
You can connect one or more cdkDropList
instances together by setting the cdkDropListConnectedTo
property or by wrapping the elements in an element with the cdkDropListGroup
attribute.
Note that cdkDropListConnectedTo
works both with a direct reference to another cdkDropList
, or
by referencing the id
of another drop container:

If you have an unknown number of connected drop lists, you can use the cdkDropListGroup
directive
to set up the connection automatically. Note that any new cdkDropList
that is added under a group
will be connected to all other lists automatically.

You can associate some arbitrary data with both cdkDrag
and cdkDropList
by setting cdkDragData
or cdkDropListData
, respectively. Events fired from both directives include this data, allowing
you to easily identify the origin of the drag or drop interaction.

The cdkDrag
and cdkDropList
directive include only those styles strictly necessary for
functionality. The application can then customize the elements by styling CSS classes added
by the directives:
| Selector | Description |
|---|---|
.cdk-drop-list |
Corresponds to the cdkDropList container. |
.cdk-drag |
Corresponds to a cdkDrag instance. |
.cdk-drag-disabled |
Class that is added to a disabled cdkDrag . |
.cdk-drag-handle |
Class that is added to the host element of the cdkDragHandle directive. |
.cdk-drag-preview |
This is the element that will be rendered next to the user's cursor as they're dragging an item in a sortable list. By default the element looks exactly like the element that is being dragged. |
.cdk-drag-placeholder |
This is element that will be shown instead of the real element as it's being dragged inside a cdkDropList . By default this will look exactly like the element that is being sorted. |
.cdk-drop-list-dragging |
A class that is added to cdkDropList while the user is dragging an item. |
.cdk-drop-list-disabled |
A class that is added to cdkDropList when it is disabled. |
.cdk-drop-list-receiving |
A class that is added to cdkDropList when it can receive an item that is being dragged inside a connected drop list. |
The drag-and-drop module supports animations both while sorting an element inside a list, as well as
animating it from the position that the user dropped it to its final place in the list. To set up
your animations, you have to define a transition
that targets the transform
property. The
following classes can be used for animations:
.cdk-drag
- If you add a transition
to this class, it'll animate as the user is sorting
through a list..cdk-drag-animating
- This class is added to a cdkDrag
when the user has stopped dragging.
If you add a transition
to it, the CDK will animate the element from its drop position to
the final position inside the cdkDropList
container.Example animations:
/* Animate items as they're being sorted. */
.cdk-drop-list-dragging .cdk-drag {
transition: transform 250ms cubic-bezier(0, 0, 0.2, 1);
}
/* Animate an item that has been dropped. */
.cdk-drag-animating {
transition: transform 300ms cubic-bezier(0, 0, 0.2, 1);
}
By default, the user can drag the entire cdkDrag
element to move it around. If you want to
restrict the user to only be able to do so using a handle element, you can do it by adding the
cdkDragHandle
directive to an element inside of cdkDrag
. Note that you can have as many
cdkDragHandle
elements as you want:
When a cdkDrag
element is picked up, it will create a preview element visible while dragging.
By default, this will be a clone of the original element positioned next to the user's cursor.
This preview can be customized, though, by providing a custom template via *cdkDragPreview
.
Using the default configuration the custom preview won't match the size of the original dragged
element, because the CDK doesn't make assumptions about the element's content. If you want the
size to be matched, you can pass true
to the matchSize
input.
Note that the cloned element will remove its id
attribute in order to avoid having multiple
elements with the same id
on the page. This will cause any CSS that targets that id
not
to be applied.
By default, the preview of a cdkDrag
will be inserted into the
of the page in order to
avoid issues with z-index
and overflow: hidden
. This may not be desireable in some cases,
because the preview won't retain its inherited styles. You can control where the preview is inserted
using the cdkDragPreviewContainer
input on cdkDrag
. The possible values are:
| Value | Description | Advantages | Disadvantages |
|---|---|---|---|
global |
Default value. Preview is inserted into the  or the closest shadow root. |
Preview won't be affected by z-index or overflow: hidden . It also won't affect :nth-child selectors and flex layouts. |
Doesn't retain inherited styles. |
parent |
Preview is inserted inside the parent of the item that is being dragged. | Preview inherits the same styles as the dragged item. | Preview may be clipped by overflow: hidden or be placed under other elements due to z-index . Furthermore, it can affect :nth-child selectors and some flex layouts. |
ElementRef or HTMLElement |
Preview will be inserted into the specified element. | Preview inherits styles from the specified container element. | Preview may be clipped by overflow: hidden or be placed under other elements due to z-index . Furthermore, it can affect :nth-child selectors and some flex layouts. |
While a cdkDrag
element is being dragged, the CDK will create a placeholder element that will
show where it will be placed when it's dropped. By default the placeholder is a clone of the element
that is being dragged, however you can replace it with a custom one using the *cdkDragPlaceholder
directive:
The cdkDropList
directive assumes that lists are vertical by default. This can be
changed by setting the orientation
property to `"horizontal".
If you want to stop the user from being able to drag a cdkDrag
element outside of another element,
you can pass a CSS selector to the cdkDragBoundary
attribute. The attribute works by accepting a
selector and looking up the DOM until it finds an element that matches it. If a match is found,
it'll be used as the boundary outside of which the element can't be dragged. cdkDragBoundary
can
also be used when cdkDrag
is placed inside a cdkDropList
.
By default, cdkDrag
allows free movement in all directions. To restrict dragging to a
specific axis, you can set cdkDragLockAxis
on cdkDrag
or cdkDropListLockAxis
on cdkDropList
to either "x"
or "y"
.
If there's an element that you want to make draggable, but you don't have direct access to it, you
can use the cdkDragRootElement
attribute. The attribute works by accepting a selector and looking
up the DOM until it finds an element that matches the selector. If an element is found, it'll become
the element that is moved as the user is dragging. This is useful for cases like making a dialog
draggable.
By default, all cdkDrag
items from one container can be moved into another connected container.
If you want more fine-grained control over which items can be dropped, you can use the
cdkDropListEnterPredicate
which will be called whenever an item is about to enter a
new container. Depending on whether the predicate returns true
or false
, the item may or may not
be allowed into the new container.
If you want to disable dragging for a particular drag item, you can do so by setting the
cdkDragDisabled
input on a cdkDrag
item. Furthermore, you can disable an entire list
using the cdkDropListDisabled
input on a cdkDropList
or a particular handle via
cdkDragHandleDisabled
on cdkDragHandle
.
There are cases where draggable items can be dragged out of one list into another, however
the user shouldn't be able to sort them within the source list. For these cases you can set the
cdkDropListSortingDisabled
input which will prevent the items in a cdkDropList
from sorting,
in addition to preserving the dragged item's initial position in the source list, if the user
decides to return the item.
By default as soon as the user puts their pointer down on a cdkDrag
, the dragging sequence will
be started. This might not be desirable in cases like fullscreen draggable elements on touch
devices where the user might accidentally trigger a drag as they're scrolling the page. For
cases like these you can delay the dragging sequence using the cdkDragStartDelay
input which
will wait for the user to hold down their pointer for the specified number of milliseconds before
moving the element.
By default, standalone cdkDrag
elements move from their normal DOM position only when manually
moved by a user. The element's position can be explicitly set, however, via the
cdkDragFreeDragPosition
input. Applications commonly use this, for example, to restore a
draggable's position after a user has navigated away and then returned.
cdkDrag
items can be sorted into any position inside of a cdkDropList
by default. You can change
this behavior by setting a cdkDropListSortPredicate
. The predicate function will be called
whenever an item is about to be moved into a new index. If the predicate returns true
, the
item will be moved into the new index, otherwise it will keep its current position.


Your proposal is still open for public discussion, but the ZF team has requested changes. Please make the necessary edits and mark the changes as resolved.
{% if args.admin_note %}A note from the Zcash Foundation:
“{{ args.admin_note }}”
{% endif %}Please note that repeated submissions without significant changes or with content that doesn't match the platform guidelines may result in a removal of your submission privileges.


What would be printed if the following Python script were to be run?
a = Dec b = 12 def goo(x, y): a = x / 2 b = y + 1 goo(a, b) print a
The variables a and b have global scope in this example.
Changing the value of a global variable a will persist when the function call is completed.
The value Math.floor(Dec / 2) would be printed -- i.e., the change to a inside the function will persist.


Contact Us
Home
About
Koalas FAQ
Save Koalas
Gallery
Adopt
Contact Us
First Name:
Last Name:
Email:
How much do you like Koalas:
alot
tons
favorite animal
If you had a koala bear what would you name it:
Choose...
Grizzly
Teddy
Smokey
Rupert
In 500 words tell us your favorite thing about koala bears:


Cuba 0-4 United States: Morris, Sargent send Berhalter's men into semis
by Sports DeskThe United States moved into the CONCACAF Nations League semi-finals after a 4-0 win over Cuba on Tuesday.
USA were ahead inside a minute in the Cayman Islands through Josh Sargent and never looked back, Jordan Morris adding a first-half brace.
Morris continued his fine run of form for USA before Sargent sealed his side's victory during a quieter second half.
The win ensured Gregg Berhalter's side of top spot in Group A of League A and a spot in the semi-finals on goal difference.
USA opened the scoring inside 40 seconds through Sargent.
Paul Arriola did the hard work down the right before crossing for Sargent, who scored from close range as he put Cuba goalkeeper Sandy Sanchez under pressure.
USA dominated the first half and Weston McKennie had a goal-bound effort cleared off the line by Erick Rizo in the eighth minute.
However, the visitors doubled their lead through Morris, who made no mistake in a one-on-one with Sanchez after a great flick-on header by McKennie.
Morris struck again six minutes before half-time, although the forward seemed apologetic to Aaron Long.
Long's ball from the left side of the area went over Sanchez and Morris tapped in on the goal-line to make it 3-0.
After a quieter start to the second half, USA added to their lead through Sargent's second.
Tyler Boyd flicked Reggie Cannon's back-post cross into the path of Sargent, who converted from inside the area in the 66th minute.
USA cruised late on, easing to an important victory and seeing Cuba finish without a point in the group.
What does it mean? USA put Canada hiccup aside
A 2-0 loss to Canada in Toronto in October had Berhalter under enormous pressure at the helm, but USA have responded. Wins over Canada (4-1) and Cuba this international break – and a spot in the semi-finals – have surely been enough to ease the pressure on Berhalter.
USA developing fast-start habit
For the second game in a row, USA scored inside two minutes. They also netted three times in the opening nine minutes against Cuba in October and Berhalter will be hoping they can continue their fast starts going forward.
Morris caps off stellar 2019
Morris' brace meant he has scored in four of his past five appearances for USA. The Seattle Sounders forward has netted five of his 10 international goals since September in a fine run of form.
What's next?
Both countries have played their final games of the year, but USA can look forward to the Nations League semi-finals in June 2020.


The correlation plugin, which allows you to plot a grid of scatter plots representing the correlations between variables in a data set.


Curt Ziegler
I am a web designer specializing in wordpress theme development
with 10 years of experience designing sites for clients around the globe.
-
Freelance
Visit Cudazi.com for freelance availablilty
-
Themes
HTML and WordPress Theme Portfolio at ThemeForest
-
Twitter
Follow @cudazi on Twitter for news, updates and freebies
- TutorialsDesign Tutorials on Envato's WebDesignTuts+
-
Linkedin
Join into my professional network
-
Contact
Send me a message


Option #1
Home
About
Services
Kitchen Remodel
Bathroom Remodels
Room Additions
Wall Removals
Pergolas
Patios
Accessories
Shop
Portfolio
Contact Us
Option #2
Home
About
Services
Shop
Portfolio
Contact Us
Kitchen Remodel
Bathroom Remodels
Room Additions
Wall Removals
Pergolas
Patios
Accessories
Option #3
Home
Shop
Services
About
Portfolio
Contact Us
Kitchen Remodel
Bathroom Remodels
Room Additions
Wall Removals
Pergolas
Patios
Accessories
Option #4
Home
About
Services
Shop
Portfolio
Contact Us
Kitchen Remodel
Bathroom Remodels
Room Additions
Wall Removals
Pergolas
Patios
Accessories