Maven cannot find modules in the local .m2 repository, does not work offline

[Georg Grütter]

Hi everyone,

I'm new to vert.x and I am facing a problem with offline builds and builds behind a company firewall. I am writing a module which uses com.jetdrone~yoke~1.0.1 module and build it with Maven. Building and running the module with

mvn clean package

mvn vertx:runMod

works fine, as long as I have internet connection. However, Maven re-downloads the yoke module during every build and dutifully installs it in my local .m2 repository. When trying to build my module offline (with all dependencies present in the local .m2 repository), the build fails with the following error message

[INFO] --- vertx-maven-plugin:2.0.1-final:pullInDeps (PullInDeps) @ fusion.app.m2dev ---

log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

[ERROR] 

org.vertx.java.platform.PlatformManagerException: Module com.jetdrone~yoke~1.0.1 not found in any repositories

at org.vertx.java.platform.impl.DefaultPlatformManager.getModule(DefaultPlatformManager.java:1257)

at org.vertx.java.platform.impl.DefaultPlatformManager.doPullInDependencies(DefaultPlatformManager.java:522)

at org.vertx.java.platform.impl.DefaultPlatformManager.access$800(DefaultPlatformManager.java:58)

at org.vertx.java.platform.impl.DefaultPlatformManager$6.run(DefaultPlatformManager.java:301)

at org.vertx.java.platform.impl.DefaultPlatformManager$12.run(DefaultPlatformManager.java:438)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:724)

Can anyone please explain if (and if yes, why) this is the intended behavior or if something in my build configuration might be broken.

I use vert.x 2.1M2 and maven 3.0.5.

Thanks for your help in advance and cheers,

Georg

[Georg Grütter]

Just to clarify:

• I have read the vert.x documentation which explains how vert.x locates modules
• I have set the mavenLocal  variable in repos.txt to the local maven repository in which the yoke module is stored

[Amit Kumar]

Are you building your modules in Eclipse ? Have you set a M2_REPO variable in eclipse to a different location than ~/.m2/repository ? Did you try creating a repo.txt under your project resources and see if that works ?

[Georg Grütter]

I'm building and running my module exclusively from the command line using Maven. I develop the modules code in Eclipse, through. The Maven plugin for Eclipse has no problems picking up the yoke dependencies which are of course specified in my modules Maven pom.xml (using the compile scope, by the way).

[Norman Maurer]

Could you try with latest vertx release too ?

If this still not works please create a reproduce for us and we will fix it :)

-- 
Norman Maurer

An 30. Januar 2014 at 05:12:47, Georg Grütter (grue...@gmail.com) schrieb:

I'm building and running my module exclusively from the command line using Maven. I develop the modules code in Eclipse, through. The Maven plugin for Eclipse has no problems picking up the yoke dependencies which are of course specified in my modules Maven pom.xml (using the compile scope, by the way).

Are you building your modules in Eclipse ? Have you set a M2_REPO variable in eclipse to a different location than ~/.m2/repository ? Did you try creating a repo.txt under your project resources and see if that works ?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tim Fox]

On 30/01/14 00:28, Georg Grütter wrote:

Hi everyone,

I'm new to vert.x and I am facing a problem with offline builds and builds behind a company firewall. I am writing a module which uses com.jetdrone~yoke~1.0.1 module and build it with Maven. Building and running the module with

mvn clean package

mvn vertx:runMod

If you just want to run the module, you don't need to package it first.

works fine, as long as I have internet connection. However, Maven re-downloads the yoke module during every build and dutifully installs it in my local .m2 repository.

I guess you have declared the yoke *jar* as a dependency in your pom.xml, because it is a non runnable module? This will download the Yoken jar, *not* the module.

When trying to build my module offline (with all dependencies present in the local .m2 repository), the build fails with the following error message

[INFO] --- vertx-maven-plugin:2.0.1-final:pullInDeps (PullInDeps) @ fusion.app.m2dev ---

log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

[ERROR] 

org.vertx.java.platform.PlatformManagerException: Module com.jetdrone~yoke~1.0.1 not found in any repositories

at org.vertx.java.platform.impl.DefaultPlatformManager.getModule(DefaultPlatformManager.java:1257)

at org.vertx.java.platform.impl.DefaultPlatformManager.doPullInDependencies(DefaultPlatformManager.java:522)

at org.vertx.java.platform.impl.DefaultPlatformManager.access$800(DefaultPlatformManager.java:58)

at org.vertx.java.platform.impl.DefaultPlatformManager$6.run(DefaultPlatformManager.java:301)

at org.vertx.java.platform.impl.DefaultPlatformManager$12.run(DefaultPlatformManager.java:438)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:724)

Can anyone please explain if (and if yes, why) this is the intended behavior or if something in my build configuration might be broken.

Can you do a ls in ~/.m2/repository/com/jetdrone/yoke/1.0.1  and tell me what it shows?

I suspect you don't actually have the module there, you just have the jar...

If you are behind a firewall and aren't allowed to access the internet then you can manually install the module in a mods directory, or I believe there is a maven command to manually push an artifact into a Maven local directory (? I am not really a Maven user)

I use vert.x 2.1M2 and maven 3.0.5.

Thanks for your help in advance and cheers,

Georg

[Georg Grütter]

I guess you have declared the yoke *jar* as a dependency in your pom.xml, because it is a non runnable module? This will download the Yoken jar, *not* the module.

That's correct, Tim. I needed that so that eclipse finds the Yoke classes. Is it possible to install the yoke module as a vert.x module somewhere else an have Eclipse pull that instead of the maven dependency?

 

Can you do a ls in ~/.m2/repository/com/jetdrone/yoke/1.0.1  and tell me what it shows?

I suspect you don't actually have the module there, you just have the jar...

Correct again. It's only a jar but it has the mod.json in it. I thought that was sufficient. What would a module look like? Would it be something along the lines of com.jetdrone~yoke~1.0.1.zip?

 

If you are behind a firewall and aren't allowed to access the internet then you can manually install the module in a mods directory, or I believe there is a maven command to manually push an artifact into a Maven local directory (? I am not really a Maven user)

That would be handy. I'll check.

[Tim Fox]

On 30/01/14 13:32, Georg Grütter wrote:

I guess you have declared the yoke *jar* as a dependency in your pom.xml, because it is a non runnable module? This will download the Yoken jar, *not* the module.

That's correct, Tim. I needed that so that eclipse finds the Yoke classes. Is it possible to install the yoke module as a vert.x module somewhere else an have Eclipse pull that instead of the maven dependency?

Declaring the dependency against the jar in the pom is the right thing to do as that's what you need at build time to compile.

 

Can you do a ls in ~/.m2/repository/com/jetdrone/yoke/1.0.1  and tell me what it shows?

I suspect you don't actually have the module there, you just have the jar...

Correct again. It's only a jar but it has the mod.json in it. I thought that was sufficient. What would a module look like? Would it be something along the lines of com.jetdrone~yoke~1.0.1.zip?

You can see the artifacts in Maven Central here:

http://central.maven.org/maven2/com/jetdrone/yoke/1.0.1/

The actual module is this one: yoke-1.0.1-mod.zip

 

If you are behind a firewall and aren't allowed to access the internet then you can manually install the module in a mods directory, or I believe there is a maven command to manually push an artifact into a Maven local directory (? I am not really a Maven user)

That would be handy. I'll check.

[Georg Grütter]

I've just downloaded yoke-1.0.1-mod.zip and tried a few things, all without success however. The original error message prevails. Here's what I did

• copied yoke-1.0.1-mod.zip to my local maven repository: ~/Workspaces/.m2/com/jetdrone/yoke/1.0.1/yoke-1.0.1-mod.zip
• copied the mod to my local mods directory (the one which my VERTX_MODS env variable points to). I tried a couple of names as I wasn't sure how the module is to be stored in a local mods directory:
• yoke-1.0.1-mod.zip
• com.jetdrown~yoke~1.0.1.zip
• com.jetdrone~yoke~1.0.1-mod.zip
• unzipped contents of yoke-1.0.1-mod.zip into directory com.jetdrone~yoke~1.0.1

Here's what my local repos.txt looks like

  1 # Local Maven repo on filesystem                                                                                                                         

  2 mavenLocal:~/Workspaces/.m2                                                     

  3                                                                                 

  4 # Maven central                                                                 

  5 maven:http://repo2.maven.org/maven2                                             

  6                                                                                 

  7 # Sonatype snapshots                                                            

  8 maven:http://oss.sonatype.org/content/repositories/snapshots                    

  9                                                                                 

 10 # Bintray                                                                       

 11 bintray:http://dl.bintray.com  

I have upgraded to vert.x 2.0M5 but the problem remains. 

[Tim Fox]

I'm not sure what to suggest, I suggest debugging the code and figuring out what it's looking for and where (hint: add breakpoints in MavenLocalRepoResolver)

[Georg Grütter]

I'm not sure what to suggest, I suggest debugging the code and figuring out what it's looking for and where (hint: add breakpoints in MavenLocalRepoResolver)

Thanks for your suggestions anyhow, Tim. Debugging maven is not a viable solution for me, unfortunately. I'll try uploading the artifact manually to our company internal maven repo (Archiva) and see if that solves our problem. If it does, we'll be fine.

I'm still wondering what the usual workflow of developers using maven and vertx modules is. 

[Tim Fox]

On 30/01/14 15:56, Georg Grütter wrote:

I'm not sure what to suggest, I suggest debugging the code and figuring out what it's looking for and where (hint: add breakpoints in MavenLocalRepoResolver)

Thanks for your suggestions anyhow, Tim. Debugging maven is not a viable solution for me, unfortunately.

It's not Maven code, it's Vert.x code. It's Vert.x that looks in the local Maven repo.

The code is here https://github.com/eclipse/vert.x/blob/master/vertx-platform/src/main/java/org/vertx/java/platform/impl/resolver/MavenLocalRepoResolver.java#L78

As you can see it's pretty straightforward and just looks for files on the disk. If you add breakpoints in there you should be able to see what it's looking for.

I'll try uploading the artifact manually to our company internal maven repo (Archiva) and see if that solves our problem. If it does, we'll be fine.

I'm still wondering what the usual workflow of developers using maven and vertx modules is.

Can you be a bit more specific about which workflow you mean?

[Georg Grütter]

I started a new project based on the maven archetype in order to figure out what the problem might be. It turns out that everything works fine now. mvn vertx:runMod is now downloading the included modules (yoke mod) into my local Vert.x mods directory (the one VERTX_MODS points to) and I can now run the module locally. The Vert.x mods coexist with the maven artifacts (yoke jar) just fine now. Compared to my previous attempts, there are two differences

- I didn't include my project specific parent pom. I guess this is the source of the problem and I'll try to narrow down the problem tomorrow

- I used mvn eclipse:eclipse to create the Eclipse project template AFTER I added the Maven dependency to yoke. Interestingly enough, the generated eclipse project was not a maven project but a plain java project. I used the maven plugin in eclipse before. I don't think this has anything to do with my previous problem but I thought I'd mention it anyhow.

It's not Maven code, it's Vert.x code. It's Vert.x that looks in the local Maven repo.

Make sense now that you mention it. 

Thanks for the link to the MavenLocalRepoResolver. I'll use that to debug should the problem reoccurs.

Can you be a bit more specific about which workflow you mean?

I assumed that there were common steps to

• download included vertx modules (I see now that mvn vertx:runMod does that for me)
• upload modules to a company internal maven repository manager (still figuring out how that works). 
  

On a general note, you guys provide great support. It's much appreciated. And I really like Vert.x, by the way, might even ditch OSGi as my module system of choice. I'm already spreading the word in the company I work for (Robert Bosch GmbH).

Thanks and cheers,

Georg

[Tim Fox]

On 30/01/14 21:14, Georg Grütter wrote:

I started a new project based on the maven archetype in order to figure out what the problem might be. It turns out that everything works fine now. mvn vertx:runMod is now downloading the included modules (yoke mod) into my local Vert.x mods directory (the one VERTX_MODS points to) and I can now run the module locally. The Vert.x mods coexist with the maven artifacts (yoke jar) just fine now. Compared to my previous attempts, there are two differences

- I didn't include my project specific parent pom. I guess this is the source of the problem and I'll try to narrow down the problem tomorrow

- I used mvn eclipse:eclipse to create the Eclipse project template AFTER I added the Maven dependency to yoke. Interestingly enough, the generated eclipse project was not a maven project but a plain java project. I used the maven plugin in eclipse before. I don't think this has anything to do with my previous problem but I thought I'd mention it anyhow.

It's not Maven code, it's Vert.x code. It's Vert.x that looks in the local Maven repo.

Make sense now that you mention it. 

Thanks for the link to the MavenLocalRepoResolver. I'll use that to debug should the problem reoccurs.

Can you be a bit more specific about which workflow you mean?

I assumed that there were common steps to

• download included vertx modules (I see now that mvn vertx:runMod does that for me)
• upload modules to a company internal maven repository manager (still figuring out how that works).
  

I just use mvn deploy and it pushes the module to oss.sonatype or Maven Central depending on whether it's a SNAPSHOT or not. If you want to push it somewhere else (e.g. internal Nexus repo) then you shoulld be able to just configure Maven in the normal way to do that.

On a general note, you guys provide great support. It's much appreciated. And I really like Vert.x, by the way, might even ditch OSGi as my module system of choice. I'm already spreading the word in the company I work for (Robert Bosch GmbH).

Great! Thanks

Thanks and cheers,

Georg

[Georg Grütter]

I have now tested the setup in the corporate network. Everything works fine as long as the module is in the VERTX_MODS directory. However, Vert.x is still is not able to download the module-zip from our company internal maven archive (no login, no proxy required) and install it there on its own. 

My understanding is that Vert.x uses the repos in repos.txt to search for and download it, rather than using the maven configuration, correct? I configured our company internal maven archive in repos.txt  (maven:http://bios.intranet.bosch.com:8080/archiva/repository/internal) 

and also pointed Vert.x to the local directory, where the yoke-1.0.4-mod.zip is also present, but to no effect.

I have started familiarizing myself with the sources of vertx-platform and try to identify the problem. Ultimatively I need to debug but I have no idea how to do this in eclipse. Can you give me an idea how to debug vertx-platform in eclipse? I know this is kind of a dummy question but I'd be more than willing to contribute to Vert.x and help solve the problem (if there is any) or at the very least share what I learned in solving the problem with the community.

Thanks in advance for your support, again.

[Tim Fox]

On 31/01/14 09:49, Georg Grütter wrote:

I have now tested the setup in the corporate network. Everything works fine as long as the module is in the VERTX_MODS directory. However, Vert.x is still is not able to download the module-zip from our company internal maven archive (no login, no proxy required) and install it there on its own. 

My understanding is that Vert.x uses the repos in repos.txt to search for and download it, rather than using the maven configuration, correct? I configured our company internal maven archive in repos.txt  (maven:http://bios.intranet.bosch.com:8080/archiva/repository/internal) 

and also pointed Vert.x to the local directory, where the yoke-1.0.4-mod.zip is also present, but to no effect.

Can you tell me the exact commands you are executing, and how (command line or in Eclipse)?

I have started familiarizing myself with the sources of vertx-platform and try to identify the problem. Ultimatively I need to debug but I have no idea how to do this in eclipse. Can you give me an idea how to debug vertx-platform in eclipse? I know this is kind of a dummy question but I'd be more than willing to contribute to Vert.x and help solve the problem (if there is any) or at the very least share what I learned in solving the problem with the community.

Thanks in advance for your support, again.

[Georg Grütter]

Can you tell me the exact commands you are executing, and how (command line or in Eclipse)?

This is what I do:

mvn clean vertx:runMod

This results in the same error I showed in my first comment. Here are the relevant lines from my repos.txt

mavenLocal:~/Workspaces/.m2
maven:http://bios.intranet.bosch.com:8080/archiva/repository/internal

Both local and remote maven repositories contain the file

yoke-1.0.4-mod.zip

I did check the code in MavenLocalRepoResolver.java and I can't see why it couldn't find the mod.zip file. My local repo does not contain the maven-metadata-local.xml or maven-metadata-remote.xml files so the code beginning in line 89 should pick up the file (unless the problem is related to the java.io.temp directory, which I doubt.

I know it's long, but here's the maven output for the sake of completeness:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)

Maven home: /opt/local/share/java/maven3

Java version: 1.7.0_25, vendor: Oracle Corporation

Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Default locale: de_DE, platform encoding: UTF-8

OS name: "mac os x", version: "10.9.1", arch: "x86_64", family: "mac"

[INFO] Error stacktraces are turned on.

[DEBUG] Reading global settings from /opt/local/share/java/maven3/conf/settings.xml

[DEBUG] Reading user settings from /Users/grg2fr/.m2/settings.xml

[DEBUG] Using local repository at /Users/grg2fr/Workspaces/.m2

[DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for /Users/grg2fr/Workspaces/.m2

[INFO] Scanning for projects...

[DEBUG] Extension realms for project eu.gruetter:vertxModulePoc:jar:1.0-SNAPSHOT: (none)

[DEBUG] Looking up lifecyle mappings for packaging jar from ClassRealm[plexus.core, parent: null]

[DEBUG] Resolving plugin prefix vertx from [org.apache.maven.plugins, org.codehaus.mojo]

[DEBUG] Resolved plugin prefix vertx to io.vertx:vertx-maven-plugin from POM eu.gruetter:vertxModulePoc:jar:1.0-SNAPSHOT

[DEBUG] === REACTOR BUILD PLAN ================================================

[DEBUG] Project: eu.gruetter:vertxModulePoc:jar:1.0-SNAPSHOT

[DEBUG] Tasks:   [vertx:runMod]

[DEBUG] Style:   Regular

[DEBUG] =======================================================================

[INFO]                                                                        

[INFO] ------------------------------------------------------------------------

[INFO] Building Project - vertxModulePoc 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[DEBUG] Resolving plugin prefix vertx from [org.apache.maven.plugins, org.codehaus.mojo]

[DEBUG] Resolved plugin prefix vertx to io.vertx:vertx-maven-plugin from POM eu.gruetter:vertxModulePoc:jar:1.0-SNAPSHOT

[DEBUG] Lifecycle default -> [validate, 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]

[DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]

[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]

[DEBUG] === PROJECT BUILD PLAN ================================================

[DEBUG] Project:       eu.gruetter:vertxModulePoc:1.0-SNAPSHOT

[DEBUG] Dependencies (collect): []

[DEBUG] Dependencies (resolve): [compile+runtime]

[DEBUG] Repositories (dependencies): [internal (http://bios.intranet.bosch.com:8080/archiva/repository/internal/, releases), snapshots (http://bios.intranet.bosch.com:8080/archiva/repository/snapshots/, snapshots), releases (http://localhost:8081/nexus/content/repositories/releases, releases), sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots, snapshots), central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/, releases)]

[DEBUG] Repositories (plugins)     : [central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/, releases)]

[DEBUG] -----------------------------------------------------------------------

[DEBUG] Goal:          io.vertx:vertx-maven-plugin:2.0.3-final:runMod (default-cli)

[DEBUG] Style:         Regular

[DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?>

<configuration>

  <instances default-value="1"/>

  <modsDir default-value="target/mods"/>

  <moduleName default-value="${project.groupId}~${project.artifactId}~${project.version}">${moduleName}</moduleName>

  <project default-value="${project}"/>

</configuration>

[DEBUG] =======================================================================

[DEBUG] Using mirror central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/) for central (http://repo.maven.apache.org/maven2).

...

DEBUG] Using mirror central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/) for central (http://repo.maven.apache.org/maven2).

[DEBUG] eu.gruetter:vertxModulePoc:jar:1.0-SNAPSHOT

[DEBUG]    io.vertx:vertx-core:jar:2.1M5:provided

[DEBUG]       org.slf4j:slf4j-api:jar:1.6.2:provided

[DEBUG]       com.fasterxml.jackson.core:jackson-databind:jar:2.2.2:provided

[DEBUG]          com.fasterxml.jackson.core:jackson-annotations:jar:2.2.2:provided

[DEBUG]       com.fasterxml.jackson.core:jackson-core:jar:2.2.2:provided

[DEBUG]       log4j:log4j:jar:1.2.16:provided

[DEBUG]       io.netty:netty-all:jar:4.0.14.Final:provided

[DEBUG]    io.vertx:vertx-platform:jar:2.1M5:provided

[DEBUG]    io.vertx:vertx-hazelcast:jar:2.1M5:provided

[DEBUG]       com.hazelcast:hazelcast:jar:2.6.6:provided

[DEBUG]    junit:junit:jar:4.11:test

[DEBUG]       org.hamcrest:hamcrest-core:jar:1.3:test

[DEBUG]    io.vertx:testtools:jar:2.0.3-final:test

[DEBUG]       org.apache.directory.server:apacheds-protocol-dns:jar:1.5.7:test

[DEBUG]          org.apache.directory.server:apacheds-i18n:jar:1.5.7:test

[DEBUG]          org.apache.directory.server:apacheds-core-jndi:jar:1.5.7:test

[DEBUG]             org.apache.directory.server:apacheds-core:jar:1.5.7:test

[DEBUG]                org.apache.directory.server:apacheds-core-api:jar:1.5.7:test

[DEBUG]                   org.apache.directory.server:apacheds-core-entry:jar:1.5.7:test

[DEBUG]                   org.apache.directory.server:apacheds-core-constants:jar:1.5.7:test

[DEBUG]                org.apache.directory.server:apacheds-utils:jar:1.5.7:test

[DEBUG]                bouncycastle:bcprov-jdk15:jar:140:test

[DEBUG]          org.apache.directory.server:apacheds-protocol-shared:jar:1.5.7:test

[DEBUG]             org.apache.mina:mina-core:jar:2.0.0-RC1:test

[DEBUG]          org.apache.directory.shared:shared-ldap:jar:0.9.19:test

[DEBUG]             commons-lang:commons-lang:jar:2.4:test

[DEBUG]             commons-collections:commons-collections:jar:3.2.1:test

[DEBUG]             org.apache.directory.shared:shared-i18n:jar:0.9.19:test

[DEBUG]             antlr:antlr:jar:2.7.7:test

[DEBUG]          org.apache.directory.shared:shared-ldap-schema:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-schema-loader:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-schema-manager:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-cursor:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-jndi:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-asn1-codec:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-asn1:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-constants:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-converter:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldap-schema-dao:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-ldif:jar:0.9.19:test

[DEBUG]          org.apache.directory.shared:shared-dsml-parser:jar:0.9.19:test

[DEBUG]             dom4j:dom4j:jar:1.6.1:test

[DEBUG]                xml-apis:xml-apis:jar:1.0.b2:test

[DEBUG]             xpp3:xpp3:jar:1.1.4c:test

[DEBUG]    com.jetdrone:yoke:jar:1.0.4:provided

[INFO]

[INFO] --- vertx-maven-plugin:2.0.3-final:runMod (default-cli) @ vertxModulePoc ---

[DEBUG] Created new class realm maven.api

[DEBUG] Importing foreign packages into class realm maven.api

[DEBUG]   Imported: org.apache.maven.wagon.events < plexus.core

[DEBUG]   Imported: org.sonatype.aether.transfer < plexus.core

[DEBUG]   Imported: org.apache.maven.exception < plexus.core

[DEBUG]   Imported: org.sonatype.aether.metadata < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.util.xml.Xpp3Dom < plexus.core

[DEBUG]   Imported: org.sonatype.aether.collection < plexus.core

[DEBUG]   Imported: org.sonatype.aether.version < plexus.core

[DEBUG]   Imported: org.apache.maven.monitor < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.repository < plexus.core

[DEBUG]   Imported: org.apache.maven.repository < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.resource < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.logging < plexus.core

[DEBUG]   Imported: org.apache.maven.profiles < plexus.core

[DEBUG]   Imported: org.sonatype.aether.repository < plexus.core

[DEBUG]   Imported: org.apache.maven.classrealm < plexus.core

[DEBUG]   Imported: org.apache.maven.execution < plexus.core

[DEBUG]   Imported: org.sonatype.aether.artifact < plexus.core

[DEBUG]   Imported: org.sonatype.aether.spi < plexus.core

[DEBUG]   Imported: org.apache.maven.reporting < plexus.core

[DEBUG]   Imported: org.apache.maven.usability < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.container < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.component < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlSerializer < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.authentication < plexus.core

[DEBUG]   Imported: org.apache.maven.lifecycle < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.classworlds < plexus.core

[DEBUG]   Imported: org.sonatype.aether.graph < plexus.core

[DEBUG]   Imported: org.sonatype.aether.* < plexus.core

[DEBUG]   Imported: org.apache.maven.settings < plexus.core

[DEBUG]   Imported: org.codehaus.classworlds < plexus.core

[DEBUG]   Imported: org.sonatype.aether.impl < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.* < plexus.core

[DEBUG]   Imported: org.apache.maven.toolchain < plexus.core

[DEBUG]   Imported: org.sonatype.aether.deployment < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.observers < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlPullParserException < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlPullParser < plexus.core

[DEBUG]   Imported: org.apache.maven.configuration < plexus.core

[DEBUG]   Imported: org.apache.maven.cli < plexus.core

[DEBUG]   Imported: org.sonatype.aether.installation < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.context < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.authorization < plexus.core

[DEBUG]   Imported: org.apache.maven.project < plexus.core

[DEBUG]   Imported: org.apache.maven.rtinfo < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.lifecycle < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.configuration < plexus.core

[DEBUG]   Imported: org.apache.maven.artifact < plexus.core

[DEBUG]   Imported: org.apache.maven.model < plexus.core

[DEBUG]   Imported: org.apache.maven.* < plexus.core

[DEBUG]   Imported: org.apache.maven.wagon.proxy < plexus.core

[DEBUG]   Imported: org.sonatype.aether.resolution < plexus.core

[DEBUG]   Imported: org.apache.maven.plugin < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.* < plexus.core

[DEBUG]   Imported: org.codehaus.plexus.personality < plexus.core

[DEBUG] Populating class realm maven.api

[DEBUG] Using mirror central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/) for central (http://repo.maven.apache.org/maven2).

...

[DEBUG] Using mirror central-proxy (http://bios.intranet.bosch.com:8080/archiva/repository/internal/) for central (http://repo.maven.apache.org/maven2).

[DEBUG] io.vertx:vertx-maven-plugin:jar:2.0.3-final:

[DEBUG]    io.vertx:vertx-platform:jar:2.1M5:runtime

[DEBUG]    io.vertx:vertx-core:jar:2.1M5:runtime

[DEBUG]       com.fasterxml.jackson.core:jackson-databind:jar:2.2.2:runtime

[DEBUG]          com.fasterxml.jackson.core:jackson-annotations:jar:2.2.2:runtime

[DEBUG]       com.fasterxml.jackson.core:jackson-core:jar:2.2.2:runtime

[DEBUG]       log4j:log4j:jar:1.2.16:runtime

[DEBUG]       io.netty:netty-all:jar:4.0.14.Final:runtime

[DEBUG]    io.vertx:vertx-hazelcast:jar:2.1M5:runtime

[DEBUG]       com.hazelcast:hazelcast:jar:2.6.6:runtime

[DEBUG]    org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.2:compile

[DEBUG]       org.apache.maven:maven-model:jar:2.2.1:compile

[DEBUG]       org.apache.maven:maven-plugin-api:jar:2.2.1:compile

[DEBUG]       org.apache.maven:maven-artifact:jar:2.2.1:compile

[DEBUG]       org.apache.maven:maven-plugin-descriptor:jar:2.2.1:compile

[DEBUG]       org.codehaus.plexus:plexus-utils:jar:3.0:compile

[DEBUG]       org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile

[DEBUG]          junit:junit:jar:3.8.1:compile

[DEBUG]          classworlds:classworlds:jar:1.1-alpha-2:compile

[DEBUG]    org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.2:compile

[DEBUG]       org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.2:compile

[DEBUG]       org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:compile

[DEBUG]       asm:asm:jar:3.3.1:compile

[DEBUG]       asm:asm-commons:jar:3.3.1:compile

[DEBUG]          asm:asm-tree:jar:3.3.1:compile

[DEBUG]       org.codehaus.plexus:plexus-archiver:jar:2.1.1:compile

[DEBUG]          org.codehaus.plexus:plexus-io:jar:2.0.3:compile

[DEBUG]       com.thoughtworks.qdox:qdox:jar:1.12.1:compile

[DEBUG]    org.apache.maven:maven-project:jar:2.0.6:compile

[DEBUG]       org.apache.maven:maven-settings:jar:2.0.6:compile

[DEBUG]       org.apache.maven:maven-profile:jar:2.0.6:compile

[DEBUG]       org.apache.maven:maven-artifact-manager:jar:2.0.6:compile

[DEBUG]          org.apache.maven:maven-repository-metadata:jar:2.0.6:compile

[DEBUG]       org.apache.maven:maven-plugin-registry:jar:2.0.6:compile

[DEBUG]    org.slf4j:slf4j-api:jar:1.7.2:compile

[DEBUG] Created new class realm plugin>io.vertx:vertx-maven-plugin:2.0.3-final

[DEBUG] Importing foreign packages into class realm plugin>io.vertx:vertx-maven-plugin:2.0.3-final

[DEBUG]   Imported:  < maven.api

[DEBUG] Populating class realm plugin>io.vertx:vertx-maven-plugin:2.0.3-final

[DEBUG]   Included: io.vertx:vertx-maven-plugin:jar:2.0.3-final

[DEBUG]   Included: io.vertx:vertx-platform:jar:2.1M5

[DEBUG]   Included: io.vertx:vertx-core:jar:2.1M5

[DEBUG]   Included: com.fasterxml.jackson.core:jackson-databind:jar:2.2.2

[DEBUG]   Included: com.fasterxml.jackson.core:jackson-annotations:jar:2.2.2

[DEBUG]   Included: com.fasterxml.jackson.core:jackson-core:jar:2.2.2

[DEBUG]   Included: log4j:log4j:jar:1.2.16

[DEBUG]   Included: io.netty:netty-all:jar:4.0.14.Final

[DEBUG]   Included: io.vertx:vertx-hazelcast:jar:2.1M5

[DEBUG]   Included: com.hazelcast:hazelcast:jar:2.6.6

[DEBUG]   Included: org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.2

[DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0

[DEBUG]   Included: junit:junit:jar:3.8.1

[DEBUG]   Included: org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.2

[DEBUG]   Included: org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.2

[DEBUG]   Included: org.codehaus.plexus:plexus-component-annotations:jar:1.5.5

[DEBUG]   Included: asm:asm:jar:3.3.1

[DEBUG]   Included: asm:asm-commons:jar:3.3.1

[DEBUG]   Included: asm:asm-tree:jar:3.3.1

[DEBUG]   Included: org.codehaus.plexus:plexus-archiver:jar:2.1.1

[DEBUG]   Included: org.codehaus.plexus:plexus-io:jar:2.0.3

[DEBUG]   Included: com.thoughtworks.qdox:qdox:jar:1.12.1

[DEBUG]   Included: org.slf4j:slf4j-api:jar:1.7.2

[DEBUG]   Excluded: org.apache.maven:maven-model:jar:2.2.1

[DEBUG]   Excluded: org.apache.maven:maven-plugin-api:jar:2.2.1

[DEBUG]   Excluded: org.apache.maven:maven-artifact:jar:2.2.1

[DEBUG]   Excluded: org.apache.maven:maven-plugin-descriptor:jar:2.2.1

[DEBUG]   Excluded: org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1

[DEBUG]   Excluded: classworlds:classworlds:jar:1.1-alpha-2

[DEBUG]   Excluded: org.apache.maven:maven-project:jar:2.0.6

[DEBUG]   Excluded: org.apache.maven:maven-settings:jar:2.0.6

[DEBUG]   Excluded: org.apache.maven:maven-profile:jar:2.0.6

[DEBUG]   Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.6

[DEBUG]   Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.6

[DEBUG]   Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.6

[DEBUG] Configuring mojo io.vertx:vertx-maven-plugin:2.0.3-final:runMod from plugin realm ClassRealm[plugin>io.vertx:vertx-maven-plugin:2.0.3-final, parent: sun.misc.Launcher$AppClassLoader@52d18636]

[DEBUG] Configuring mojo 'io.vertx:vertx-maven-plugin:2.0.3-final:runMod' with basic configurator -->

[DEBUG]   (f) instances = 1

[DEBUG]   (f) modsDir = /Users/grg2fr/Workspaces/vertx/vertxModulePoc/target/mods

[DEBUG]   (f) moduleName = eu.gruetter~vertxModulePoc~1.0-SNAPSHOT

[DEBUG]   (f) project = MavenProject: eu.gruetter:vertxModulePoc:1.0-SNAPSHOT @ /Users/grg2fr/Workspaces/vertx/vertxModulePoc/pom.xml

[DEBUG] -- end configuration --

[ERROR]

org.vertx.java.platform.PlatformManagerException: Module com.jetdrone~yoke~1.0.4 not found in any repositories

        at org.vertx.java.platform.impl.DefaultPlatformManager.getModule(DefaultPlatformManager.java:1399)

        at org.vertx.java.platform.impl.DefaultPlatformManager.doInstallMod(DefaultPlatformManager.java:1388)

        at org.vertx.java.platform.impl.DefaultPlatformManager.doLoadIncludedModules(DefaultPlatformManager.java:1259)

        at org.vertx.java.platform.impl.DefaultPlatformManager.loadIncludedModules(DefaultPlatformManager.java:1242)

        at org.vertx.java.platform.impl.DefaultPlatformManager.deployModuleFromModJson(DefaultPlatformManager.java:1063)

        at org.vertx.java.platform.impl.DefaultPlatformManager.deployModuleFromFileSystem(DefaultPlatformManager.java:1201)

        at org.vertx.java.platform.impl.DefaultPlatformManager.access$1300(DefaultPlatformManager.java:56)

        at org.vertx.java.platform.impl.DefaultPlatformManager$12.run(DefaultPlatformManager.java:444)

        at org.vertx.java.platform.impl.DefaultPlatformManager$14.run(DefaultPlatformManager.java:469)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

        at java.lang.Thread.run(Thread.java:724)

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1.995s

[INFO] Finished at: Fri Jan 31 11:41:40 CET 2014

[INFO] Final Memory: 7M/18M

[INFO] ------------------------------------------------------------------------

[Tim Fox]

Where is the repos.txt you are editing?

[Georg Grütter]

its in the conf directory of my local vertx installation

/usr/local/vert.x/conf/repos.txt

Do I need to set a VERTX_HOME or something like that?

[Tim Fox]

When you use Maven to do stuff it does not use the vert.x distribution that you have installed. After all, Maven builds are supposed to be self contained and reproduceable so Maven will download and install any dependencies that your build uses (including the Vert.x jars) before launching the plugin that runs the module.

I.e. you can do:

git clone
mvn vertx:runMod

on any Maven Vert.x project without having to have Vert.x pre-installed.

So it won't be using the repos.txt that you have in your Vert.x installation.

If you want to provide a custom repos.txt you can add it in the src/main/platform_lib directory of your project. If you've created your project from the archetype you should already have such an directory with just a README in it

[Georg Grütter]

Good catch, Tim! That was indeed the problem.  The module zip is now picked up by vertx both locally and in our corporate maven repository and then stored in the local VERTX_MODS directory. 

Thanks a bunch for the tip and the explanation.

Cheers,

Georg