Hello Bruce, I've just committed the sling-s3 module to the sling/contrib [1]. I also added new sling/contrib/extensions/oak-s3 module that gathers all dependencies required to run S3 on Oak.
On Thu, Mar 12, 2015 at 11:58 PM, Bruce Edge <bruce.e...@nextissuemedia.com> wrote: > > There's a few options here. > 1) If the Sling-S3 is as a contrib component, then I can depend on it > within the packaging module. Although I'm not sure exactly what the > cleanest way to pull it in is, as it's not a maven artifact and I really > just need the base templates & the ruby script. I suppose it could be > packaged as resources in a jar. That doesn't feel right though. > It doesn't have to be jar, we can wrap it in a Maven module producing tgz or zip assembly, but still - it's somehow strange. > Where you you see this in the sling tree? While it is an end to end > S3/mongo setup, it's more akin to a contrib module for crankstart as it > provides a quick start setup for crankstart. > Yep, I put it into the contrib. > 2) I could pull your scripts directly into the packaging module, but I > think this loses some flexibility. While it doesn't restrict anyone from > using it in a non-debian/ubuntu manner, it does make it a bit confusing if > it's all wrapped up with the debian bits. > I agree. Right now one can simply svn export the sling-s3 module and run it on any OS providing "make" command. > 3) Add the debian packaging folder under Sling-S3 (or whatever you end up > calling it). That way I can refer to the parent module for all the pieces > I need and it doesn¹t imply that one needs to build a .deb to use it. > Sounds good. > Regarding the actual packaging I'm thinking of putting the crank.*/ dirs > into /etc/sling/crank.*/ such that they are treated as config files such > that they are created if not present on initial installation, but then > remain untouched by update installations. > This lets the user modify these files as needed, while at the same time > retaining the ability to update the crank.d/*-sling-startlevel-*.txt > manually for existing installations. > Good idea. It'll mimic other Linux services using this convention and also it'll separate configuration from the code. > The building phase (install-deps & make target/*) would take place from > the package's postinst script, as it will have internet connectivity > during this phase. > Please notice that when you start Sling via Crankstart it'll probably also need an internet connection, as it'll try to download bundles present in the configuration but not in the local repo. The install-deps was responsible only for downloading and installing only a few SNAPSHOT dependencies from the SVN, but in the contributed version I removed it and configured crankstart to use snapshot Apache Maven repository [2]. Right now there is no way to force downloading all configured dependencies other than running Crankstart. We can think about some way to provide such feature, it'll require modyfing Crankstart or creating a new Java executable. > Lastly, /etc/default/sling will define the storage mode for sling, unset > (default to tar), s3, mongo, or s3-mongo. > Sounds good. Regards, Tomek [1] http://svn.apache.org/repos/asf/sling/trunk/contrib/sling-s3/ [2] https://repository.apache.org/content/repositories/snapshots/ -- Tomek Rękawek Senior Software Engineer Cognifide Polska Sp. z o.o. skype: trekawek www.cognifide.com