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" <[email protected]>: 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
