To move it to trunk, use "svn mv" and edit the top level build POM. Let
dev@ know. We can finetune the build due to this (and the other
changes) when "in trunk".
Switching on and off is as simple as commenting in or out the <module>
entry (as as jena-jdbc current does).
Minor comment:
In NOTICE
"Apache Jena" -> "Apache Jena - Security module"
(a better than than "security" if you prefer)
just to be clear what it refers to this module.
Andy
On 25/08/13 21:11, Claude Warren wrote:
Andy,
Is there a recommended process for moving from experimental to trunk?
I think the pom is ready,-- other than changing the version number to match
the Jena version and setting the relaive parent path in the pom .
Claude
On Sat, Aug 24, 2013 at 4:42 PM, Andy Seaborne <[email protected]> wrote:
On 24/08/13 15:03, Claude Warren wrote:
I would like to include jena-security in the distribution as it is
sensitive to the Jena version. Adding it to the trunk would be my
objective. If there are no issues I would like to do that for the 2.11
release. What legals need to be done? Technically (besides adding the
code to the trunk as opposed to experimental) what needs to be done?
I will modify the pom to depend on apache-jena-libs.
Claude
Sounds good. Let's aim to add to trunk if everyone is happy with that.
The legal issues come from dependencies that jena-security uses. If it's
only built to maven then things are easier because we, the Jena project, as
not shipping other project's binaries.
There should be a NOTICE and LICENSE in the module for people who checkout
just that module.
The jar files should also have a NOTICE and LICENSE in META-INF.
The build we have will automatically put NOTICE and LICENSE from the
top-level directory of the module into the jar, so having module-level
NOTICE and LICENSE serves two purposes.
jena-arq's is a good starting place as they are quite simple - just
referring to copyrights from pre-ASF.
If additional dependencies are from an Apache project, that means looking
in that project's NOTICE and LICENSE files. If we, jena, are not shipping
a dependency as a binary, (i.e. the build is only to maven) then it's
unlikely that we need to change anything.
Currently, the two things that are complicated for us are the binary
distribution and Fuseki. Both reship dependencies and both have their own
NOTICE/LICENSE which is different to the usual source.
For example, Fuseki is the most complicated because the server jar is an
uber-jar so even in maven form, it's shipping every Jena dependency.
Fuseki now uses the shade plugin to build the combined jar with License
and Notice helpers added. The helpers put in combined NOTICE and LICENSE
if required. As this is the first release using the shade plugin, this
needs checking.
The apache-jena distribution includes special NOTICE and LICENSE for all
the included dependencies and these are added to the assembled files.
NOTICE is supposed to be short and minimal. However, they also must be
the rolled up NOTICE from all reship binaries ... and not everyone's NOTICE
is short. Styles have changed over the years; there are principles for what
to put in but it's not formulaic.
Andy
