> Note that this build uses profiles and each binary is named for its target > platform.
Except the release artifact on Maven central contains all the shared libs in one jar in org/apache/commons/crypto/native/OS/ARCH. The makefile takes the artifact from targer/commons-crypto-<release>-<OS>-<ARCH> and places it in the targer/classes folder where it does the final packaging into the jar. At least that is how I'm reading the Makefile and observing Maven doing its work. The current behavior is that Maven cleans the target dir, so any artifacts we gather from elsewhere get omitted. I found that we can tweak the release plugin through the <preparationGoals> tag to not do a clean and maintain the artifacts. I'm readying a PR for that. I'm still attempting to increase code coverage, but its slow going. The Jna code paths are behind many layers of defensive coding that I'm manually trying to understand what extra tests if any can be written. Haven't gotten to the random part of the library yet. -Geoff On Thu, Apr 16, 2020 at 8:56 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > On Thu, Apr 16, 2020 at 5:57 PM Geoffrey Blake <geoffrey.w.bl...@gmail.com> > wrote: > > > 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? > > > > Note that this build uses profiles and each binary is named for its target > platform. > > Gary > > > > > > -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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
