Since the code is sensitive to changes in Graph, Model, and OpVisitor it probably makes sense to release on cycle with Jena core. I'll get the source code repackaged, I think most files have the header already.
Is there a tool that will look for missing Apache headers? Claude On Thu, Aug 1, 2013 at 4:09 PM, Andy Seaborne <[email protected]> wrote: > Claude, > > > > How do I go about contributing the code? > > You already have an iCLA on file so you can contribute code at any time > (provided it is yours to contribute! e.g. if your employer has any related > policy). > > Are there any new dependencies? > > If no, this is mostly about you want to get it out to users. > > Is this an additional module a user might wish to use? (not something to > hook deep into the standard distribution). > > I'm guessing it is, so the user adds "org.apache.jena:jena-**security" > (or whatever it gets called) to their POM to add it. > > The next decision is how you want to release it - coupled to the next > release or put out for discuss and feedback as a separate unit. (It can > migrate into the main build later.) > > Is this likely (in the short term) to evolve faster than the main Jena > release cycle? Evolve means formal releases, not snapshots. Given we seem > to be on ~3 months rather than the loosely stated ~6, faster is tricky! > > If aligning to the main release is the right approach, then a module under > trunk/ seems right. It will be built and deployed with a release; it will > not be in the apache-jena distribution or the related apache-jena-libs > (jena-text and jena-fuseki aren't either). > > If you want, for the moment, a separate release cycle then put in under > .../repos/asf/jena/**Experimental/ and announce it. > > Or, even if related to the main release cycle, you want a "first release" > that is more about getting feedback, then released separately might be > better. > > The quickest route is to put under Experimental/ and email users@. Build > to the snapshot repo and people can try it out immediately. Actually, > snapshot builds are an optional extra. People can build themselves if > necessary. As first steps, early feedback is better than polishing the > build process. > > However, there is one thing: > You must add the Apache header to all files. > > fastest route: > 1/ Align source code, > repackage to org.apache.jena.security > Add Apache header > 2/ Import to /Experimental/???? > 3/ Email users@ > 4/ Then consider formal release and aligning to jena main releases. > > Andy > > > On 01/08/13 07:37, Claude Warren wrote: > >> I would like to contribute the Xenei Jena Security project to the Apache >> Jena project (I assume as an experimental project). The code is currently >> at >> https://github.com/Claudenw/**JenaSecurity<https://github.com/Claudenw/JenaSecurity> >> . >> >> The project applies security access security (Create, Read, Update and >> Delete restrictions) on Graphs and Models. >> >> It does this by creating dynamic proxies to the Graph or Model >> implementations and intercepting calls that require modification. The >> architecture uses a interface that must be implemented by the developer >> using the package. This interface provides the security layer with the >> Principal of the current user, and determines if that user has specific >> access to specific graphs and/or triples. >> >> There are several thousand test cases. >> The Graph and Model implementations pass the Jena Graph and Model test >> suites. >> >> There is good javadoc coverage. >> >> There is some documentation. >> >> How do I go about contributing the code? >> >> Claude >> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
