Difference between revisions of "Talk:Creating gCube Maven components: How-To"

From Gcube Wiki
Jump to: navigation, search
(Created page with '== Dependencies on External Repositories == gCube building and deployment environment are configured to use gCube Snapshots (only in /devsec scope), gCube Releases, gCube Extern…')
 
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
== Dependencies on External Repositories ==
+
=== Repositories ===
  
−
gCube building and deployment environment are configured to use gCube Snapshots (only in /devsec scope), gCube Releases, gCube Externals and Maven Central repositories for dependency resolution. In other words, any dependency declared in pom.xml that can be found in those repositories will be resolved at build time and deployment time without any further configuration. To emulate this behaviour also in development environment, it is strongly suggested to use the settings.xml file suggested here
+
As a one-off task, developers must configure these repositories in the <code>~/.m2/settings.xml</code> file of their local Maven installation, as follows:
  
−
Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project.
+
<source lang="xml">
 +
<settings 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/settings-1.0.0.xsd">
  
 +
<servers>
 +
<server>
 +
<id>gcube-snapshots</id>
 +
<username>gcube-user</username>
 +
<password>maven</password>
 +
</server>
 +
</servers>
 +
  
 +
<profiles>
 +
<profile>
 +
<id>gcube</id>
 +
<repositories>
 +
<repository>
 +
<id>gcube-snapshots</id>
 +
<name>gCube Snapshots</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-snapshots</url>
 +
<releases>
 +
<enabled>false</enabled>
 +
</releases>
 +
<snapshots>
 +
<enabled>true</enabled>
 +
</snapshots>
 +
</repository>
 +
<repository>
 +
<id>gcube-releases</id>
 +
<name>gCube Releases</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-releases</url>
 +
<snapshots>
 +
<enabled>false</enabled>
 +
</snapshots>
 +
<releases>
 +
<enabled>true</enabled>
 +
</releases>
 +
</repository>
 +
<repository>
 +
<id>gcube-externals</id>
 +
<name>gCube Externals</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-externals</url>
 +
<snapshots>
 +
<enabled>false</enabled>
 +
</snapshots>
 +
<releases>
 +
<enabled>true</enabled>
 +
</releases>
 +
</repository>
 +
</repositories>
  
−
On one hand, Maven allows declaration of additional dependency resolution repositories in the pom.xml file that can easily ............. serve the purpose .......... for any software stored in a Maven repository. On the other hand, to guarantee the quality of gCube software it is required to check quality and trustwhortiness of its dependencies disallowing usage of external software that does not pass a quality check.
+
<pluginRepositories>
 +
<pluginRepository>
 +
<id>gcube-snapshots</id>
 +
<name>gCube Snapshots</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-snapshots</url>
 +
<releases>
 +
<enabled>false</enabled>
 +
</releases>
 +
<snapshots>
 +
<enabled>true</enabled>
 +
</snapshots>
 +
</pluginRepository>
 +
<pluginRepository>
 +
<id>gcube-releases</id>
 +
<name>gCube Releases</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-releases</url>
 +
<snapshots>
 +
<enabled>false</enabled>
 +
</snapshots>
 +
<releases>
 +
<enabled>true</enabled>
 +
</releases>
 +
</pluginRepository>
 +
<pluginRepository>
 +
<id>gcube-externals</id>
 +
<name>gCube Externals</name>
 +
<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-externals</url>
 +
<snapshots>
 +
<enabled>false</enabled>
 +
</snapshots>
 +
<releases>
 +
<enabled>true</enabled>
 +
</releases>
 +
</pluginRepository>
 +
</pluginRepositories>
 +
 +
</profile>
 +
</profiles>
  
−
Such a control over usage of external Maven repositories is realized by allowing gCube components of using external repository not directly but through a proxy repository (a.k.a. shadow repository) created on CNR's Nexus Repository Portal. .... what is a proxy repository....
+
<activeProfiles>
 +
<activeProfile>gcube</activeProfile>
 +
</activeProfiles>
 +
</settings>
 +
</source>
  
  
−
Please note that use of an external repository directly will technically work in the development environment and also in the ETICS building environment, but it will fail in deployment phase. In fact, Software Gateway only resolves software stored or proxed by Nexus.
+
'''Note:Developers must not configure these repositories in their POMs''', only in <code>settings.xml</code>.  
  
 +
This is to:
 +
* keep their projects independent from future changes in repository locations;
 +
* avoid interference with ETICS builds, where access to these repositories may comprise correct system integration;
  
−
Addition of an third party repository proxy in Nexus
 
−
Any developer that needs to use an externa public Maven repository, should never use it directly, but asking for creation of a proxy of that repository on Nexus.
 
  
−
Procedure for asking addition of a proxy repository is:
+
=== Third Party external Repositories ===
−
1) open a ticket of type "Task" in iMarine TRAC (at .......URL.....)
+
−
2) ticket's description must report:
+
−
  - URL of repository to add
+
−
  - organization which hosts the repository
+
−
  - license of software stored in the repository (if available)
+
−
  - reasons (e.g. which gCube component needs it)
+
−
3) assign the ticket to the Release Manager
+
  
−
Release Manager will process the ticket checking that software satisfy the quality level and no license issue migth rise from the usage of software stored in the repository. If request is accepted, a new proxy repository is created and the repository's id will be communicated publicly on gCube's developers mailinglist (a.k.a. TCOM mailinglist).
+
Using the the <code>settings.xml</code> aforementioned, any dependency declared in pom.xml that can be found in one of gCube repositories or in Maven Central will be resolved at build time and deployment time without any further configuration.
  
−
Furthermore, the repository will be added to gcube-public-deps grouping repository.
+
Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project. E.g.:
  
−
Troubleshooting
+
<source lang="xml" highlight="3,4">
−
It might happens that a new proxy repository will appear as empty in Nexus and any search (through Nexus Portal as well as from Eclipse) performed to find artifacts contained in the proxed repository will not find any artifact. This is a normal behaviour because Nexus download an artifact from the proxed repository only upon explicit request. After the first request, the artifact is added to Nexus indexes and will be, in such a way, discoverable browinsg and/or searching the indexes.
+
<repositories>
 +
    <repository>
 +
    <id>[repository-id]</id>
 +
    <url>[repository URL]</url>
 +
    </repository>
 +
</repositories>
 +
</source>
  
 +
Though technically possible to add any Maven repository in this way, in order to guarantee the quality of gCube software it is required to check quality and trustwhortiness of its dependencies disallowing usage of external software that does not pass a quality check. To enforce such a control over external Maven repositories, '''gCube components are allowed to use external repository not directly but only through a proxy repository''' (a.k.a. shadow repository) created on CNR's Nexus Repository Portal.
  
−
This issue does not take place when the proxed repository has index files (..... eg..... ) recognized and read by Nexus.
+
The creation of proxy repositories in Nexus Portal is required because at deployment time, only artifacts available in Nexus (in one of the repositories configured in Nexus) can be downloaded and installed.
 +
 
 +
List of all repositories in Nexus Portal is available at http://maven.research-infrastructures.eu/nexus/index.html#view-repositories
 +
 
 +
==== How to request creation of a new proxy repository in Nexus ====
 +
Proxy Repositories on Nexus are created by the Release Manager. To request a new proxy a new ticket must be created.
 +
 
 +
Details of ticket are:
 +
#  open a ticket of type "Task" in iMarine TRAC (at https://issue.imarine.research-infrastructures.eu/)
 +
# ticket's '''description''' must report:
 +
#* URL of repository to add
 +
#* organization which hosts the repository
 +
#* which artifacts are needed from that repository
 +
# '''Milestone''' field should be set to the gCube release in which the component is expected to be released
 +
# '''Component''' field must report the gCube component that needs the external repository
 +
# '''Blocking''' should list (if any) other tickets blocked by the addition of this Maven repository
 +
# '''Task Category''' is ''software''
 +
# assign the ticket to the Release Manager
 +
 
 +
An example of ticket for requesting a new repository mirror is reported in the figure below.
 +
[[Image:New_maven_mirror_repo.png|600px|center|Ticket for requesting a new Mirror Repository]]
 +
 
 +
Release Manager will process the ticket checking that repository satisfy the quality level and no issues are foreseen from the usage of software stored in the repository. If request is accepted, a new proxy repository is created and the repository's URL will be communicated publicly on gCube's developers mailinglist (a.k.a. TCOM mailinglist).
 +
 
 +
Knowing the mirror repository URL, developer can use it adding following lines in pom.xml. E.g.
 +
 
 +
<source lang="xml" highlight="3,4">
 +
<repositories>
 +
    <repository>
 +
    <id>gcube-ext-osgeo</id>
 +
    <url>http://maven.research-infrastructures.eu/nexus/content/repositories/osgeo/</url>
 +
    </repository>
 +
</repositories>
 +
</source>

Latest revision as of 12:40, 22 June 2012

Repositories

As a one-off task, developers must configure these repositories in the ~/.m2/settings.xml file of their local Maven installation, as follows: 

<settings 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/settings-1.0.0.xsd">
 
	<servers>
		<server>
			<id>gcube-snapshots</id>
			<username>gcube-user</username>
			<password>maven</password>
		</server>
	</servers>
 
 
	<profiles>
		<profile>
			<id>gcube</id>
			<repositories>
				<repository>
					<id>gcube-snapshots</id>
					<name>gCube Snapshots</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-snapshots</url>
					<releases>
						<enabled>false</enabled>
					</releases>
					<snapshots>
						<enabled>true</enabled>
					</snapshots>
				</repository>
				<repository>
					<id>gcube-releases</id>
					<name>gCube Releases</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-releases</url>
					<snapshots>
						<enabled>false</enabled>
					</snapshots>
					<releases>
						<enabled>true</enabled>
					</releases>
				</repository>
				<repository>
					<id>gcube-externals</id>
					<name>gCube Externals</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-externals</url>
					<snapshots>
						<enabled>false</enabled>
					</snapshots>
					<releases>
						<enabled>true</enabled>
					</releases>
				</repository>
			</repositories>
 
			<pluginRepositories>
				<pluginRepository>
					<id>gcube-snapshots</id>
					<name>gCube Snapshots</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-snapshots</url>
					<releases>
						<enabled>false</enabled>
					</releases>
					<snapshots>
						<enabled>true</enabled>
					</snapshots>
				</pluginRepository>
				<pluginRepository>
					<id>gcube-releases</id>
					<name>gCube Releases</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-releases</url>
					<snapshots>
						<enabled>false</enabled>
					</snapshots>
					<releases>
						<enabled>true</enabled>
					</releases>
				</pluginRepository>
				<pluginRepository>
					<id>gcube-externals</id>
					<name>gCube Externals</name>
					<url>http://maven.research-infrastructures.eu/nexus/content/repositories/gcube-externals</url>
					<snapshots>
						<enabled>false</enabled>
					</snapshots>
					<releases>
						<enabled>true</enabled>
					</releases>
				</pluginRepository>
			</pluginRepositories>
 
		</profile>
	</profiles>
 
	<activeProfiles>
		<activeProfile>gcube</activeProfile>
	</activeProfiles>
</settings>


Note:Developers must not configure these repositories in their POMs, only in settings.xml.

This is to:

  • keep their projects independent from future changes in repository locations;
  • avoid interference with ETICS builds, where access to these repositories may comprise correct system integration;


Third Party external Repositories

Using the the settings.xml aforementioned, any dependency declared in pom.xml that can be found in one of gCube repositories or in Maven Central will be resolved at build time and deployment time without any further configuration.

Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project. E.g.: 

<repositories>
    <repository>
    	<id>[repository-id]</id>    	<url>[repository URL]</url>    </repository>
</repositories>

Though technically possible to add any Maven repository in this way, in order to guarantee the quality of gCube software it is required to check quality and trustwhortiness of its dependencies disallowing usage of external software that does not pass a quality check. To enforce such a control over external Maven repositories, gCube components are allowed to use external repository not directly but only through a proxy repository (a.k.a. shadow repository) created on CNR's Nexus Repository Portal.

The creation of proxy repositories in Nexus Portal is required because at deployment time, only artifacts available in Nexus (in one of the repositories configured in Nexus) can be downloaded and installed.

List of all repositories in Nexus Portal is available at http://maven.research-infrastructures.eu/nexus/index.html#view-repositories

How to request creation of a new proxy repository in Nexus

Proxy Repositories on Nexus are created by the Release Manager. To request a new proxy a new ticket must be created.

Details of ticket are:

  1. open a ticket of type "Task" in iMarine TRAC (at https://issue.imarine.research-infrastructures.eu/)
  2. ticket's description must report:
    • URL of repository to add
    • organization which hosts the repository
    • which artifacts are needed from that repository
  3. Milestone field should be set to the gCube release in which the component is expected to be released
  4. Component field must report the gCube component that needs the external repository
  5. Blocking should list (if any) other tickets blocked by the addition of this Maven repository
  6. Task Category is software
  7. assign the ticket to the Release Manager

An example of ticket for requesting a new repository mirror is reported in the figure below.

Ticket for requesting a new Mirror Repository

Release Manager will process the ticket checking that repository satisfy the quality level and no issues are foreseen from the usage of software stored in the repository. If request is accepted, a new proxy repository is created and the repository's URL will be communicated publicly on gCube's developers mailinglist (a.k.a. TCOM mailinglist).

Knowing the mirror repository URL, developer can use it adding following lines in pom.xml. E.g. 

<repositories>
    <repository>
    	<id>gcube-ext-osgeo</id>    	<url>http://maven.research-infrastructures.eu/nexus/content/repositories/osgeo/</url>    </repository>
</repositories>
Retrieved from "https://gcube.wiki.gcube-system.org/index.php?title=Talk:Creating_gCube_Maven_components:_How-To&oldid=15392"