I went ahead cargo-ized fedora-client. And since that was so entertaining, I revisited fedora-batch, too. This was actually a little interesting, because fedora-batch originally required modifications to Fedora (adding a jar to WEB-INF/lib), modifying web.xml and adding some config to FEDORA_HOME.
With a bit of refactoring of fedora-batch and the use of overlays, cargo now spins up a modified instance of Fedora with batch request support. While I was at it, I played with using some Servlet 3.0 features in fedora-batch. So now, with Tomcat 7 (or presumably any Servlet 3.0 container), you just need to drop in the fedora-batch-core jar and you're done--no editing of web.xml necessary. Reminds me that it would be nice to push Fedora along to require Servlet 3.0 container support, but that's a whole 'mother discussion. On Sep 3, 2012, at 1:55 PM, Edwin Shin <ed...@fedora-commons.org> wrote: > Thanks for the feedback, everyone. > > Scott's approach is basically what I see happening in > fcrepo-integrationtest-core, except there it's via assemblies. > > I pushed ahead on the cargo-based approach, although getting FEDORA_HOME > correctly filtered and set up involved some unpleasant use of Maven exec:exec > with a stripped-down subset of classes from fcrepo-installer (was more > interested in seeing this work than making it pretty). > > So in many respects it's really not that different from running the installer > (you still pass in an install.properties file which can be filtered for > property substitution). > > But I like a) working with the much smaller fedora_home zip artifact and b) > having cargo manage downloading, starting and stopping tomcat. > > Seems to be working in my sample fedora-cargo project > (https://github.com/eddies/fedora-cargo). I'll see about bringing it to > fedora-client. If it all stands up there, I suppose we could consider > refining and applying to approach w/ fcrepo. > > If we could have Fedora be purely Spring-configured and dump fedora.fcfg (or > at least make it superfluous), I think this would all be a lot cleaner. > > On Sep 1, 2012, at 1:13 AM, Scott Prater <pra...@wisc.edu> wrote: > >> For what it's worth, for more own testing, I deploy and configure a single >> Fedora installer zip multiple times using an (ugly) shell script, setting >> configuration parameters as environment variables that then percolate down >> to the Fedora instance. >> >> Most configuration settings can be set in the install.properties file, so >> the bulk of the configuration work can be done by editing a >> install.properties template, then installing from a generated >> install.properties file. I also templated a few other files: namely >> akubra-llstore.xml and logback.xml. >> >> Not sure how much the shell script work could be turned into maven actions, >> but for my own purposes, I much prefer the route of a single Fedora >> installer with parameterized/templated configuration options, that can be >> deployed, configured, and destroyed on an ad-hoc basis. >> >> -- Scott >> >> On 08/31/12, "aj...@virginia.edu" wrote: >>> I agree that packing a Fedora home (or more than one) into the source tree >>> is not a good thing. For context, the reason that I tried that for the >>> client was simply that I had tried that for the server. The reason that I >>> tried that for the server was because you don't need one Fedora home >>> for the server tests. You need at least four, for the various suites. And >>> using one home and reconfiguring it over and over to run the different >>> suites was just more Maven action than I felt like I wanted to get into for >>> what was, in the end, an experiment. You're getting into that action >>> right now. >>> >>> I don't think you're crazy to try it. I do think it points up some >>> of the difficulties we have with the nature of configuration in Fedora >>> right now. One option-- modularizing the config, which would allow for >>> separate artifacts which might be easier to manage. Another-- introducing >>> multiple prebuilt zipfile Fedora home artifacts, which would minimize the >>> Maven complexity. The first option is clearly better, but it would require >>> some serious work. >>> >>> --- >>> A, Soroka >>> Online Library Environment >>> the University of Virginia Library >>> >>> On Fri, Aug 31, 2012 at 12:38 PM, Edwin Shin >>> <Fedora-commons-developers@lists.sourceforge.net >>> <ed...@fedora-commons.org')" target="1">ed...@fedora-commons.org> wrote: >>> >>>> This may be mostly directed at Adam, but just in case anyone else has any >>>> experience or ideas on the matter: >>>> >>>> I took another look at >>>> https://github.com/mediashelf/fedora-client/tree/test-with-Cargo (which >>>> still won't run correctly for me anyway), which uses Cargo to start up >>>> an instance of Fedora for the integration tests rather than relying on a >>>> separate running instance of Fedora. And of course, we've talked about >>>> doing this for fcrepo as well. >>>> >>>> But I noticed this branch actually adds an actual FEDORA_HOME directory >>>> and miscellany to the git repo. Instead, seems like what you'd want is >>>> to reference the fedora-home zip artifact that gets produced by >>>> fcrepo-installer. But of course, then you're still left w/ getting the >>>> contents of that zip configured correctly. >>>> >>>> So far, I've used the maven-dependencies-plugin to unpack the >>>> fedora-home zip, then the maven-resources-plugin to filter that unzipped >>>> directory's xml, wsdl and fcfg for Maven-defined properties. But I >>>> still have plenty of breakage when Cargo actually tries to start the >>>> Fedora web app. Before I sink much more time into this, I'm just >>>> looking for a sanity check on this approach. >>>> >>>> I've created a new project just to try and minimize the number of >>>> moving parts: >>>> https://github.com/eddies/fedora-cargo >>>> >>>> It just tries to launch Fedora via Cargo and runs a Describe Repository >>>> test (mvn verify). >>>> >>>> To only unpack and filter fedora home, use mvn package. >>>> >>>> Suggestions or help most welcome ;-) > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
