> So, let's start; What is JFree and how is it used? The JFree jars (jfreechart and jcommon) constitute a Java2D charting library. Our "pivot-charts-1.1-incubating.jar" is built against them and provides a Pivot charting component that allows you to present a JFree chart within the Pivot component hierarchy. Thus, our charting package is designed around the JFree API and won't build without the JFree jar files.
Tomorrow morning (I'm heading to bed now), I'll read up on category A, category B, category X, and System Requirements, and if those terms are official Apache classifications so I can be better educated in this area. > NOTICE contains a single paragraph about each source and binary > dependency used in the project, and where that dependency originate > from. It would also contain the VMware Copyright notice, and any other > individual's work that has been forked. So, license, origin, copyright > holder and year (if available) in one paragraph, followed by a blank > line. Ok. Does this include binary dependencies that are not included in the release artifact but are described in BUILD? (for instance, what if we decide *not* to include the JFree jars in our tarball - do we still include a paragraph in NOTICE for JFree?) > What surprises me is that you are struggling a lot with this. Isn't > just "version" a property in the Ant file at the top, which would be > appended to filenames? 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. > For this release, I will not make a fuzz over it, and I will try to > help out 'hands on' with the Ant script later. I'm not struggling with it technically - I just didn't want to re-arrange the build file if I didn't have to. It's obviously an issue, so I'll fix it :) > Is 5. and 6. same question? Yes - I should proof-read my emails before hitting send :) > Well, I guess it is a balance. I am of the opinion that 2 separate > tarballs is preferred, but that could be due to my slow connection to > the Internet. If you have a single tarball, then the most important > bit is that it can be built to the same state as the in-house built > one. The way it's structured right now, it's a single tarball, and within that tarball is a src directory from which you can produce the same tarball. I prefer the single tarball approach, but if I might be alone in that preference, perhaps I should put this to a vote on this list.
