On Fri, Jul 8, 2016 at 10:56 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul <bindulbhow...@gmail.com> > wrote: >> One option could be to go the Eclipse way, the way they handle SWT >> distributions which have native components[1]. >> > Yeah, that seems like a more normal way to go.
It's fine to break down native libraries into separate artifacts, as long as there's no restriction around which native libraries can be included in an application. i.e. you'd have a single artifact for the java code, and one each for each native library. That's needed to support applications that need to run on heterogeneous environments; imagine a distributed app where the launcher is on Windows or MacOS but workers are running on Linux. You still want people to be able to build the application once and deploy it, instead of having to build it for every separate target OS and figure out at runtime which version to run. (All this is a long winded way to say: I wouldn't use those profiles when building applications using crypto. Instead, I'd package all native libraries I think are useful for my application, and rely on the code to figure out which one to use at runtime.) -- Marcelo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
