It's not that I need the cryptography. Without studying the code it is hard to see which classes could be excised from the code to break the dependency. I briefly looked at deleting some of the crypto classes but then that rippled further into other classes requiring the classes I deleted. If I don't remove the entire class then I needed to comment out portions of the code at which point I have to read the code and make some decision about whether it will break other things which isn't sustainable. In the end I just want to generate non-encrypted Excel files.
By packaging everything as an OSGi bundle there are clear boundaries on what is in a plug-in and what the plug-in depends on. The approach of just compiling everything (tests, utilities, obscure dependencies) into a big jar and failing when you happen to hit code paths that require other libraries you haven't installed conflicts with this approach. On Thu, Sep 24, 2015 at 2:02 PM, Andreas Beeker <[email protected]> wrote: > On 24.09.2015 22:35, Patrick Bakker wrote: > > Yeah, I had those as dependencies. Then there are further dependencies > on 1 > > or more bouncycastle (https://www.bouncycastle.org/java.html) libraries > and > > some XML security stuff which I think is http://santuario.apache.org/. > The > > XML security libraries have their own series of dependencies which is > where > > I decided to stop. > > > > Do you need support for exotic cryptography (des3_112[1],various[2]) and > xml signatures in your OSGI bundle? > > I guess it's ok to skip those for most users. > > The reason for not referencing those dependency in our poms is of course > the cascading > heap of libraries, which you've mentioned. When I've implemented the > encryption classes > and adapted the xml signature stuff I've already tried to minimize the > dependencies, but > there's a point where you need to decide if you want to provide feature xy > or simply omit it. > > With encryption it was quite easy to make bouncycastle optional, but with > the xml signatures > you only find some sun.misc classes which you might copy&paste and would > end with a lot of > copyright infringements, so I preferred to use the official libs ... > > Andi > > [1] org.apache.poi.poifs.crypt.CipherAlgorithm > [2] org.apache.poi.poifs.crypt.HashAlgorithm > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Patrick Bakker *IT Manager* Van Belle Nursery | vanbelle.com <http://www.vanbelle.com/> T: 1-888-826-2355 | F: 604-853-6282 Find us on Facebook <http://facebook.com/vanbellenursery> • Twitter <http://twitter.com/vanbellenursery> • Google+ <http://gplus.to/vanbellenursery>
