of the 2 option 1 is the cleanest: at least you don't make don't go
outside of you project like you do with option 2. But it comes with too
much overhead.
I would go for option 3: write a Maven plugin:
use MavenSession.getProjects() to find the specific instance(s) from which
you want to copy the sources.
AFAIK there's no such plugin available yet.
thanks,
Robert
On Tue, 30 Jan 2018 09:12:01 +0100, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
Regarding the number of kittens being hurt in both ways ... which one
would you guys see the one with more happy kittens?
1) Use the test-jar and unpack it
2) Copy classes from a location outside the module (but relative to the
current module)
Chris
Am 29.01.18, 22:41 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Robert,
Well in that case I would copy resources from one module to another
using relative paths which point outside the module itself.
That doesn't sound ideal either. At least I always try to avoid
accessing things this way cause I have burnt myself too often when doing
it.
With the "test-jar unpacking" one module only consumes maven
artifacts another project created.
Chris
Am 29.01.18, 18:47 schrieb "Robert Scholte" <rfscho...@apache.org>:
This makes me wonder: is the pack/unpack already hackish?
Wouldn't it be nicer to simply copy the content from
target/classes +
target/test-classes?
With a Maven plugin is it quite simple to access this as part of
the
reactor.
thanks,
Robert
On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
> Hi all,
>
> in the Apache Edgent (incubating) project we are producing
java 8 and
> java 7 compatible jars by using the retrolambda-maven-plugin.
The Java 7
> versions are just a convenience byproduct for us. In order to
do this,
> we create the jar as well as the test-jars for each module and
hava
> separate java 7 modules where no code is compiled, but instead
in the
> compile phase we unpack the jar and in the compile-test phase
we unpack
> the test-jar of the matching Java 8 module. After unpacking the
> retrolambda plugin is executed and it generates the Java 7
versions.
> From then on the converted class files are used to run the
tests and
> create the java 7 jars.
>
> A little inconvenience of this approach is, that all test-jars
are also
> published to nexus. We do need them to be installed in the
local repo,
> but there is generally no point in deploying them to
Maven-Central.
> While I have no big deals with this, some in the project would
like to
> remove those test-jars from deployment.
>
> Is there any way to do this by usual configuration? Right now
we are
> thinking of using the Nexus REST interface to programmatically
strip
> them form the staging repo prior to closing it, but this all
feels like
> a huge hack.
>
> Do you have any advice how to do this or some good reasons not
to do it?
>
> Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
