Closed jumarko closed 11 years ago
Nice addition Juraj, thanks!
Do you have any idea why the Travis CI build has failed for this PR?
It seems to that travis maven repo (nexus) fails to respond with proper artifact (maven-failsafe plugin 2.12.4). Maybe it was just a temporary failure...
ok to test.
Travis build is ok now, so let me know if you have any further concerns.
Juraj, I've temporarily reverted the changes to the changelog and readme just to make sure that no-one gets confused. I'll add your changes back in when 0.1.8 is released.
Ok, thanks!
Juraj, could you explain to me a little about this implementation?
Do you have tests which have a dependency on this plugin to use the PortHelper#getMongoPort
method? or maybe you have written your own plugin that has a dependency on this plugin?
IMO PortHelper#getMongoPort
is really a rather strange thing for this plugin to provide. I'd prefer to remove this method from the plugin and have you add it to whatever project uses it instead. The outbound interface of a Maven plugin is the context objects like PluginContext, MavenSession, UserProperties etc and through these it should communicate to other code, its highly irregular to import a plugin and use helpers from it wouldn't you agree?
I'm wondering, would it not be a lot easier to simply add the randomly generated port number to the project properties? Then configuration for other plugins (including the failsafe plugin) can easily reference the property.
So after generating the random port, we simply set the project property:
project.getProperties().put("embedmongo.port." + artifactId, port)
then other plugins defined in the pom can take advantage of this property like:
${embedmongo.port.myArtifact}
You can even pass this on as a system property to a JVM forked by the failsafe plugin by using:
<configuration>
<systemPropertyVariables>
<mongo.port>${embedmongo.port.myArtifact}</mongo.port>
...
I'm just thinking aloud here so please do shout if you think any of the above is incorrect.
I'd have to try it, but I think it might even be possible to remove the artifactId
suffix if we use this method.
Try building a snapshot from this branch to try this:
https://github.com/joelittlejohn/embedmongo-maven-plugin/tree/random-port
Hi,
thanks for questions.
Right now, I have a direct (scope test) dependency on plugin in my POM. This way I can call PortHelper#getMongoPort
. The reason why I add PortHelper to the plugin code base is that I wanted to avoid the reimplementation of this method in each client.
As regards to storing allocated port to the project properties instead of system property I'll definitely give it a try as soon as possible - hopefully on this Wednesday.
Wow, it seems to work seamlessly, even with parallel builds.
One little note - you have broken test MongoIT (which ca be run via mvn clean verify -f src/test/resources/randomport/pom.xml)
.
To fix it simply replace PortHelper#getMongoPort
with
int mongoPort = Integer.valueOf(System.getProperty("mongo.port"));
and configure failsafe plugin in associated pom.xml.
Thanks for cleaning of my solution!
And also, please, fix javadoc: https://github.com/joelittlejohn/embedmongo-maven-plugin/compare/random-port#L1R238 MavenSession is not used anymore and should be removed from imports too.
Thanks for giving this a test Juraj. Yes, I'll definitely do some more tidying up of the code - I just wanted to get some raw changes out to see if this idea was viable.
I'll make some updates tonight and cut a new release.
This way we are able to perform concurrent builds on single machine. Allocated port is set to the system property "embedmongo.port." where is artifactId of current (tested) maven module.
Note: I'm not sure if proposed MongoIT and related "testing" module in src/test/resources/randomport is the bost approach for integration testing but I've tried to follow the other examples.