Roll your own Continuous Integration System (C.I.S.)
Content:
Configuracion de MySQL
This is a very short post, and the reason is that this is more like a remainder that the default installation cannot be used for production environments without changing default database manager (Derby) for any other. My choice is MySQL + filesystem.
Artifactory guys explained it perfectly in their wiki, just take a look, it is easy and I have just tested it, no problem.
http://wiki.jfrog.org/confluence/display/RTF/Running+Artifactory+on+MySQL
It is supposed that you have just installed it from the WAR, stop Tomcat, erase from your artifactory_home everything but "etc", it is the only folder you will need for the derby->anyother change.
Now follow the steps, if you did them alright, you will find the erased folders re-created again, and the following command will show you that some tables were created in the MySQL database: mysqlshow -u root -p artifactory .
Now continue tunning a bit this software in the next entry.
Mostrando entradas con la etiqueta artifactory. Mostrar todas las entradas
Mostrando entradas con la etiqueta artifactory. Mostrar todas las entradas
miércoles, 10 de agosto de 2011
miércoles, 18 de mayo de 2011
What if I want to deploy/upload several files to artifactory or nexus with Maven?
Regardless of the repository you are using to store generated artifacts, the default Maven configuration for, let's say, WAR file, is upload a WAR file.. interesting..
A common configuration commented here also uploads the source code as a jar file, and that is very recommendable for debugging.
Another uploaded or auto-generated file is a "pom.xml" project descriptor file for your artifact.
But we want to go further, we want to upload the sql file needed to generate our initial database, or the pdf with the documentation of this release.. how to get this?
With this plugin, you are associating with the same artifact the "document.pdf" file, the "initdb.sql" file, the war, the sources jar, the pom.xml file... all them with the same version, and with the possibility of declaring any of them as a dependency.
It will be executed in package phase, beware because you may mistake the phases and attach something not yet created, for example, the pdf may be created in pre-site phase instead of .. compile, for example.
In the case of multiple configurations, you can configure it like this:
In this case, if we execute "mvn deploy", only "initdb.sql" will be attached, if we execute "mvn site-deploy", it will be only attached "document.pdf" (because it is supposed to be created in pre-site phase, but I am not sure if it will be deployed in "artifactory" or "nexus", because you don't pass through "deploy" phase, I would say it won't.
The best, if you execute "mvn site-deploy deploy", firstly "document.pdf" is attached in "site" phase, then "initbd.sql" is attached in "package" phase, and finally all them are deployed in "deploy" phase. Really useful!
This is the solution for a problem we wanted to solve in my job, the solution was taken here, thanks!
A common configuration commented here also uploads the source code as a jar file, and that is very recommendable for debugging.
Another uploaded or auto-generated file is a "pom.xml" project descriptor file for your artifact.
But we want to go further, we want to upload the sql file needed to generate our initial database, or the pdf with the documentation of this release.. how to get this?
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <executions>
<execution> <id>attach-artifacts</id> <phase>package</phase>
<goals> <goal>attach-artifact</goal> </goals> <configuration> <artifacts> <artifact> <file>src\main\sql\initdb.sql</file> <type>sql</type> <classifier>create</classifier> </artifact> <artifact> <file>target\site\docs\document.pdf</file> <type>pdf</type> <classifier>doc</classifier> </artifact> </artifacts> </configuration> </execution> </executions> </plugin>
With this plugin, you are associating with the same artifact the "document.pdf" file, the "initdb.sql" file, the war, the sources jar, the pom.xml file... all them with the same version, and with the possibility of declaring any of them as a dependency.
It will be executed in package phase, beware because you may mistake the phases and attach something not yet created, for example, the pdf may be created in pre-site phase instead of .. compile, for example.
In the case of multiple configurations, you can configure it like this:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <executions>
<execution> <id>attach-artifacts1</id> <phase>package</phase>
<goals> <goal>attach-artifact</goal> </goals> <configuration> <artifacts> <artifact> <file>src\main\sql\initdb.sql</file> <type>sql</type> <classifier>create</classifier> </artifact> </artifacts> </configuration> </execution> <execution> <id>attach-artifacts2</id> <phase>site</phase>
<goals> <goal>attach-artifact</goal> </goals> <configuration> <artifacts> <artifact> <file>target\site\docs\document.pdf</file> <type>pdf</type> <classifier>doc</classifier> </artifact> </artifacts> </configuration> </execution> </executions> </plugin>In this case, if we execute "mvn deploy", only "initdb.sql" will be attached, if we execute "mvn site-deploy", it will be only attached "document.pdf" (because it is supposed to be created in pre-site phase, but I am not sure if it will be deployed in "artifactory" or "nexus", because you don't pass through "deploy" phase, I would say it won't.
The best, if you execute "mvn site-deploy deploy", firstly "document.pdf" is attached in "site" phase, then "initbd.sql" is attached in "package" phase, and finally all them are deployed in "deploy" phase. Really useful!
This is the solution for a problem we wanted to solve in my job, the solution was taken here, thanks!
jueves, 5 de mayo de 2011
Roll your own Continuous Integration System (C.I.S.): Artifactory repositories configuration: snapshot, releases and security.
Roll your own Continuous Integration System (C.I.S.)
Content:
In order to ease the explanation about security and maven deploy, lets create the simplest Maven project possible.
Create a directory
Create a "pom.xml" file with the following content:
Now that you have the out-of-the-box Artifactory installation and a Maven project, try to upload your project to the Artifactory repository manager.
Remember: You must have a Maven installation in order to run those examples. As far as you have followed this blog, you should have installed SpringSource Tool Suite, that brings with Maven. Maybe you need insert "mvn" executable in the PATH.
Try to execute "mvn deploy" in the same directory than "pom.xml".
Read the bold, it means that either in your project or in other possible settings file, you are not specifying where are you willing to deploy your project.
Note: not explained yet, but there is a lifecycle somewhere in Internet that says "deploying requires compiling first" for instance. So, when you ask Maven to do "deploy", you are also asking it to compile, testing and some other actions.
Note: The examples are based in basic configurations and no network troubles. Everything in the same host and so on. Take it as it is, an example.
Go to Artifactory, "Artifacts" tabs, and click in the second repository, "libs-snapshot-local"
Copy it to your "pom.xml" (your project, remember?)
Now execute again "mvn deploy", let's check the response: (Yes, it fails again, I do not like suspense)
This error means that you are not allowed to do the upload. That is because you are trying to upload an SNAPSHOT in a RELEASE repository. WTF?
See your pom.xml, <version>1.0-SNAPSHOT</version>. That -SNAPSHOT is being read by Artifactory in order to determine whether it is a release or not.
Now travel to Artifactory. Log in (user "admin", password "password"), and go to Admin tab.
Inside Admin tab, Repositories menu and put your mouse over "libs-release-local", click "Edit".
There it is, the guts of the repository configuration. See how out-of-the-box "libs-release-local" repository can only handle with RELEASES, and you are trying to upload a SNAPSHOT. It is not possible!!.
First option, change <version>1.0-SNAPSHOT</version> for <version>1.0</version>. Come on! do it! it will fail xD. Why? You do not have permissions yet :P
It is not a good idea anyway. Just do not release anything until you know what are really doing.
Second option, in that window, you can tick "Handle Snapshots" and it will fail, because of permissions. It is a matter of time.
Third option, see above now to copy the "distribution management" information of a repository, and take the information from "libs-snapshot-local". This is the best option right now. Your "pom.xml" should look like:
Now try "mvn deploy" in order to confirm that I was right, permissions are not set yet.
Now let's set the damn permissions!
"Admin" tab, menu "Permissions"
New (in the right side)
We are going to configure the permissions for all our local repositories:
Name: Local repositories
Include Patterns: Any
Exclude Patterns: None
Repositories: Any Local Repository
And "Create" it, it is done.
Repeat the operation, "mvn deploy", and it should be able to compile and deploy your project to Artifactory repository :)
Last travel to Artifactory, let's find the uploaded artifact.
In the "Artifacts" tab, navigate through "libs-snapshot-local" and you will arrive to your project.
By clicking in the artifact itself, you will get the Maven code for declaring it as dependency for other projects.
The end... quite long, isn't it?
Content:
In order to ease the explanation about security and maven deploy, lets create the simplest Maven project possible.
Create a directory
Create a "pom.xml" file with the following content:
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0" 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>com.mycompany</groupid>
<artifactid>mavenproject</artifactid>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
</project>
Now that you have the out-of-the-box Artifactory installation and a Maven project, try to upload your project to the Artifactory repository manager.
Remember: You must have a Maven installation in order to run those examples. As far as you have followed this blog, you should have installed SpringSource Tool Suite, that brings with Maven. Maybe you need insert "mvn" executable in the PATH.
Try to execute "mvn deploy" in the same directory than "pom.xml".
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mavenproject 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mavenproject ---
[INFO] Installing /home/***/NetBeansProjects/mavenproject10/pom.xml to /home/***/.m2/repository/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ mavenproject ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.586s
[INFO] Finished at: Tue May 03 22:36:23 CEST 2011
[INFO] Final Memory: 3M/74M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project mavenproject: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Read the bold, it means that either in your project or in other possible settings file, you are not specifying where are you willing to deploy your project.
Note: not explained yet, but there is a lifecycle somewhere in Internet that says "deploying requires compiling first" for instance. So, when you ask Maven to do "deploy", you are also asking it to compile, testing and some other actions.
Note: The examples are based in basic configurations and no network troubles. Everything in the same host and so on. Take it as it is, an example.
Go to Artifactory, "Artifacts" tabs, and click in the second repository, "libs-snapshot-local"
By clicking the repository, its information is displayed at the right side. We want "Distribution Management" section.
<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>com.mycompany</groupId>
<artifactId>mavenproject</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<distributionManagement>
<repository>
<id>dhcppc24</id>
<name>dhcppc24-releases</name>
<url>http://localhost:8080/artifactory/libs-release-local</url>
</repository>
</distributionManagement>
</project>
Now execute again "mvn deploy", let's check the response: (Yes, it fails again, I do not like suspense)
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mavenproject 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mavenproject ---
[INFO] Installing /home/***/NetBeansProjects/mavenproject10/pom.xml to /home/***/.m2/repository/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ mavenproject ---
Downloading: http://localhost:8080/artifactory/libs-release-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml
Uploading: http://localhost:8080/artifactory/libs-release-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110503.214739-1.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.660s
[INFO] Finished at: Tue May 03 23:47:39 CEST 2011
[INFO] Final Memory: 3M/74M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project mavenproject: Failed to deploy artifacts: Could not transfer artifact com.mycompany:mavenproject:pom:1.0-20110503.214739-1 from/to dhcppc24 (http://localhost:8080/artifactory/libs-release-local): Failed to transfer file: http://localhost:8080/artifactory/libs-release-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110503.214739-1.pom. Return code is: 409 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
This error means that you are not allowed to do the upload. That is because you are trying to upload an SNAPSHOT in a RELEASE repository. WTF?
See your pom.xml, <version>1.0-SNAPSHOT</version>. That -SNAPSHOT is being read by Artifactory in order to determine whether it is a release or not.
Now travel to Artifactory. Log in (user "admin", password "password"), and go to Admin tab.
Inside Admin tab, Repositories menu and put your mouse over "libs-release-local", click "Edit".
There it is, the guts of the repository configuration. See how out-of-the-box "libs-release-local" repository can only handle with RELEASES, and you are trying to upload a SNAPSHOT. It is not possible!!.
First option, change <version>1.0-SNAPSHOT</version> for <version>1.0</version>. Come on! do it! it will fail xD. Why? You do not have permissions yet :P
It is not a good idea anyway. Just do not release anything until you know what are really doing.
Second option, in that window, you can tick "Handle Snapshots" and it will fail, because of permissions. It is a matter of time.
Third option, see above now to copy the "distribution management" information of a repository, and take the information from "libs-snapshot-local". This is the best option right now. Your "pom.xml" should look like:
<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>com.mycompany</groupId>
<artifactId>mavenproject</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<distributionManagement>
<repository>
<id>dhcppc24</id>
<name>dhcppc24-releases</name>
<url>http://localhost:8080/artifactory/libs-release-local</url> </repository><snapshotRepository>
<id>dhcppc24</id>
<name>dhcppc24-snapshots</name>
<url>http://localhost:8080/artifactory/libs-snapshot-local</url>
</snapshotRepository>
</distributionManagement>
</project>Now try "mvn deploy" in order to confirm that I was right, permissions are not set yet.
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mavenproject 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mavenproject ---
[INFO] Installing /home/***/NetBeansProjects/mavenproject10/pom.xml to /home/***/.m2/repository/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ mavenproject ---
Downloading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml
Downloaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml (359 B at 7.5 KB/sec)
Uploading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110505.213434-2.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.637s
[INFO] Finished at: Thu May 05 23:34:34 CEST 2011
[INFO] Final Memory: 3M/74M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project mavenproject: Failed to deploy artifacts: Could not transfer artifact com.mycompany:mavenproject:pom:1.0-20110505.213434-2 from/to dhcppc24 (http://localhost:8080/artifactory/libs-snapshot-local): Failed to transfer file: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110505.213434-2.pom. Return code is: 401 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Now let's set the damn permissions!
"Admin" tab, menu "Permissions"
We are going to configure the permissions for all our local repositories:
Name: Local repositories
Include Patterns: Any
Exclude Patterns: None
Repositories: Any Local Repository
Users tab: Anonymous users must be able to Deploy, automatically will be able to Annotate and Read.
Repeat the operation, "mvn deploy", and it should be able to compile and deploy your project to Artifactory repository :)
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mavenproject 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mavenproject ---
[INFO] Installing /home/***/NetBeansProjects/mavenproject10/pom.xml to /home/***/.m2/repository/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ mavenproject ---
Downloading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml
Downloaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml (359 B at 5.7 KB/sec)
Uploading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110505.214558-2.pom
Uploaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/mavenproject-1.0-20110505.214558-2.pom (823 B at 3.4 KB/sec)
Downloading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/maven-metadata.xml
Downloaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/maven-metadata.xml (351 B at 8.6 KB/sec)
Uploading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml
Uploaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/1.0-SNAPSHOT/maven-metadata.xml (598 B at 20.1 KB/sec)
Uploading: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/maven-metadata.xml
Uploaded: http://localhost:8080/artifactory/libs-snapshot-local/com/mycompany/mavenproject/maven-metadata.xml (317 B at 4.1 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.034s
[INFO] Finished at: Thu May 05 23:45:58 CEST 2011
[INFO] Final Memory: 3M/74M
[INFO] ------------------------------------------------------------------------
Last travel to Artifactory, let's find the uploaded artifact.
In the "Artifacts" tab, navigate through "libs-snapshot-local" and you will arrive to your project.
By clicking in the artifact itself, you will get the Maven code for declaring it as dependency for other projects.
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>mavenproject</artifactId>
<version>1.0-20110505.214856-1</version>
<type>pom</type>
</dependency>
The end... quite long, isn't it?
domingo, 10 de abril de 2011
Roll your own Continuous Integration System (C.I.S.): Artifactory installation, Linux, MySQL and Tomcat 6.x
Roll your own Continuous Integration System (C.I.S.)
Content:
War installation
There are numerous well-formed tutorials about how to install Artifactory as the chosen Maven Dependencies Repository of our Continuous Integration System.
I will summarize their steps as concisely as possible:
A trip to a default configured Artifactory
Some default features:
- It supports Maven, Ivy and Gradle systems. We will only use Maven here.
- Artifactory provide several remote dependency repositories, and it will act as a proxy downloading and storing from those repositories for you.
- A dead-simple security schema. It is possible only for admins to upload files. User:admin, Pass: password. Shhh, it's a secret ;)
- Search engine for classes, packages and other files.
Welcome Page:
As said before, Artifactory can serve to Maven, Gradle and Ivy.
See the Home tab -> Left menu -> Client settings -> Maven Settings. (You are allowed to nose around Ivy and Gradle, but don't tell me :P )
Next, you have some sections to declare and put in your settings.xml configuration file. It's a bit early for this, don't worry, only keep it in mind.
Artifacts:
Some layouts to improve your feeling in searches (What the fuck, so much time reading Microsoft marketing), mainly they are offered to you both tree and list structure.
The tree layout is created through the groupId + artifactId, being the default repositories the roots of the trees, one for each repository.
Notice that if you click over a repository, you will get a Maven snippet for your pom.xml, for example:
<distributionManagement>
<repository>
<id>linux-wdx0</id>
<name>linux-wdx0-releases</name>
<url>http://localhost:8080/artifactory/libs-3rd-party</url>
</repository>
</distributionManagement>
If you paste the snippet in your pom.xml (remember, only one distributionManagement per pom.xml, so, if you already have one, you will have to merge them), you will be able to upload (if you are authorized, of course) generated artifacts to that repository with "mvn deploy" in deploy phase.
Default repositories in Artifactory:
libs-release-local: Your libraries and products go here, only releases.
libs-snapshots-local: Your libraries and products go here, snapshots.
plugins-release-local: Your plugins, or plugins needed by you, releases, here.
plugins-snapshots-local: Your plugins, or plugins needed by you, releases, here.
ext-releases-local: 3rd party libraries, releases, needed by your projects. (i.e. Spring, ojdbc driver.. )
ext-snapshot-local: 3rd party libraries, snapshots, needed by your projects.
Artifact resolution in Artifactory:
I do not like to simply repeat what is already written and it is not improvable by me:
http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositories
Here finishes first chapter about Artifactory. Coming soon: Simple security and customization of repositories.
Content:
War installation
There are numerous well-formed tutorials about how to install Artifactory as the chosen Maven Dependencies Repository of our Continuous Integration System.
I will summarize their steps as concisely as possible:
- Create a directory with owner tomcat.tomcat (user/group) where Artifactory is meant to put all its information and artifacts. Let's say... /var/artifactory
- Edit /usr/share/tomcat6/conf/tomcat6.conf and add the variable anywhere in the file. I prefer at top. ARTIFACTORY_HOME="/var/artifactory"
- Download last version of OSS Artifactory (Or pay the license if you find it worthy, of course).
- Unzip and install artifactory.war into your Tomcat6, remember how?
- you may copy artifactory.war into /usr/share/tomcat6/webapps/ if you have direct control over the filesystem, or
- you may use the Manager (/manager/html) application if you installed it previously
- Once artifactory is copied, automatically is run, and you should see in your ARTIFACTORY_HOME how some directories have appeared. Now you have a secureless, derby-managed Artifactory installation not ready for production, but perfect for testing.
A trip to a default configured Artifactory
Some default features:
- It supports Maven, Ivy and Gradle systems. We will only use Maven here.
- Artifactory provide several remote dependency repositories, and it will act as a proxy downloading and storing from those repositories for you.
- A dead-simple security schema. It is possible only for admins to upload files. User:admin, Pass: password. Shhh, it's a secret ;)
- Search engine for classes, packages and other files.
Welcome Page:
Do you need more explanations?
Maven settings:
See the Home tab -> Left menu -> Client settings -> Maven Settings. (You are allowed to nose around Ivy and Gradle, but don't tell me :P )
Next, you have some sections to declare and put in your settings.xml configuration file. It's a bit early for this, don't worry, only keep it in mind.
Artifacts:
Some layouts to improve your feeling in searches (What the fuck, so much time reading Microsoft marketing), mainly they are offered to you both tree and list structure.
The tree layout is created through the groupId + artifactId, being the default repositories the roots of the trees, one for each repository.
Notice that if you click over a repository, you will get a Maven snippet for your pom.xml, for example:
<distributionManagement>
<repository>
<id>linux-wdx0</id>
<name>linux-wdx0-releases</name>
<url>http://localhost:8080/artifactory/libs-3rd-party</url>
</repository>
</distributionManagement>
If you paste the snippet in your pom.xml (remember, only one distributionManagement per pom.xml, so, if you already have one, you will have to merge them), you will be able to upload (if you are authorized, of course) generated artifacts to that repository with "mvn deploy" in deploy phase.
Default repositories in Artifactory:
libs-release-local: Your libraries and products go here, only releases.
libs-snapshots-local: Your libraries and products go here, snapshots.
plugins-release-local: Your plugins, or plugins needed by you, releases, here.
plugins-snapshots-local: Your plugins, or plugins needed by you, releases, here.
ext-releases-local: 3rd party libraries, releases, needed by your projects. (i.e. Spring, ojdbc driver.. )
ext-snapshot-local: 3rd party libraries, snapshots, needed by your projects.
Artifact resolution in Artifactory:
I do not like to simply repeat what is already written and it is not improvable by me:
http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositories
Here finishes first chapter about Artifactory. Coming soon: Simple security and customization of repositories.
domingo, 20 de marzo de 2011
Managing Maven dependencies with an external dependencies repository
Content:
I have been talking a lot about Maven dependencies for a local machine. It is high time to start talking about remote dependencies.
When you define a dependency in your pom.xml file, that dependency is sought in repo1.maven.org. But your libraries and internal dependencies are not there. Certainly they are in your local repository, but not in your workmate's own.
I do not find necessary to speak in favour of a code repository, the reasons are widely known. Reasons for a dependency repository might be less known because code is always used, but Maven is not (always).
Basic scenario is easy to find nevertheless:
With this entry in pom.xml, we are asking Maven to search in this URL for any dependency we might need, and, for being in pom.xml, that configuration is project-scoped, being shared with the project itself in code repository.
All we have to keep in mind is that the server MUST be accessible by any of your partners who you are expecting to compile the project. In this example, our partners will find that they do not have Artifactory installed in their localhost, and you will find lots of complains for creating a local-dependant configuration for a department project.
Your second try made it better:
However, as you find comfortable to download dependencies, you will find awful to upload your libraries manually through web interface. It is possible as well to improve this.
With the correct Artifactory and Nexus (trying to be neutral by now) settings, you can automatize your system for uploading a library once it is compiled by Maven:
by typing "mvn deploy" instead of "mvn install" in your Maven console or IDE compilation button.
Now you can enjoy of an easy way to share and download department-scoped libraries within your department in a new fashion way of making things work. Your objetive: your project should compile and run only by downloading it in any machine with zero configuration.
I have been talking a lot about Maven dependencies for a local machine. It is high time to start talking about remote dependencies.
When you define a dependency in your pom.xml file, that dependency is sought in repo1.maven.org. But your libraries and internal dependencies are not there. Certainly they are in your local repository, but not in your workmate's own.
I do not find necessary to speak in favour of a code repository, the reasons are widely known. Reasons for a dependency repository might be less known because code is always used, but Maven is not (always).
Basic scenario is easy to find nevertheless:
- You create a library for a project with Maven.
- You design that library as a dependency for that project.
- You might want your workmate to compile the project in his/her computer, but...
- Binaries should never be uploaded to code repository!
- Shared folders are system dependant and difficult to automatize, trace and export.
- We are looking for zero specific configuration in a compilation.
If you could only upload to a private repo1.maven.org repository in order to make accessible an internal dependency for your company... You can!
There are two main open-source implementation for this task: Nexus and Artifactory. Both seem alike, but I chose to know deeply the last one, maybe I could find some time for comparing both in installation, configuration and performance.
If you had in your pom.xml a configuration like this:
<repositories> <repository> <snapshots /> <id>snapshots</id> <name>libs-internal</name> <url>http://localhost:8080/artifactory/libs-internal</url> </repository> </repositories>With this entry in pom.xml, we are asking Maven to search in this URL for any dependency we might need, and, for being in pom.xml, that configuration is project-scoped, being shared with the project itself in code repository.
All we have to keep in mind is that the server MUST be accessible by any of your partners who you are expecting to compile the project. In this example, our partners will find that they do not have Artifactory installed in their localhost, and you will find lots of complains for creating a local-dependant configuration for a department project.
Your second try made it better:
<repository>
<snapshots /> <id>snapshots</id> <name>libs-internal</name> <url>http://srvmachine:8080/artifactory/libs-internal</url> </repository>However, as you find comfortable to download dependencies, you will find awful to upload your libraries manually through web interface. It is possible as well to improve this.
With the correct Artifactory and Nexus (trying to be neutral by now) settings, you can automatize your system for uploading a library once it is compiled by Maven:
<distributionManagement>
<repository>
<id>linux-wdx0</id>
<name>linux-wdx0-releases</name>
<url>http://srvmachine:8080/artifactory/libs-release-local</url>
</repository>
</distributionManagement>
by typing "mvn deploy" instead of "mvn install" in your Maven console or IDE compilation button.
Now you can enjoy of an easy way to share and download department-scoped libraries within your department in a new fashion way of making things work. Your objetive: your project should compile and run only by downloading it in any machine with zero configuration.
domingo, 19 de diciembre de 2010
Roll your own Continuous Integration System (C.I.S.): Abstract.
Roll your own Continuous Integration System (C.I.S.)
Content:
http://looking4q.blogspot.com/2011/01/roll-your-own-continuous-integration.html
This is the very first goal for the followers of this blog.
For those who doesn't know what a Continuous Integration System is, you could take a look at wikipedia, but, summarizing with an example, is a software that every night downloads your code, compiles it, executes unitary testing and deploys it in your server or in your dependency repository.
That's not all. It could pass several control checks like code style, testing code coverage, code quality, it makes a report and send it to your email, and other for the guilty developer that wrote some code that generates lots of warnings.
This information is processed for cyclic dependencies, copied&pasted code, percent of commented code, percent of tested code... reports and more reports.
Some of this reports are also postprocessed in order to evaluate each developer independently. Then it creates a dashboard with scores for each participant, trying to motivate the team for a better code.
Appealing enough?
I have selected some tools that I use in my company. This list might be modified in near future:
Code Repository: We are using Subversion
Dependencies manager: Maven
Dependencies repository: Artifactory, which understands Maven among others.
C.I.S Manager: Hudson: which understands Maven and SVN among others.
Extra: Sonar as quality of code reporter.
Extra: Wiki or CMS
And Tomcat6 as the container of everything or almost everything.
In next articles, I will try to explain how to install and deploy each tool in order to get something similar to my example in your own company or at home.
See you soon!
Content:
http://looking4q.blogspot.com/2011/01/roll-your-own-continuous-integration.html
This is the very first goal for the followers of this blog.
For those who doesn't know what a Continuous Integration System is, you could take a look at wikipedia, but, summarizing with an example, is a software that every night downloads your code, compiles it, executes unitary testing and deploys it in your server or in your dependency repository.
That's not all. It could pass several control checks like code style, testing code coverage, code quality, it makes a report and send it to your email, and other for the guilty developer that wrote some code that generates lots of warnings.
This information is processed for cyclic dependencies, copied&pasted code, percent of commented code, percent of tested code... reports and more reports.
Some of this reports are also postprocessed in order to evaluate each developer independently. Then it creates a dashboard with scores for each participant, trying to motivate the team for a better code.
Appealing enough?
I have selected some tools that I use in my company. This list might be modified in near future:
Code Repository: We are using Subversion
Dependencies manager: Maven
Dependencies repository: Artifactory, which understands Maven among others.
C.I.S Manager: Hudson: which understands Maven and SVN among others.
Extra: Sonar as quality of code reporter.
Extra: Wiki or CMS
And Tomcat6 as the container of everything or almost everything.
In next articles, I will try to explain how to install and deploy each tool in order to get something similar to my example in your own company or at home.
See you soon!
martes, 14 de diciembre de 2010
Basic Artifactory installation
On Un*x:
http://wiki.jfrog.org/confluence/display/RTF/Installing+on+Un*x
On Windows (I really like this one)
http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository
http://wiki.jfrog.org/confluence/display/RTF/Installing+on+Un*x
On Windows (I really like this one)
http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository
Suscribirse a:
Entradas (Atom)