Commit 21a3e0c3 authored by djeang's avatar djeang
Browse files

Merge branch 'master' of https://github.com/jerkar/jerkar.git

Conflicts:
	org.jerkar.core/build/def/org/jerkar/AbstractBuild.java
parents e9e75b58 58f6807a
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>jerkar</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
</buildSpec>
<natures>
</natures>
</projectDescription>
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>jerkar</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
</buildSpec>
<natures>
</natures>
</projectDescription>
language: java
This diff is collapsed.
[![Build Status](https://travis-ci.org/jerkar/jerkar.svg?branch=master)](https://travis-ci.org/jerkar/jerkar)
[![Maven Central](https://maven-badges.herokuapp.com/maven-central/org.jerkar/core/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.jerkar/core) <br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<img src="http://jerkar.github.io/img/logo/PNG-01.png" width='350' height='420' align='middle'/>
<strong>Jerkar</strong> is a complete **build system** ala _Ant_, _Maven_, _Gradle_ or _Buildr_ but using **pure Java** to describe builds : no XML, no foreign language.
Breaking a common belief, it makes proof that Java is perfectly suitable in this domain.
# How to use Jerkar
Jerkar is expected to have a very fast learning curve for Java developers. You can visit the following page in this order :
* http://jerkar.github.io/tell-me-more.html : introduction to Jerkar. Answer to the question : *What Jerkar is exactly ?*
* http://jerkar.github.io/tour.html : to give a concrete idea of how Jerkar is working
* http://jerkar.github.io/tour.html : to give a concrete idea on how Jerkar is working
* http://jerkar.github.io/documentation/latest/getting_started.html : to get hand-on experience
* http://jerkar.github.io/documentation/latest/reference.html : to know the details about Jerkar behavior
......@@ -31,9 +35,9 @@ Jerkar builds itself. To get Jerkar full distrib built from the Java sources onl
* Choose `org.jerkar.tool.Main` as Main class
* Run it : It will launch a multi-project build. You will find result for the full distrib in *org.jerkar.distrib-all/build/output* directory
## Build Jerkar from Intellij
## Build Jerkar from IntelliJ
Youu can achieve the same using **Intellij** as Intellij module definitions (.iml) are stored in git. `org.jerkar.distrib-all` contains the project definition (.idea folder).
You can achieve the same using **Intellij** as Intellij module definitions (.iml) are stored in git. `org.jerkar.distrib-all` contains the project definition (.idea folder).
# Status
......
<project name="Jerkar" default="test" basedir=".">
<description>
This ANT file is here to let Travis build Jerkar (as Jerkar is not supported yet by Travis).
</description>
<property name="bin" location="jerkar-bin" />
<fileset id="libs" dir="org.jerkar.core/build/libs/provided">
<include name='**/*.jar' />
</fileset>
<target name="init">
<mkdir dir="${bin}" />
</target>
<target name="create-bin" depends="init">
<delete dir="${bin}" />
<mkdir dir="${bin}" />
<javac destdir="${bin}">
<src path="org.jerkar.core/src/main/java" />
<classpath>
<fileset refid="libs" />
</classpath>
</javac>
<copy todir="${bin}">
<fileset dir="org.jerkar.core/src/main/java" excludes="**/*.java" />
</copy>
</target>
<target name="test" depends="create-bin">
<java classname="org.jerkar.tool.Main" dir="org.jerkar.distrib-all" fork="true" failonerror="true">
<arg line="-testSamples=false -verbose=false" />
<classpath>
<pathelement location="${bin}" />
<fileset refid="libs" />
</classpath>
</java>
</target>
</project>
\ No newline at end of file
......@@ -4,7 +4,7 @@
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="src" output="build/output/testClasses" path="src/test/java"/>
<classpathentry kind="lib" path="build/libs/provided/ivy-2.4.0.jar" sourcepath="build/libs-sources/apache-ivy-2.4.0-sources.jar"/>
<classpathentry kind="lib" path="build/libs/provided/ivy-2.4.0.jar"/>
<classpathentry kind="lib" path="build/libs/provided/bouncycastle-pgp-152.jar"/>
<classpathentry kind="lib" path="build/libs/provided/junit-4.11.jar" sourcepath="build/libs-sources/junit-4.11-sources.jar"/>
<classpathentry kind="lib" path="build/libs/provided/hamcrest-core-1.3.jar" sourcepath="build/libs-sources/hamcrest-core-1.3-sources.jar"/>
......
*.class
# Package Files #
*.war
*.ear
/bin
/.sonar
*.class
# Package Files #
*.war
*.ear
/bin
/.sonar
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>org.jerkar.core</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>org.jerkar.core</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>
eclipse.preferences.version=1
encoding//src/main/java/META-INF/MANIFEST.MF=UTF-8
encoding/<project>=UTF-8
eclipse.preferences.version=1
encoding//src/main/java/META-INF/MANIFEST.MF=UTF-8
encoding/<project>=UTF-8
......@@ -24,7 +24,7 @@ public abstract class AbstractBuild extends JkJavaBuild {
@Override
public JkVersion version() {
return JkVersion.ofName("0.3.3-SNAPSHOT");
return JkVersion.ofName("0.4.0-SNAPSHOT");
}
@Override
......
......@@ -35,7 +35,10 @@ public class CoreBuild extends AbstractBuild {
@Override
protected JkManifest jarManifest() {
final String version = version().name() + " - built at " + buildTimestamp();
String version = version().name();
if (version().isSnapshot()) {
version = version + " - built at " + buildTimestamp();
}
return super.jarManifest().addMainClass("org.jerkar.tool.Main")
.addMainAttribute(Name.IMPLEMENTATION_VERSION, version);
}
......
<?xml version="1.0" encoding="UTF-8"?>
<module type="JAVA_MODULE" version="4">
<component name="NewModuleRootManager" inherit-compiler-output="true">
<exclude-output />
<content url="file://$MODULE_DIR$">
<sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" />
<sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" />
<sourceFolder url="file://$MODULE_DIR$/build/def" isTestSource="true" />
<excludeFolder url="file://$MODULE_DIR$/bin" />
</content>
<orderEntry type="jdk" jdkName="1.6" jdkType="JavaSDK" />
<orderEntry type="sourceFolder" forTests="false" />
<orderEntry type="module-library" scope="TEST">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/test/jdepend-2.9.1.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/hamcrest-core-1.3.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" exported="" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/junit-4.11.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/ivy-2.4.0.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/bouncycastle-pgp-152.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
</component>
</module>
<?xml version="1.0" encoding="UTF-8"?>
<module type="JAVA_MODULE" version="4">
<component name="NewModuleRootManager" inherit-compiler-output="true">
<exclude-output />
<content url="file://$MODULE_DIR$">
<sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" />
<sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" />
<sourceFolder url="file://$MODULE_DIR$/build/def" isTestSource="true" />
<excludeFolder url="file://$MODULE_DIR$/bin" />
</content>
<orderEntry type="jdk" jdkName="1.6" jdkType="JavaSDK" />
<orderEntry type="sourceFolder" forTests="false" />
<orderEntry type="module-library" scope="TEST">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/test/jdepend-2.9.1.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/hamcrest-core-1.3.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" exported="" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/junit-4.11.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/ivy-2.4.0.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
<orderEntry type="module-library" scope="PROVIDED">
<library>
<CLASSES>
<root url="jar://$MODULE_DIR$/build/libs/provided/bouncycastle-pgp-152.jar!/" />
</CLASSES>
<JAVADOC />
<SOURCES />
</library>
</orderEntry>
</component>
</module>
Contains some libraries that are likely to be in Eclipse environment.
This directory is only intended for users who want Jerkar build extract build info from Eclipse metadata (.classpath file).
Contains some libraries that are likely to be in Eclipse environment.
This directory is only intended for users who want Jerkar build extract build info from Eclipse metadata (.classpath file).
......@@ -150,8 +150,8 @@ fi
JERKAR_CMD_LINE_ARGS="$@"
export JERKAR_CMD_LINE_ARGS
if [ -d "./build/libs/build" ]; then
LOCAL_BUILD_DIR="./build/libs/build/*:"
if [ -d "./build/boot" ]; then
LOCAL_BUILD_DIR="./build/boot/*:"
else
LOCAL_BUILD_DIR=""
fi
......
......@@ -8,7 +8,7 @@ if "%JAVA_HOME%" == "" set "JAVA_CMD=java"
if not "%JAVA_HOME%" == "" set "JAVA_CMD=%JAVA_HOME%\bin\java"
SET LOCAL_BUILD_DIR=
if exist %cd%\build\libs\build set "LOCAL_BUILD_DIR=build\libs\build\*;"
if exist %cd%\build\boot set "LOCAL_BUILD_DIR=build\boot\*;"
set "COMMAND="%JAVA_CMD%" %JERKAR_OPTS% -cp "%LOCAL_BUILD_DIR%%JERKAR_HOME%libs\ext\*;%JERKAR_HOME%org.jerkar.core-all.jar" org.jerkar.tool.Main %*"
if not "%JERKAR_ECHO_CMD%" == "" (
@echo on
......
## All properties defined here will be injected automatically as option in your Jerkar builds.
## You can override some default as verbose=true or repo.publish.url=file:///c:/sharedMavenRepo or define your owns.
## Note that you can also inject option by editing [user home]/.jerkar/options.properties
## or by mention in command line as -verbose=true
## All properties defined here will be injected automatically as option in your Jerkar builds.
## You can override some default as verbose=true or repo.publish.url=file:///c:/sharedMavenRepo or define your owns.
## Note that you can also inject option by editing [user home]/.jerkar/options.properties
## or by mention in command line as -verbose=true
## All properties defined here will be set as system properties.
## These won't be set in the java command startup but right after the JVM has started.
## Note that you can also inject option by editing [user home]/.jerkar/system.properties
## or by mention in command line as -Dhttps.proxyPort=8080
## All properties defined here will be set as system properties.
## These won't be set in the java command startup but right after the JVM has started.
## Note that you can also inject option by editing [user home]/.jerkar/system.properties
## or by mention in command line as -Dhttps.proxyPort=8080
......@@ -14,7 +14,7 @@ These scripts do the following :
1. __Find the java executable path__ : If a `JAVA_HOME` environment variable is defined then it takes its value as `java` path. Otherwise it takes the `java` executable defined in the _PATH_ of your OS.
2. __Get java execution option__ : If an environment variable `JERKAR_OPTS` exists then its value is passed to the `java` command line parameters, otherwise default `-Xmx512m -XX:MaxPermSize=512m` is passed.
3. __Set Jerkar classpath__ in the following order :
* all jar and zip files found under _[WORKING DIR]/build/libs/build_
* all jar and zip files found under _[WORKING DIR]/build/boot_
* all jar and zip files found under _[JERKAR HOME]/libs/ext_
* the _[JERKAR_HOME]/org.jerkar.core.jar_ file
4. __Run the `org.jerkar.tool.Main` class__ passing the command line argument as is. So if you have typed `jerkar myArg1 myArg2` the `myArg1 myArg2` will be passed as Java command-line arguments.
......
## Build Configuration
----------------------
Jerkar build are configurable. Build definition classes can retrieve values defined at runtime by reading :
* an environment variable
* a system property
* a Jerkar option
### Environment variables
There is nothing specific to Jerkar. Just set the environment variable as you usually do on your OS and get the value from build using the standard Java `System#getenv` method.
### System properties
Naturally, your build definitions can read system properties by using the standard method `System#getProperty`.
Jerkar proposes 3 ways to inject system properties :
* By editing ___[Jerkar Home]/system.properties___ file.
Note that if you are running Jerkar in embedded mode, the ___[Jerkar Home]/system.properties___ file will not be taken in account but ___[project dir]/build/def/build/system.properties___.
* By editing ___[Jerkar User Home]/system.properties___ file.
* By mentioning the property/value in Jerkar __command line__ as `Jerkar doDefault -DmyProperty=myValue`.
The __command line__ takes precedence on ___[Jerkar User Home]/system.properties___ that in turn, takes precedence on ___[Jerkar Home]/system.properties___.
In every case, defined system properties are injected after the creation of the java process (via `System#setProperty` method).
### Jerkar options
Jerkar options are similar to system properties as it stands for a set of __key/value__. You can read it by using a dedicated API or let it be injected in Java field as explained below.
#### Injecting options
Jerkar proposes 3 ways to inject options :
* By editing ___[Jerkar Home]/options.properties___ file.
Note that if you are running Jerkar in embedded mode, the ___[Jerkar Home]/options.properties___ file will not be taken in account but ___[project dir]/build/def/build/options.properties___.
* By editing ___[Jerkar User Home]/options.properties___ file.
* By mentioning the property/value in the Jerkar command line as `Jerkar doDefault -myOption=myValue`.
As for system properties, The __command line__ takes precedence on ___[Jerkar User Home]/options.properties___ that takes in turn, precedence on ___[Jerkar Home]/options.properties___.
Note for boolean, when no value is specified, `true` will be used as default.
#### Retrieve Jerkar options
You can retrieve string values using the `JkOptions` API providing convenient static methods as `JkOptions#get`, `JkOptions#getAll` or `JkOptions#getAllStartingWith(String prefix)`.
You can also retrieve options just by __declaring fields in build definition class__.
All non private instance fields of the build definition class, are likely to be injected as an option.
For example, if you declare a field like `protected int size = 3;` then you can override the default value by injecting the option value with any of the 3 ways described above.
Any fields __except static fields or private fields__ can be used to inject options.
If you want __inject option in a private field__, you must annotate it with `@JkDoc` as `@JkDoc private boolean myField;`
Note that the injected string value will be automatically converted to the target type.
Handled types are __String__, __all primitive types (and their wrappers)__, __enum__, __File__ and __composite object__.
To get a precise idea on how types are converted see [this code](https://github.com/jerkar/jerkar/blob/master/org.jerkar.core/src/main/java/org/jerkar/tool/OptionInjector.java).
#### Composite options
Composite options are a way to structure your options. Say that you want to configure some server access with url, userName and passwsord,
you can gather all these information in a object as
```Java
class Server {
private String url;
private String userName;
private String password;
// ...
}
```
declare a Server field in your build :
```Java
class MyBuild extends JkBuild {
Server deployServer;
...
}
```
Then you can inject the server object using following options :
```
deployServer.url=http:/myServer:8090/to
deployServer.username=myUsername
deployServer.password=myPassword
```
#### Standard options
Jerkar predefines some standard options that you can set for any build :
* buildClass : This forces the build class to use. If this option is not null then Jerkar will used the specified class as the build class.
Note that this can be a simple class as `MyBuildClass` is enough for running `org.my.project.MyBuildClass`.
* verbose : when `true` Jerkar will be more verbose at logging at the price of being slower and bloating logs. Default value is `false`.
* silent : when `true`nothing will be logged. Default is `false`
#### How to document options ?
If you want your option been displayed when invoking `jerkar help` you need to annotate it with `@JkDoc`.
For example :
```
@JkDoc("Make the test run in a forked process")
private boolean forkTests = false;
```
## Build Configuration
----------------------
Jerkar build are configurable. Build definition classes can retrieve values defined at runtime by reading :
* an environment variable
* a system property
* a Jerkar option
### Environment variables
There is nothing specific to Jerkar. Just set the environment variable as you usually do on your OS and get the value from build using the standard Java `System#getenv` method.
### System properties
Naturally, your build definitions can read system properties by using the standard method `System#getProperty`.
Jerkar proposes 3 ways to inject system properties :
* By editing ___[Jerkar Home]/system.properties___ file.
Note that if you are running Jerkar in embedded mode, the ___[Jerkar Home]/system.properties___ file will not be taken in account but ___[project dir]/build/def/build/system.properties___.
* By editing ___[Jerkar User Home]/system.properties___ file.
* By mentioning the property/value in Jerkar __command line__ as `Jerkar doDefault -DmyProperty=myValue`.
The __command line__ takes precedence on ___[Jerkar User Home]/system.properties___ that in turn, takes precedence on ___[Jerkar Home]/system.properties___.
In every case, defined system properties are injected after the creation of the java process (via `System#setProperty` method).
### Jerkar options
Jerkar options are similar to system properties as it stands for a set of __key/value__. You can read it by using a dedicated API or let it be injected in Java field as explained below.
#### Injecting options
Jerkar proposes 3 ways to inject options :
* By editing ___[Jerkar Home]/options.properties___ file.
Note that if you are running Jerkar in embedded mode, the ___[Jerkar Home]/options.properties___ file will not be taken in account but ___[project dir]/build/def/build/options.properties___.
* By editing ___[Jerkar User Home]/options.properties___ file.
* By mentioning the property/value in the Jerkar command line as `Jerkar doDefault -myOption=myValue`.
As for system properties, The __command line__ takes precedence on ___[Jerkar User Home]/options.properties___ that takes in turn, precedence on ___[Jerkar Home]/options.properties___.
Note for boolean, when no value is specified, `true` will be used as default.
#### Retrieve Jerkar options
You can retrieve string values using the `JkOptions` API providing convenient static methods as `JkOptions#get`, `JkOptions#getAll` or `JkOptions#getAllStartingWith(String prefix)`.
You can also retrieve options just by __declaring fields in build definition class__.
All non private instance fields of the build definition class, are likely to be injected as an option.
For example, if you declare a field like `protected int size = 3;` then you can override the default value by injecting the option value with any of the 3 ways described above.
Any fields __except static fields or private fields__ can be used to inject options.
If you want __inject option in a private field__, you must annotate it with `@JkDoc` as `@JkDoc private boolean myField;`
Note that the injected string value will be automatically converted to the target type.
Handled types are __String__, __all primitive types (and their wrappers)__, __enum__, __File__ and __composite object__.
To get a precise idea on how types are converted see [this code](https://github.com/jerkar/jerkar/blob/master/org.jerkar.core/src/main/java/org/jerkar/tool/OptionInjector.java).
#### Composite options
Composite options are a way to structure your options. Say that you want to configure some server access with url, userName and passwsord,
you can gather all these information in a object as
```Java
class Server {
private String url;
private String userName;
private String password;
// ...
}
```
declare a Server field in your build :
```Java
class MyBuild extends JkBuild {
Server deployServer;
...
}
```
Then you can inject the server object using following options :
```
deployServer.url=http:/myServer:8090/to
deployServer.username=myUsername
deployServer.password=myPassword
```
#### Standard options
Jerkar predefines some standard options that you can set for any build :
* buildClass : This forces the build class to use. If this option is not null then Jerkar will used the specified class as the build class.
Note that this can be a simple class as `MyBuildClass` is enough for running `org.my.project.MyBuildClass`.
* verbose : when `true` Jerkar will be more verbose at logging at the price of being slower and bloating logs. Default value is `false`.
* silent : when `true`nothing will be logged. Default is `false`
#### How to document options ?
If you want your option been displayed when invoking `jerkar help` you need to annotate it with `@JkDoc`.
For example :
```
@JkDoc("Make the test run in a forked process")
private boolean forkTests = false;
```
Supports Markdown
0% or .