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&#39;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&#39;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&#39;d want is to 
> > reference the fedora-home zip artifact that gets produced by 
> > fcrepo-installer. But of course, then you&#39;re still left w/ getting the 
> > contents of that zip configured correctly.
> > 
> > So far, I&#39;ve used the maven-dependencies-plugin to unpack the 
> > fedora-home zip, then the maven-resources-plugin to filter that unzipped 
> > directory&#39;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&#39;m just looking for a 
> > sanity check on this approach.
> > 
> > I&#39;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&#39;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
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers(javascript:main.compose('new',
> >  't=Fedora-commons-developers@lists.sourceforge.net>
> > <a href=)
> > 

--
-- 
Scott Prater
Library, Instructional, and Research Applications (LIRA)
Division of Information Technology (DoIT)
University of Wisconsin - Madison
pra...@wisc.edu

------------------------------------------------------------------------------
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

Reply via email to