Skip deploy of test-jars?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Skip deploy of test-jars?

Christofer Dutz
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
Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

Anders Hammar
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 <[hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

rfscholte
In reply to this post by Christofer Dutz
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  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

Christofer Dutz
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" <[hidden email]>:

    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  
    <[hidden email]> 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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

Christofer Dutz
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" <[hidden email]>:

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Skip deploy of test-jars?

Christofer Dutz
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" <[hidden email]>:

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]