On 26/08/13 22:16, Rob Vesse wrote:
My intention was to get Jena JDBC in this release.
For clarity:
Does "in this release" mean:
1/ maven artifacts available
2/ 1+in the lib/ of apache-jena-VER.zip/.tar.gz
3/ something else
I was expecting (1) but have no strong advocacy other than a general
feeling that a user using the non-maven bianry is unlikely to be wanting
JDBC and maybe thinking its required. YMMV.
We can have things in the build that do not end up in apache-jena-VER.zip.
For example, jena-sdb is in the main build but only produces maven
artifacts (as of the next release, we delete the independent binary
distribution).
Separately (although some connection?), there is what goes on
apache-jena-libs.
The what's being distributed thing with the whole Apache L&N stuff is
always an incomprehensible minefield IMO. Yes we are not distributing the
source or even the binary but an end user requires AspectJ in order to
compile the source which we release (which is done automatically via
maven).
Moving minefield as well.
If the dependency is compile time only then are the L&N entries actually
unnecessary?
As I understand it, no, they are not absolutely required.
This is based on the text:
[[ http://eclipse.org/aspectj/doc/released/faq.php#q:license
Most users only want to use AspectJ to build programs they distribute.
There are no restrictions here. When you distribute your program, be
sure to include all the runtime classes from the aspectjrt.jar for that
version of AspectJ. When distributing only the runtime classes, you need
not provide any notice that the program was compiled with AspectJ or
includes binaries from the AspectJ project, except as necessary to
preserve the warranty disclaimers in our license.
]]
and we (subject to clarification above) are not distributing, binary or
source.
AspectJ does seem to be one of the more complicated cases because it
messes around with the compilation step. We can confirm by emailing
legal@ if you want.
Andy
