Talk:Creating gCube Maven components: How-To

From Gcube Wiki
Revision as of 16:10, 18 June 2012 by Gabriele.giammatteo (Talk | contribs) (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…')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Dependencies on External 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

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.


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.

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....


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.


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: 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).

Furthermore, the repository will be added to gcube-public-deps grouping repository.

Troubleshooting 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.


This issue does not take place when the proxed repository has index files (..... eg..... ) recognized and read by Nexus.