Hi Mark,
I agree with you it would be better not to add the dependencies to compile
or test scope, but Eclipse does not understand and complains about compile
errors in build classes. I think it will be the same with any IDE. So for
now I think adding the dependencies to test scope is our best
If it were something structured I’d probably start with GMaven. I can write
Java in an IDE faster than ad-hoc Groovy so I really only thought of the
one-off cases and custom logic vis-a-vis the in-line plugins.
> On May 8, 2016, at 5:49 PM, Francois-Xavier Bonnet
> wrote:
On 9 May 2016, at 1:40, Hervé BOUTEMY wrote:
> Some little questions:
> 1. on https://javabuild.java.net/builder-maven-plugin/usage.html
> can the dependency on builder-api be test scope? (to avoid polluting the
> component dependencies with build requirements)
I was thinking including the
Romain, Jason,
I have already looked at polyglot maven and unless I missed something you
can execute some specific code but it has to be inside the pom. This should
be ok for simple cases but to do more complex things I find it more
convenient to be able to structure the code as classes in a
Hi Hervé,
You are right, builder-api dependency should definitely be in test scope. I
will get this fixed.
I am not very used to plugins integration tests. I will test your
suggestion. If it can work this way, a single multimodule project would
certainly make things more simple.
Thank you for
Le 8 mai 2016 20:47, "Jason van Zyl" a écrit :
>
> It has worked out of the box since 3.3.1 and the Maven Wrapper stuff. But
the fact is most users don’t really care, developers are looking at the
build all that often that it matters much. I think it’s pretty cool that it
works
It has worked out of the box since 3.3.1 and the Maven Wrapper stuff. But the
fact is most users don’t really care, developers are looking at the build all
that often that it matters much. I think it’s pretty cool that it works but in
the grand scheme of things most things should work with a
Well having it working ootb everywhere - including ideS - is a must and why
polyglot maven didnt get as must market as it should IMHO.
Also being able to order in the pom itself execution by reference would
solve a lot of headaches.
Le 8 mai 2016 17:04, "Jason van Zyl" a écrit :
There is also:
https://github.com/takari/polyglot-maven-examples/blob/master/groovy/pom.groovy
and the equivalent for ruby:
https://github.com/takari/polyglot-maven-examples/blob/master/ruby/hello/pom.rb
Both the Groovy and Ruby dialect allow inline of plugins.
Similar ideas but you might be
Hi all
I love that. Only missing thing to kill gradle in my use cases is a full
control on plugin order from the pom and not rely on easy to break
convention - a change in a parent can do today.
Le 8 mai 2016 15:40, "Hervé BOUTEMY" a écrit :
> Hi FX,
>
> Interesting for
Hi FX,
Interesting for people who don't want to write such code in Groovy, which
would be my initial bet on such scenario.
Some little questions:
1. on https://javabuild.java.net/builder-maven-plugin/usage.html
can the dependency on builder-api be test scope? (to avoid polluting the
component
Hi,
I wrote a Maven plugin that lets you execute java code directly from the
project and bind it to build cycle phases. I believe this can be helpful
when you want to do something specific in your project without having to
develop your own custom plugin (or before spending time packaging it as a
12 matches
Mail list logo