You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Christofer Dutz <ch...@c-ware.de> on 2018/01/28 11:52:14 UTC
Skip deploy of test-jars?
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
Re: Skip deploy of test-jars?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <rf...@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
<ch...@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"
> <ch...@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" <rf...@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
> <ch...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Skip deploy of test-jars?
Posted by Robert Scholte <rf...@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
<ch...@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"
> <ch...@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" <rf...@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
> <ch...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Skip deploy of test-jars?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@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" <rf...@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
<ch...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Skip deploy of test-jars?
Posted by Christofer Dutz <ch...@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" <rf...@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
<ch...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Skip deploy of test-jars?
Posted by Robert Scholte <rf...@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
<ch...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Skip deploy of test-jars?
Posted by Anders Hammar <an...@hammar.net>.
I can't think of a clean Maven (configuration) way to do this.
/Anders
On Sun, Jan 28, 2018 at 12:52 PM, Christofer Dutz <christofer.dutz@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
>