> pivot-charts will therefor not be allowed to be released from Apache. > Sorry. The release will not be approved with it.
Bummer :-( > I think you have 3 options; > > 1. Rebuild the same functionality using a library that has a > permissible license. > > 2. Stick that component at SourceForge or similar. > > 3. Create an SPI in Pivot, to which one can plug in an underlying > implementation. You will need a bit of 'bridge code', which you stick > in SF. Charts have been Greg's domain - Greg, thoughts? > Yeah, it is a big topic, and understanding the many nuances can be quite a > ride. So like you said: let's take our dependencies one by one. Here are the ones I can think of now: * servlet-api.jar: We build against this to produce pivot-web.server.jar, which contains our server portion of our "web queries" API. Specifically, it contains a few servlets, which require that J2EE jar to build. * junit.jar We've written a few JUnit unit tests in the core-test package, and we plan to write more in other packages. This jar allows us to build our tests, which end up as pivot-core.test.jar, etc. The resulting jars are not part of our API - just our test cases. JUnit is licensed under the "common public license": http://junit.sourceforge.net/cpl-v10.html * plugin.jar This jar is part of Sun's JRE (but doesn't live in the CLASSPATH by default) and allows us to build against the LiveConnect API (netscape.javascript.*). We use this in pivot-wtk.jar to provide our component-DOM interaction API. * stax-api.jar We build pivot-wtk.jar against this to provide our WTKXSerializer (which translates our XML bean representation into objects). It's homepage is http://stax.codehaus.org/, and it looks like it's Apache 2.0, so we should be good. >> Some context might help shed some light on why this continues to be an >> issue. We build "pivot-foo.jar" internally for day to day builds and >> wiki deployment, and only "pivot-foo-incubating.jar" as part of the >> "dist" target, which creates a lot more than just the jars. And as >> per our vote a few days back, version doesn't appear anywhere in the >> jar files. > > Ok, but I still think that is a mistake. I have too many times come > across work in companies using, let's say, struts.jar and having no > clue what version it is, or even if it is an official build or > modified in-house. Short-term small gain, over long-term serious > problems. You're preaching to the choir here - I voted in favor of versioned jars :)
