Create MavenTool

[lordofthejars]

Hi, today I have been thinking about the project and I think it may be interesting to provide some kind of MavenTool. Basically I am a bit tired of having to use maven-dependency-plugin every time I want to run my tests in embedded Wildfly. The problem is that if you clean the target directory but you don't remember to rerun maven, Wildfly has been disappeared and tests run from the IDE simply don't work. For this reason I think we could create a MavenTool which we can set to download wilfly and do all the work required and we will be able to remove the dependency-plugin.

I can implement this tool if you think useful.

What you think?

[smiklosovic]

We have Maven tool in aerogear-testenv-plugin

https://github.com/aerogear/aerogear-testing-tools/blob/master/aerogear-test-env-plugin/src/main/groovy/org/jboss/aerogear/test/maven/MavenExecutor.groovy

It uses "mvn" tool which is constructed internally and not online but from the implementation point of view, all you need to do is to refactor MavenExecutor to get rid of aerogear-testenv-plugin stuff and you use CommandTool to wrap mvn executable and this is used in process method of MavenExecutor and you are done.

That command def on line 49 is nothing but CommandTool wrapper around mvn executable. That's it.

[smiklosovic]

This is list of all Spacelift tools we have in Aerogear testenv plugin which may come handy

https://github.com/aerogear/aerogear-testing-tools/tree/master/aerogear-test-env-plugin#spacelift-tools-and-task

[kpiwko]

Maven support is definitely something we should push into Spacelift. Thinking about that, we indeed need a tools package apart from api, spi and impl.

[lordofthejars]

Yes, I was thinking of using Maven not as a CLI tool but as used in Shrinkwrap resolver, where you set a coordinates and the dependency is downloaded.

2014-10-06 13:57 GMT+02:00 Karel Piwko notifications@github.com:

Maven support is definitely something we should push into Spacelift. Thinking about that, we indeed need a tools package apart from api, spi and impl.

— Reply to this email directly or view it on GitHub https://github.com/arquillian/arquillian-spacelift/issues/17#issuecomment-58006919 .

+----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+

[smiklosovic]

So why not to use ShrinkWrap resolver then? I just do not see any advantage of having standalone Spacelift task which has only the subset of ShrinkWrap capabilities. As a wrapper?

When you have Spacelift as a hammer, everything looks like a nail.

[lordofthejars]

I though the same, but we must decide if we want to tight Shrinkwrap dependency in Spacelift or not. I mean Spacelift can be used standalone, so using standalone will mean downloading Shrinkwrap dependencies as well. If it is ok then we can use without any problem for sure. I prefer to ask any technical decision before implement it. So we can use Maven embedded or on the other side we can use ShrinkWrap implementation.

2014-10-06 14:43 GMT+02:00 Štefan Miklošovič notifications@github.com:

So why not to use ShrinkWrap resolver then? I just do not see any advantage of having standalone Spacelift task which has only the subset of ShrinkWrap capabilities. As a wrapper?

When you have Spacelift as a hammer, everything looks like a nail.

— Reply to this email directly or view it on GitHub https://github.com/arquillian/arquillian-spacelift/issues/17#issuecomment-58011217 .

+----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+

[kpiwko]

My vision is to have core spacelift with as few dependencies as possible and additional package that brings most common tools you'll likely use.

We need to make sure that tool is still easy to be used - we don't want neither all in one nor one jar per tool approach.

It's a shame we don't have AMD in Java. Although in theory we have jboss-modules and different implementations that could do that :-)

[TadeasKriz]

The API is so extensible that you don't need this kind of module approach. I would suggest going in direction of multiple task packages. For example:

spacelift-io spacelift-common spacelift-networking

And so on. That way Spacelift users just put the dependency on classpath, no more setup required.

[kpiwko]

Idea: could spacelift be self-defining? E.g. spacelift-io will itself be an installation that provides tasks and tools - and for instance spacelift-common would be installed by default?

[TadeasKriz]

I'm not sure what you mean by self-defining. My idea was that each package would bring tasks and tools onto the classpath. Those tasks could then be run by the user however he like.

[kpiwko]

By self-defining I mean that Spacelift is using Spacelift itself to manage its dependencies. However, this would not help much as in Java classes are needed in CP for code completion. We would need a Maven plugin and it's IDE support or duplicate.

However, for gradle, that would be much easier, for instance pseudo DSL:

installations {
'spacelift-io'
'maven'
'eap'
}

will add task and tools from these installations to classpath, without need to specify them in dependencies.