You can probably use maven-dependency-plugin and maven-assembly-plugin to form a coherent whole:
https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html https://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html On Fri, 17 Apr 2020 at 17:02, Geoffrey Blake <geoffrey.w.bl...@gmail.com> wrote: > > > 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 > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
