Hi Robert, thanks for that ... Option 3 was actually the one I was thinking of too but I was hoping that there already had been such a plugin or feature. I whipped up a little plugin that we'll have in our code repo and guess we'll release it once and then probably forget it's there ;-)
But it's working like a charm and I too think this is the easiest and cleanest way to go. Thanks for your support. Chris Am 30.01.18, 21:02 schrieb "Robert Scholte" <rfscho...@apache.org>: 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