I got distracted and wanted to know why you might be thinking of doing
the cross-compiling path, $mvn release:prepare will always clean the
target/ directory and rebuild. We don't want that to cobble together
artifacts from different build sources, which ultimately would
probably want to happen via Travis. It is apparently really difficult
to get maven to skip cleaning in this case, passing
-Dmaven.clean.skip=true is ignored by the release plugin. The only
way so far I've found so far is to code this into the build section:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Then we can put outside artifacts into the target folder and maven
will package it into a Jar for us. There has got to be a configurable
way to do this as a work-around. Any Maven experts out there?
-Geoff
On Wed, Apr 15, 2020 at 8:19 PM Gary Gregory <garydgreg...@gmail.com> wrote:
>
> On Wed, Apr 15, 2020 at 5:46 PM Geoffrey Blake <geoffrey.w.bl...@gmail.com>
> wrote:
>
> > So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
> > all the tests pass. The code coverage bumps to 72%, I'm guessing if I
> > did Mac we'd see the 73% coverage seen from Travis CI.
> >
> > @Gary, what should a reasonable coverage target be? 73% is not great,
> > but not sure how much higher this can get with many code paths that
> > may be unreachable from unit-testing from what I'm seeing (private
> > constructors, private overridden methods that are not used, static
> > classes etc). There are some functions that can be added, but is it
> > worth it right now for getting a new release?
> >
>
> Hi Geoff,
>
> I do not have a number to give you but as you point out 73% is not great.
> Any improvement is welcome.
>
> It looks that me doing a release is going to be a lot more tricky than I
> initially thought due to getting cross-compiling to work instead of hacking
> together a build from other builds on different environments. This means
> that you have more time to increase the coverage ;-)
>
> Keep in mind that the code coverage improvement buys us two kinds of wins:
>
> 1) We get to prove and document through tests the expected behavior, and,
> more importantly IMO,
> 2) We provide a better and sounder foundation for future changes, allowing
> developers to make changes with less worry of introducing regression bugs.
>
> Cheers,
> Gary
>
>
> >
> > Still, I've seen this error pop up in Travis multiple times now for the
> > repo:
> >
> > 3040[ERROR]
> > testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest)
> > Time elapsed: 0.019 s <<< ERROR!
> > 3041java.lang.Exception: Unexpected exception,
> > expected<javax.crypto.AEADBadTagException> but
> > was<java.lang.InternalError>
> > 3042 at
> > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224)
> >
> > Is that an error in commons-crypto, or something up with the Travis CI
> > env? I haven't seen it on my dev environments.
> >
> > -Geoff
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
