You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sam Spycher <sa...@spycher.info> on 2011/10/19 09:24:52 UTC
Scripting felix
Hi
I am currently writing a small shell script which is supposed to run
felix, install the necessary bundles with gogo, then quit and package
felix for deployment on our integration servers.
Unfortunately, felix seems to undeploy the deployed bundles when
shutting down. If I do this manually, felix retains the bundles across
shutdowns and startups.
The only difference I can find is on how I exit Felix. From the script,
felix exits "normally", and when configuring interactively I exit with
Ctrl-C.
-> so my question is: how can I persuade Felix to keep the installed
bundles (and keep their active state) across shutdowns and startups?
-> would the proper way to do this be over config.properties?
-> if yes, and if this means that deployment of bundles happens on every
startup, then how do I work around the issue of potentially not having
access to a repo on the server that felix is to be installed?
Here is the part of the script which uses gogo:
#!/bin/bash
# ...
# GOGO deployment script
cat > $GOGO_SCRIPT <<-END_GOGO_SCRIPT
obr:repos add file:$HOME/.m2/repository/repository.xml
obr:deploy -s "Bundle A"
obr:deploy -s "Bundle B"
obr:deploy -s "Bundle C"
# etc.
felix:refresh
felix:lb
END_GOGO_SCRIPT
# ...
# run felix and GOGO script
java -verbose -jar bin/felix.jar - <<-END_GOGO_SCRIPT_STARTUP
gosh --nointeractive --login -x $GOGO_SCRIPT
END_GOGO_SCRIPT_STARTUP
Thanks for any help,
Sam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE : RE : Scripting felix
Posted by DEBROUX Lionel <Li...@atos.net>.
Hi again,
> Thanks for the example given, you are right, we are using Maven. I am
> currently adding base depencies by using copy-dependencies as you
> describe. But I am not using some of the additional maven niceties
> you are demonstrating, so thanks for the pointers.
You're welcome.
> What I like about the gogo-deployment method is that dependency
> resolution for obr:deploy happens on the basis of manifest.mf, so
> for our project bundles I can test this functionality directly as part
> of the integration build.
OK.
> I realize I could deploy the felix output of the maven method during
> the build in order to test manifest issues, but I must admit I am a
> little worried about runtime dependency issues and/or adding too much
> to our felix build with maven as dependency resolver... I note you
> are setting excludeTransitive to true in copy-dependencies of the
> example below :)
I guess that having excludeTransitive to true, in the POM I extracted
and simplified for posting here, was just a way to force explicit
specification of dependencies in the POM, so that no new dependency
can slip in without anybody noticing.
> -> Is there no way to have gogo persist its deployments, as it does
> when I deploy bundles interactively?
>
> -> Would you advise against using this approach for other reasons?
I don't know, let's wait for answers from other persons :)
Regards,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Re: RE : Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Lionel & felix users,
Thanks for the example given, you are right, we are using Maven. I am
currently adding base depencies by using copy-dependencies as you
describe. But I am not using some of the additional maven niceties you
are demonstrating, so thanks for the pointers.
What I like about the gogo-deployment method is that dependency
resolution for obr:deploy happens on the basis of manifest.mf, so for
our project bundles I can test this functionality directly as part of
the integration build.
I realize I could deploy the felix output of the maven method during the
build in order to test manifest issues, but I must admit I am a little
worried about runtime dependency issues and/or adding too much to our
felix build with maven as dependency resolver... I note you are setting
excludeTransitive to true in copy-dependencies of the example below :)
-> Is there no way to have gogo persist its deployments, as it does when
I deploy bundles interactively?
-> Would you advise against using this approach for other reasons?
Thanks again for any input,
Sam
Am 19.10.11 09:42, schrieb DEBROUX Lionel:
> Hello,
>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> [snip]
> If you are using Maven, and your bundles are deployed in Maven
> repositories (besides being deployed in OBR repositories), you can
> add bundles to a Felix installation without running Felix.
>
> The two following sample files add a File Install 3.1.10 bundle to a
> Felix 4.0.1 framework, then re-package the result as a gzipped tarball:
>
> pom.xml:
> "
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <packaging>pom</packaging>
> <name>NAME</name>
> <description>DESCRIPTION</description>
> <groupId>GROUP</groupId>
> <artifactId>ARTIFACT</artifactId>
> <version>VERSION</version>
>
> <properties>
> <felix.version>4.0.1</felix.version>
> <felix.dir>${project.build.directory}/felix-framework-${felix.version}</felix.dir>
> <fileinstall.version>3.1.10</fileinstall.version>
> </properties>
>
> <dependencies>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.fileinstall</artifactId>
> <version>${fileinstall.version}</version>
> </dependency>
>
> <!-- Add more dependencies here if you want -->
> </dependencies>
>
> <build>
> <plugins>
> <!-- 1. Unpack Felix distribution to target/${felix.dir} and install dependencies in bundle -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>unpack-felix</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>unpack</goal>
> </goals>
> <configuration>
> <outputDirectory>${project.build.directory}</outputDirectory>
> <excludeTransitive>true</excludeTransitive>
> <overWrite>true</overWrite>
> <artifactItems>
> <artifactItem>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.main.distribution</artifactId>
> <version>${felix.version}</version>
> <type>tar.gz</type>
> </artifactItem>
> </artifactItems>
> </configuration>
> </execution>
>
> <execution>
> <id>fill-out-bundle</id>
> <phase>process-resources</phase>
> <goals>
> <goal>copy-dependencies</goal>
> </goals>
> <configuration>
> <outputDirectory>${felix.dir}/bundle</outputDirectory>
> <useRepositoryLayout>false</useRepositoryLayout>
> <excludeTransitive>true</excludeTransitive>
> <overWrite>true</overWrite>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <!-- 2. Create an assembly package of the modified Felix distribution -->
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <executions>
> <execution>
> <id>make-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> <configuration>
> <archiveBaseDirectory>${felix.dir}</archiveBaseDirectory>
> <tarLongFileMode>gnu</tarLongFileMode>
> <descriptors>
> <descriptor>assembly.xml</descriptor>
> </descriptors>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </project>
> "
>
> assembly.xml:
> "
> <?xml version="1.0" encoding="UTF-8"?>
> <assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd">
> <formats>
> <format>tar.gz</format>
> </formats>
> <fileSets>
> <fileSet>
> <directory>.</directory>
> </fileSet>
> </fileSets>
> </assembly>
> "
>
>
> Regards,
> Lionel.
> ________________________________
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE : Scripting felix
Posted by DEBROUX Lionel <Li...@atos.net>.
Hello,
> I am currently writing a small shell script which is supposed to run
> felix, install the necessary bundles with gogo, then quit and package
> felix for deployment on our integration servers.
>
> [snip]
If you are using Maven, and your bundles are deployed in Maven
repositories (besides being deployed in OBR repositories), you can
add bundles to a Felix installation without running Felix.
The two following sample files add a File Install 3.1.10 bundle to a
Felix 4.0.1 framework, then re-package the result as a gzipped tarball:
pom.xml:
"
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<name>NAME</name>
<description>DESCRIPTION</description>
<groupId>GROUP</groupId>
<artifactId>ARTIFACT</artifactId>
<version>VERSION</version>
<properties>
<felix.version>4.0.1</felix.version>
<felix.dir>${project.build.directory}/felix-framework-${felix.version}</felix.dir>
<fileinstall.version>3.1.10</fileinstall.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.fileinstall</artifactId>
<version>${fileinstall.version}</version>
</dependency>
<!-- Add more dependencies here if you want -->
</dependencies>
<build>
<plugins>
<!-- 1. Unpack Felix distribution to target/${felix.dir} and install dependencies in bundle -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-felix</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}</outputDirectory>
<excludeTransitive>true</excludeTransitive>
<overWrite>true</overWrite>
<artifactItems>
<artifactItem>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.main.distribution</artifactId>
<version>${felix.version}</version>
<type>tar.gz</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
<execution>
<id>fill-out-bundle</id>
<phase>process-resources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${felix.dir}/bundle</outputDirectory>
<useRepositoryLayout>false</useRepositoryLayout>
<excludeTransitive>true</excludeTransitive>
<overWrite>true</overWrite>
</configuration>
</execution>
</executions>
</plugin>
<!-- 2. Create an assembly package of the modified Felix distribution -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<archiveBaseDirectory>${felix.dir}</archiveBaseDirectory>
<tarLongFileMode>gnu</tarLongFileMode>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
"
assembly.xml:
"
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>.</directory>
</fileSet>
</fileSets>
</assembly>
"
Regards,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Karl
It is true that I haven't done anything cache-wise at all! Do I need to
configure this in some special way?
The cache location is at default. In fact, I haven't changed anything at
all in config.properties. The working directory of the script is the
felix root directory.
Best regards,
Sam
Am 19.10.11 17:30, schrieb Karl Pauls:
> On Wed, Oct 19, 2011 at 5:23 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>
>>> Hi
>>>
>>> I am currently writing a small shell script which is supposed to run
>>> felix, install the necessary bundles with gogo, then quit and package
>>> felix for deployment on our integration servers.
>>>
>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>> shutting down. If I do this manually, felix retains the bundles across
>>> shutdowns and startups.
>>
>> I'm not sure what you mean, nor what you are doing exactly, but the Felix
>> framework always retains bundles across shutdowns and restarts. The
>> framework will never undeploy a bundle unless someone tells it to do so.
>
> Maybe you didn't include the cache?
>
> regards,
>
> Karl
>
>> -> richard
>>
>>>
>>> The only difference I can find is on how I exit Felix. From the script,
>>> felix exits "normally", and when configuring interactively I exit with
>>> Ctrl-C.
>>>
>>> -> so my question is: how can I persuade Felix to keep the installed
>>> bundles (and keep their active state) across shutdowns and startups?
>>>
>>> -> would the proper way to do this be over config.properties?
>>>
>>> -> if yes, and if this means that deployment of bundles happens on every
>>> startup, then how do I work around the issue of potentially not having
>>> access to a repo on the server that felix is to be installed?
>>>
>>>
>>> Here is the part of the script which uses gogo:
>>>
>>> #!/bin/bash
>>> # ...
>>> # GOGO deployment script
>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Bundle A"
>>> obr:deploy -s "Bundle B"
>>> obr:deploy -s "Bundle C"
>>> # etc.
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT
>>> # ...
>>> # run felix and GOGO script
>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>>
>>> Thanks for any help,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Oct 19, 2011 at 5:23 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 10/19/11 03:24 , Sam Spycher wrote:
>>
>> Hi
>>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> Unfortunately, felix seems to undeploy the deployed bundles when
>> shutting down. If I do this manually, felix retains the bundles across
>> shutdowns and startups.
>
> I'm not sure what you mean, nor what you are doing exactly, but the Felix
> framework always retains bundles across shutdowns and restarts. The
> framework will never undeploy a bundle unless someone tells it to do so.
Maybe you didn't include the cache?
regards,
Karl
> -> richard
>
>>
>> The only difference I can find is on how I exit Felix. From the script,
>> felix exits "normally", and when configuring interactively I exit with
>> Ctrl-C.
>>
>> -> so my question is: how can I persuade Felix to keep the installed
>> bundles (and keep their active state) across shutdowns and startups?
>>
>> -> would the proper way to do this be over config.properties?
>>
>> -> if yes, and if this means that deployment of bundles happens on every
>> startup, then how do I work around the issue of potentially not having
>> access to a repo on the server that felix is to be installed?
>>
>>
>> Here is the part of the script which uses gogo:
>>
>> #!/bin/bash
>> # ...
>> # GOGO deployment script
>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Bundle A"
>> obr:deploy -s "Bundle B"
>> obr:deploy -s "Bundle C"
>> # etc.
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT
>> # ...
>> # run felix and GOGO script
>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>> gosh --nointeractive --login -x $GOGO_SCRIPT
>> END_GOGO_SCRIPT_STARTUP
>>
>>
>> Thanks for any help,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 13:38 , Sam Spycher wrote:
> Hi everybody
>
> I'm sorry, this has really been much ado about something very small :(
>
> My mistake was a typo. I oversaw a small dash right in front of the
> heredoc marker in the script:
>
> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
Makes sense, you renamed the cache on the command line. :-)
-> richard
>
> Thanks to Richard and Karl for bringing up the felix-cache, the weird
> naming there pointed me in the right direction.
>
> Best regards,
> Sam
>
> Am 19.10.11 18:36, schrieb Richard S. Hall:
>> On 10/19/11 12:09 , Sam Spycher wrote:
>>> Hmm, that is interesting.
>>>
>>> When I deploy felix via script, I can observe the creation of a
>>> directory called '-' in the working directory while the script is
>>> executing.
>>>
>>> Looking at the contents of '-', I find bundleX subdirectories just as is
>>> to be expected from the felix cache. Indeed if i cat the bundle.info
>>> of the bundle with the highest number I can see this corresponds to a
>>> bundle that I installed with gogo.
>>>
>>> However, when I run Felix interactively from the shell after having run
>>> the script, it creates a new cache directory with the proper default
>>> name 'felix-cache'. Of course this directory now contains no traces of
>>> what was installed with gogo, it only has the bundles which were copied
>>> into the bundle/ subdirectory.
>>>
>>> -> Some issue with the cache directory name when running felix
>>> non-interactively?
>>>
>>> Note that I'm running 4.0.1 directly off maven, with no modifications to
>>> config.properties.
>> Not sure if the way you are launching it somehow overrides the default
>> cache value or not, but if you want to see what is going on, perhaps you
>> can try to debug it and set a break point at:
>>
>> org.apache.felix.framework.cache.BundleCache.determineCacheDir()
>>
>> This calculates the cache directory based on the default config and/or
>> any specified configuration.
>>
>> -> richard
>>
>>> Thanks& Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:44, schrieb Richard S. Hall:
>>>> On 10/19/11 11:39 , Sam Spycher wrote:
>>>>> Hi Richard,
>>>>>
>>>>> I am running a bash script which sends some gogo deployment commands to
>>>>> install some bundles in felix. I then list the bundles I just deployed
>>>>> with gogo with the command 'lb'. These bundles are all correctly
>>>>> displayed and have their state set to active. At the end of the script
>>>>> Felix then terminates (I assume because it is called non-interactively
>>>>> via a script).
>>>>>
>>>>> Now if I startup this exact same deployment and list the installed
>>>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>>>> although I never undeployed them.
>>>>>
>>>>> What am I missing?
>>>> Well, the framework installs bundles into a cache, which is by default
>>>> in the current directory called felix-cache. Do you see this directory
>>>> get created? Is it still there after shutdown? What happens to it after
>>>> startup?
>>>>
>>>> -> richard
>>>>
>>>>> Here is a minimal version of my deployment script:
>>>>>
>>>>> #!/bin/bash
>>>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Some bundle from maven repo"
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>> Best regards,
>>>>> Sam
>>>>>
>>>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I am currently writing a small shell script which is supposed to run
>>>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>>>> felix for deployment on our integration servers.
>>>>>>>
>>>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>>>> shutting down. If I do this manually, felix retains the bundles
>>>>>>> across
>>>>>>> shutdowns and startups.
>>>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>>>> The framework will never undeploy a bundle unless someone tells it
>>>>>> to do
>>>>>> so.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> The only difference I can find is on how I exit Felix. From the
>>>>>>> script,
>>>>>>> felix exits "normally", and when configuring interactively I exit
>>>>>>> with
>>>>>>> Ctrl-C.
>>>>>>>
>>>>>>> -> so my question is: how can I persuade Felix to keep the
>>>>>>> installed
>>>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>>>
>>>>>>> -> would the proper way to do this be over config.properties?
>>>>>>>
>>>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>>>> every
>>>>>>> startup, then how do I work around the issue of potentially not
>>>>>>> having
>>>>>>> access to a repo on the server that felix is to be installed?
>>>>>>>
>>>>>>>
>>>>>>> Here is the part of the script which uses gogo:
>>>>>>>
>>>>>>> #!/bin/bash
>>>>>>> # ...
>>>>>>> # GOGO deployment script
>>>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>>>> obr:deploy -s "Bundle A"
>>>>>>> obr:deploy -s "Bundle B"
>>>>>>> obr:deploy -s "Bundle C"
>>>>>>> # etc.
>>>>>>> felix:refresh
>>>>>>> felix:lb
>>>>>>> END_GOGO_SCRIPT
>>>>>>> # ...
>>>>>>> # run felix and GOGO script
>>>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>>>
>>>>>>>
>>>>>>> Thanks for any help,
>>>>>>> Sam
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi everybody
I'm sorry, this has really been much ado about something very small :(
My mistake was a typo. I oversaw a small dash right in front of the
heredoc marker in the script:
java -verbose -jar bin/felix.jar - <<-END_GOGO_SCRIPT_STARTUP
Thanks to Richard and Karl for bringing up the felix-cache, the weird
naming there pointed me in the right direction.
Best regards,
Sam
Am 19.10.11 18:36, schrieb Richard S. Hall:
> On 10/19/11 12:09 , Sam Spycher wrote:
>> Hmm, that is interesting.
>>
>> When I deploy felix via script, I can observe the creation of a
>> directory called '-' in the working directory while the script is
>> executing.
>>
>> Looking at the contents of '-', I find bundleX subdirectories just as is
>> to be expected from the felix cache. Indeed if i cat the bundle.info
>> of the bundle with the highest number I can see this corresponds to a
>> bundle that I installed with gogo.
>>
>> However, when I run Felix interactively from the shell after having run
>> the script, it creates a new cache directory with the proper default
>> name 'felix-cache'. Of course this directory now contains no traces of
>> what was installed with gogo, it only has the bundles which were copied
>> into the bundle/ subdirectory.
>>
>> -> Some issue with the cache directory name when running felix
>> non-interactively?
>>
>> Note that I'm running 4.0.1 directly off maven, with no modifications to
>> config.properties.
>
> Not sure if the way you are launching it somehow overrides the default
> cache value or not, but if you want to see what is going on, perhaps you
> can try to debug it and set a break point at:
>
> org.apache.felix.framework.cache.BundleCache.determineCacheDir()
>
> This calculates the cache directory based on the default config and/or
> any specified configuration.
>
> -> richard
>
>>
>> Thanks& Best regards,
>> Sam
>>
>> Am 19.10.11 17:44, schrieb Richard S. Hall:
>>> On 10/19/11 11:39 , Sam Spycher wrote:
>>>> Hi Richard,
>>>>
>>>> I am running a bash script which sends some gogo deployment commands to
>>>> install some bundles in felix. I then list the bundles I just deployed
>>>> with gogo with the command 'lb'. These bundles are all correctly
>>>> displayed and have their state set to active. At the end of the script
>>>> Felix then terminates (I assume because it is called non-interactively
>>>> via a script).
>>>>
>>>> Now if I startup this exact same deployment and list the installed
>>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>>> although I never undeployed them.
>>>>
>>>> What am I missing?
>>> Well, the framework installs bundles into a cache, which is by default
>>> in the current directory called felix-cache. Do you see this directory
>>> get created? Is it still there after shutdown? What happens to it after
>>> startup?
>>>
>>> -> richard
>>>
>>>>
>>>> Here is a minimal version of my deployment script:
>>>>
>>>> #!/bin/bash
>>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>> obr:deploy -s "Some bundle from maven repo"
>>>> felix:refresh
>>>> felix:lb
>>>> END_GOGO_SCRIPT_STARTUP
>>>>
>>>> Best regards,
>>>> Sam
>>>>
>>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>>> Hi
>>>>>>
>>>>>> I am currently writing a small shell script which is supposed to run
>>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>>> felix for deployment on our integration servers.
>>>>>>
>>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>>> shutting down. If I do this manually, felix retains the bundles
>>>>>> across
>>>>>> shutdowns and startups.
>>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>>> The framework will never undeploy a bundle unless someone tells it
>>>>> to do
>>>>> so.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> The only difference I can find is on how I exit Felix. From the
>>>>>> script,
>>>>>> felix exits "normally", and when configuring interactively I exit
>>>>>> with
>>>>>> Ctrl-C.
>>>>>>
>>>>>> -> so my question is: how can I persuade Felix to keep the
>>>>>> installed
>>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>>
>>>>>> -> would the proper way to do this be over config.properties?
>>>>>>
>>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>>> every
>>>>>> startup, then how do I work around the issue of potentially not
>>>>>> having
>>>>>> access to a repo on the server that felix is to be installed?
>>>>>>
>>>>>>
>>>>>> Here is the part of the script which uses gogo:
>>>>>>
>>>>>> #!/bin/bash
>>>>>> # ...
>>>>>> # GOGO deployment script
>>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>>> obr:deploy -s "Bundle A"
>>>>>> obr:deploy -s "Bundle B"
>>>>>> obr:deploy -s "Bundle C"
>>>>>> # etc.
>>>>>> felix:refresh
>>>>>> felix:lb
>>>>>> END_GOGO_SCRIPT
>>>>>> # ...
>>>>>> # run felix and GOGO script
>>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>>
>>>>>>
>>>>>> Thanks for any help,
>>>>>> Sam
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 12:09 , Sam Spycher wrote:
> Hmm, that is interesting.
>
> When I deploy felix via script, I can observe the creation of a
> directory called '-' in the working directory while the script is executing.
>
> Looking at the contents of '-', I find bundleX subdirectories just as is
> to be expected from the felix cache. Indeed if i cat the bundle.info
> of the bundle with the highest number I can see this corresponds to a
> bundle that I installed with gogo.
>
> However, when I run Felix interactively from the shell after having run
> the script, it creates a new cache directory with the proper default
> name 'felix-cache'. Of course this directory now contains no traces of
> what was installed with gogo, it only has the bundles which were copied
> into the bundle/ subdirectory.
>
> -> Some issue with the cache directory name when running felix
> non-interactively?
>
> Note that I'm running 4.0.1 directly off maven, with no modifications to
> config.properties.
Not sure if the way you are launching it somehow overrides the default
cache value or not, but if you want to see what is going on, perhaps you
can try to debug it and set a break point at:
org.apache.felix.framework.cache.BundleCache.determineCacheDir()
This calculates the cache directory based on the default config and/or
any specified configuration.
-> richard
>
> Thanks& Best regards,
> Sam
>
> Am 19.10.11 17:44, schrieb Richard S. Hall:
>> On 10/19/11 11:39 , Sam Spycher wrote:
>>> Hi Richard,
>>>
>>> I am running a bash script which sends some gogo deployment commands to
>>> install some bundles in felix. I then list the bundles I just deployed
>>> with gogo with the command 'lb'. These bundles are all correctly
>>> displayed and have their state set to active. At the end of the script
>>> Felix then terminates (I assume because it is called non-interactively
>>> via a script).
>>>
>>> Now if I startup this exact same deployment and list the installed
>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>> although I never undeployed them.
>>>
>>> What am I missing?
>> Well, the framework installs bundles into a cache, which is by default
>> in the current directory called felix-cache. Do you see this directory
>> get created? Is it still there after shutdown? What happens to it after
>> startup?
>>
>> -> richard
>>
>>>
>>> Here is a minimal version of my deployment script:
>>>
>>> #!/bin/bash
>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Some bundle from maven repo"
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>> Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>> Hi
>>>>>
>>>>> I am currently writing a small shell script which is supposed to run
>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>> felix for deployment on our integration servers.
>>>>>
>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>> shutting down. If I do this manually, felix retains the bundles across
>>>>> shutdowns and startups.
>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>> The framework will never undeploy a bundle unless someone tells it to do
>>>> so.
>>>>
>>>> -> richard
>>>>
>>>>> The only difference I can find is on how I exit Felix. From the script,
>>>>> felix exits "normally", and when configuring interactively I exit with
>>>>> Ctrl-C.
>>>>>
>>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>
>>>>> -> would the proper way to do this be over config.properties?
>>>>>
>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>> every
>>>>> startup, then how do I work around the issue of potentially not having
>>>>> access to a repo on the server that felix is to be installed?
>>>>>
>>>>>
>>>>> Here is the part of the script which uses gogo:
>>>>>
>>>>> #!/bin/bash
>>>>> # ...
>>>>> # GOGO deployment script
>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Bundle A"
>>>>> obr:deploy -s "Bundle B"
>>>>> obr:deploy -s "Bundle C"
>>>>> # etc.
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT
>>>>> # ...
>>>>> # run felix and GOGO script
>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>>
>>>>> Thanks for any help,
>>>>> Sam
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
P.S.
Just wanted to mention also that there is no urgency to this issue, at
least not to me personally.
Since I have proceeded in the meantime by adding our project bundles
with maven copy-dependencies per Lionel's recommendations, and
test-running felix afterwards, the only disadvantage I have at the
moment is that I have an unnecessary felix cache directory called '-'
after running maven.
Best regards,
Sam
Am 19.10.11 18:09, schrieb Sam Spycher:
> Hmm, that is interesting.
>
> When I deploy felix via script, I can observe the creation of a
> directory called '-' in the working directory while the script is executing.
>
> Looking at the contents of '-', I find bundleX subdirectories just as is
> to be expected from the felix cache. Indeed if i cat the bundle.info
> of the bundle with the highest number I can see this corresponds to a
> bundle that I installed with gogo.
>
> However, when I run Felix interactively from the shell after having run
> the script, it creates a new cache directory with the proper default
> name 'felix-cache'. Of course this directory now contains no traces of
> what was installed with gogo, it only has the bundles which were copied
> into the bundle/ subdirectory.
>
> -> Some issue with the cache directory name when running felix
> non-interactively?
>
> Note that I'm running 4.0.1 directly off maven, with no modifications to
> config.properties.
>
> Thanks & Best regards,
> Sam
>
> Am 19.10.11 17:44, schrieb Richard S. Hall:
>> On 10/19/11 11:39 , Sam Spycher wrote:
>>> Hi Richard,
>>>
>>> I am running a bash script which sends some gogo deployment commands to
>>> install some bundles in felix. I then list the bundles I just deployed
>>> with gogo with the command 'lb'. These bundles are all correctly
>>> displayed and have their state set to active. At the end of the script
>>> Felix then terminates (I assume because it is called non-interactively
>>> via a script).
>>>
>>> Now if I startup this exact same deployment and list the installed
>>> bundles via 'lb', all I get is the bundles I previously copied into the
>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>>> although I never undeployed them.
>>>
>>> What am I missing?
>>
>> Well, the framework installs bundles into a cache, which is by default
>> in the current directory called felix-cache. Do you see this directory
>> get created? Is it still there after shutdown? What happens to it after
>> startup?
>>
>> -> richard
>>
>>>
>>>
>>> Here is a minimal version of my deployment script:
>>>
>>> #!/bin/bash
>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Some bundle from maven repo"
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>> Best regards,
>>> Sam
>>>
>>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>>> Hi
>>>>>
>>>>> I am currently writing a small shell script which is supposed to run
>>>>> felix, install the necessary bundles with gogo, then quit and package
>>>>> felix for deployment on our integration servers.
>>>>>
>>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>>> shutting down. If I do this manually, felix retains the bundles across
>>>>> shutdowns and startups.
>>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>>> Felix framework always retains bundles across shutdowns and restarts.
>>>> The framework will never undeploy a bundle unless someone tells it to do
>>>> so.
>>>>
>>>> -> richard
>>>>
>>>>> The only difference I can find is on how I exit Felix. From the script,
>>>>> felix exits "normally", and when configuring interactively I exit with
>>>>> Ctrl-C.
>>>>>
>>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>>
>>>>> -> would the proper way to do this be over config.properties?
>>>>>
>>>>> -> if yes, and if this means that deployment of bundles happens on
>>>>> every
>>>>> startup, then how do I work around the issue of potentially not having
>>>>> access to a repo on the server that felix is to be installed?
>>>>>
>>>>>
>>>>> Here is the part of the script which uses gogo:
>>>>>
>>>>> #!/bin/bash
>>>>> # ...
>>>>> # GOGO deployment script
>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>>> obr:deploy -s "Bundle A"
>>>>> obr:deploy -s "Bundle B"
>>>>> obr:deploy -s "Bundle C"
>>>>> # etc.
>>>>> felix:refresh
>>>>> felix:lb
>>>>> END_GOGO_SCRIPT
>>>>> # ...
>>>>> # run felix and GOGO script
>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>>> END_GOGO_SCRIPT_STARTUP
>>>>>
>>>>>
>>>>> Thanks for any help,
>>>>> Sam
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hmm, that is interesting.
When I deploy felix via script, I can observe the creation of a
directory called '-' in the working directory while the script is executing.
Looking at the contents of '-', I find bundleX subdirectories just as is
to be expected from the felix cache. Indeed if i cat the bundle.info
of the bundle with the highest number I can see this corresponds to a
bundle that I installed with gogo.
However, when I run Felix interactively from the shell after having run
the script, it creates a new cache directory with the proper default
name 'felix-cache'. Of course this directory now contains no traces of
what was installed with gogo, it only has the bundles which were copied
into the bundle/ subdirectory.
-> Some issue with the cache directory name when running felix
non-interactively?
Note that I'm running 4.0.1 directly off maven, with no modifications to
config.properties.
Thanks & Best regards,
Sam
Am 19.10.11 17:44, schrieb Richard S. Hall:
> On 10/19/11 11:39 , Sam Spycher wrote:
>> Hi Richard,
>>
>> I am running a bash script which sends some gogo deployment commands to
>> install some bundles in felix. I then list the bundles I just deployed
>> with gogo with the command 'lb'. These bundles are all correctly
>> displayed and have their state set to active. At the end of the script
>> Felix then terminates (I assume because it is called non-interactively
>> via a script).
>>
>> Now if I startup this exact same deployment and list the installed
>> bundles via 'lb', all I get is the bundles I previously copied into the
>> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
>> although I never undeployed them.
>>
>> What am I missing?
>
> Well, the framework installs bundles into a cache, which is by default
> in the current directory called felix-cache. Do you see this directory
> get created? Is it still there after shutdown? What happens to it after
> startup?
>
> -> richard
>
>>
>>
>> Here is a minimal version of my deployment script:
>>
>> #!/bin/bash
>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Some bundle from maven repo"
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT_STARTUP
>>
>> Best regards,
>> Sam
>>
>> Am 19.10.11 17:23, schrieb Richard S. Hall:
>>> On 10/19/11 03:24 , Sam Spycher wrote:
>>>> Hi
>>>>
>>>> I am currently writing a small shell script which is supposed to run
>>>> felix, install the necessary bundles with gogo, then quit and package
>>>> felix for deployment on our integration servers.
>>>>
>>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>>> shutting down. If I do this manually, felix retains the bundles across
>>>> shutdowns and startups.
>>> I'm not sure what you mean, nor what you are doing exactly, but the
>>> Felix framework always retains bundles across shutdowns and restarts.
>>> The framework will never undeploy a bundle unless someone tells it to do
>>> so.
>>>
>>> -> richard
>>>
>>>> The only difference I can find is on how I exit Felix. From the script,
>>>> felix exits "normally", and when configuring interactively I exit with
>>>> Ctrl-C.
>>>>
>>>> -> so my question is: how can I persuade Felix to keep the installed
>>>> bundles (and keep their active state) across shutdowns and startups?
>>>>
>>>> -> would the proper way to do this be over config.properties?
>>>>
>>>> -> if yes, and if this means that deployment of bundles happens on
>>>> every
>>>> startup, then how do I work around the issue of potentially not having
>>>> access to a repo on the server that felix is to be installed?
>>>>
>>>>
>>>> Here is the part of the script which uses gogo:
>>>>
>>>> #!/bin/bash
>>>> # ...
>>>> # GOGO deployment script
>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>>> obr:deploy -s "Bundle A"
>>>> obr:deploy -s "Bundle B"
>>>> obr:deploy -s "Bundle C"
>>>> # etc.
>>>> felix:refresh
>>>> felix:lb
>>>> END_GOGO_SCRIPT
>>>> # ...
>>>> # run felix and GOGO script
>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>>> END_GOGO_SCRIPT_STARTUP
>>>>
>>>>
>>>> Thanks for any help,
>>>> Sam
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 11:39 , Sam Spycher wrote:
> Hi Richard,
>
> I am running a bash script which sends some gogo deployment commands to
> install some bundles in felix. I then list the bundles I just deployed
> with gogo with the command 'lb'. These bundles are all correctly
> displayed and have their state set to active. At the end of the script
> Felix then terminates (I assume because it is called non-interactively
> via a script).
>
> Now if I startup this exact same deployment and list the installed
> bundles via 'lb', all I get is the bundles I previously copied into the
> bunde/ subdirectory. The bundles I installed via gogo have disappeared,
> although I never undeployed them.
>
> What am I missing?
Well, the framework installs bundles into a cache, which is by default
in the current directory called felix-cache. Do you see this directory
get created? Is it still there after shutdown? What happens to it after
startup?
-> richard
>
>
> Here is a minimal version of my deployment script:
>
> #!/bin/bash
> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP
> obr:repos add file:$HOME/.m2/repository/repository.xml
> obr:deploy -s "Some bundle from maven repo"
> felix:refresh
> felix:lb
> END_GOGO_SCRIPT_STARTUP
>
> Best regards,
> Sam
>
> Am 19.10.11 17:23, schrieb Richard S. Hall:
>> On 10/19/11 03:24 , Sam Spycher wrote:
>>> Hi
>>>
>>> I am currently writing a small shell script which is supposed to run
>>> felix, install the necessary bundles with gogo, then quit and package
>>> felix for deployment on our integration servers.
>>>
>>> Unfortunately, felix seems to undeploy the deployed bundles when
>>> shutting down. If I do this manually, felix retains the bundles across
>>> shutdowns and startups.
>> I'm not sure what you mean, nor what you are doing exactly, but the
>> Felix framework always retains bundles across shutdowns and restarts.
>> The framework will never undeploy a bundle unless someone tells it to do
>> so.
>>
>> -> richard
>>
>>> The only difference I can find is on how I exit Felix. From the script,
>>> felix exits "normally", and when configuring interactively I exit with
>>> Ctrl-C.
>>>
>>> -> so my question is: how can I persuade Felix to keep the installed
>>> bundles (and keep their active state) across shutdowns and startups?
>>>
>>> -> would the proper way to do this be over config.properties?
>>>
>>> -> if yes, and if this means that deployment of bundles happens on every
>>> startup, then how do I work around the issue of potentially not having
>>> access to a repo on the server that felix is to be installed?
>>>
>>>
>>> Here is the part of the script which uses gogo:
>>>
>>> #!/bin/bash
>>> # ...
>>> # GOGO deployment script
>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>>> obr:repos add file:$HOME/.m2/repository/repository.xml
>>> obr:deploy -s "Bundle A"
>>> obr:deploy -s "Bundle B"
>>> obr:deploy -s "Bundle C"
>>> # etc.
>>> felix:refresh
>>> felix:lb
>>> END_GOGO_SCRIPT
>>> # ...
>>> # run felix and GOGO script
>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>>> gosh --nointeractive --login -x $GOGO_SCRIPT
>>> END_GOGO_SCRIPT_STARTUP
>>>
>>>
>>> Thanks for any help,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by Sam Spycher <sa...@spycher.info>.
Hi Richard,
I am running a bash script which sends some gogo deployment commands to
install some bundles in felix. I then list the bundles I just deployed
with gogo with the command 'lb'. These bundles are all correctly
displayed and have their state set to active. At the end of the script
Felix then terminates (I assume because it is called non-interactively
via a script).
Now if I startup this exact same deployment and list the installed
bundles via 'lb', all I get is the bundles I previously copied into the
bunde/ subdirectory. The bundles I installed via gogo have disappeared,
although I never undeployed them.
What am I missing?
Here is a minimal version of my deployment script:
#!/bin/bash
java -verbose -jar bin/felix.jar <<-END_GOGO_SCRIPT_STARTUP
obr:repos add file:$HOME/.m2/repository/repository.xml
obr:deploy -s "Some bundle from maven repo"
felix:refresh
felix:lb
END_GOGO_SCRIPT_STARTUP
Best regards,
Sam
Am 19.10.11 17:23, schrieb Richard S. Hall:
> On 10/19/11 03:24 , Sam Spycher wrote:
>> Hi
>>
>> I am currently writing a small shell script which is supposed to run
>> felix, install the necessary bundles with gogo, then quit and package
>> felix for deployment on our integration servers.
>>
>> Unfortunately, felix seems to undeploy the deployed bundles when
>> shutting down. If I do this manually, felix retains the bundles across
>> shutdowns and startups.
>
> I'm not sure what you mean, nor what you are doing exactly, but the
> Felix framework always retains bundles across shutdowns and restarts.
> The framework will never undeploy a bundle unless someone tells it to do
> so.
>
> -> richard
>
>>
>> The only difference I can find is on how I exit Felix. From the script,
>> felix exits "normally", and when configuring interactively I exit with
>> Ctrl-C.
>>
>> -> so my question is: how can I persuade Felix to keep the installed
>> bundles (and keep their active state) across shutdowns and startups?
>>
>> -> would the proper way to do this be over config.properties?
>>
>> -> if yes, and if this means that deployment of bundles happens on every
>> startup, then how do I work around the issue of potentially not having
>> access to a repo on the server that felix is to be installed?
>>
>>
>> Here is the part of the script which uses gogo:
>>
>> #!/bin/bash
>> # ...
>> # GOGO deployment script
>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
>> obr:repos add file:$HOME/.m2/repository/repository.xml
>> obr:deploy -s "Bundle A"
>> obr:deploy -s "Bundle B"
>> obr:deploy -s "Bundle C"
>> # etc.
>> felix:refresh
>> felix:lb
>> END_GOGO_SCRIPT
>> # ...
>> # run felix and GOGO script
>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
>> gosh --nointeractive --login -x $GOGO_SCRIPT
>> END_GOGO_SCRIPT_STARTUP
>>
>>
>> Thanks for any help,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Scripting felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/19/11 03:24 , Sam Spycher wrote:
> Hi
>
> I am currently writing a small shell script which is supposed to run
> felix, install the necessary bundles with gogo, then quit and package
> felix for deployment on our integration servers.
>
> Unfortunately, felix seems to undeploy the deployed bundles when
> shutting down. If I do this manually, felix retains the bundles across
> shutdowns and startups.
I'm not sure what you mean, nor what you are doing exactly, but the
Felix framework always retains bundles across shutdowns and restarts.
The framework will never undeploy a bundle unless someone tells it to do so.
-> richard
>
> The only difference I can find is on how I exit Felix. From the script,
> felix exits "normally", and when configuring interactively I exit with
> Ctrl-C.
>
> -> so my question is: how can I persuade Felix to keep the installed
> bundles (and keep their active state) across shutdowns and startups?
>
> -> would the proper way to do this be over config.properties?
>
> -> if yes, and if this means that deployment of bundles happens on every
> startup, then how do I work around the issue of potentially not having
> access to a repo on the server that felix is to be installed?
>
>
> Here is the part of the script which uses gogo:
>
> #!/bin/bash
> # ...
> # GOGO deployment script
> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT
> obr:repos add file:$HOME/.m2/repository/repository.xml
> obr:deploy -s "Bundle A"
> obr:deploy -s "Bundle B"
> obr:deploy -s "Bundle C"
> # etc.
> felix:refresh
> felix:lb
> END_GOGO_SCRIPT
> # ...
> # run felix and GOGO script
> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP
> gosh --nointeractive --login -x $GOGO_SCRIPT
> END_GOGO_SCRIPT_STARTUP
>
>
> Thanks for any help,
> Sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org