You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by thully <tm...@eng.ucsd.edu> on 2014/07/24 16:45:27 UTC
Disabling local repository creation on Karaf 3?
We have a project (Cytoscape) that uses a custom distribution of Karaf
(currently 2.2.11) to manage OSGi/dependencies. We are in the process of
upgrading to Karaf 3.0.1 for our next release, and have already done this on
our development branch.
For the most part, we've got everything working properly, though there is
one nagging issue we're still dealing with. Since the upgrade to Karaf 3, it
seems that a local Maven repository is created at ~/.m2 every time we start
if one doesn't exist with copies of all the bundles we provide in the system
repository. While it is possible to change
org.ops4j.pax.url.mvn.localRepository in org.ops4j.pax.utl.mvn.cfg, that
just changes the location. We're still stuck with the newly-created
repository with an extra copy of everything, which wastes disk space
unnecessarily (particularly on end-user systems where they won't be using
Maven).
Given that, is there a way to disable this repository creation? I'd prefer
to continue looking in .m2 (so that developers can test updated bundles),
but don't want to create it on end user systems.
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: feature install problem
Posted by thully <tm...@eng.ucsd.edu>.
Also, I've noticed that this behavior seems to be new to Karaf 3 - we never
had any issues with Karaf 2.2.11 copying system bundles into .m2. Any idea
what has changed in Karaf 3 to make this behavior happen, and is there
something I can do (changing a setting, or perhaps using a different version
of one of Karaf's dependencies) to get the Karaf 2 behavior in Karaf 3? We
would just stick with 2.2.x until this is fixed, but at this point we need
to support Java 8 ASAP.
If that isn't an option, we could deal with having the local repo as system
if it works OK with read-only system repositories. If not, we'll probably
put the local repository somewhere else where we can expect write
permissions (not .m2, as we don't want to push our artifacts to an existing
Maven repository). The extra bundles copies/disk space use is undesirable,
though we could put up with it until this gets fixed in Karaf.
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034489.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: feature install problem
Posted by thully <tm...@eng.ucsd.edu>.
Our main concern with writing to the local repository is making the extra
copy of all our bundles - our application is quite large (100MB), and we
don't want to unnecessarily waste disk space/spend time copying files on the
first startup - some of our users may have limited disk space/slower hard
drives. Also, if someone already has a .m2 repository for development
purposes, we don't want to touch it.
As far as writing to the system repository, our main concern there is that
our application will fail to work for users without write access to that
directory. It seems to work now (albeit with one permission denied error),
but there may be something we've overlooked...
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034488.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Thanks, Achim
I did it the safe way and started with a clean karaf installation. But
it's good to know what the format is like.
Regards,
Laci
On 31.07.2014 21:54, Achim Nierbeck wrote:
> Hi Laci,
>
> well the file you found is in a specific bundle cache directory, most
> likely the one of the feature-service therefore you can't edit it to
> "fix" your issue :)
> You might want to try to "patch" it, though I'm not sure it'll work.
> The format is simple,
> features.<feature-name>_split_for_name_and_version_<version>=list-of-installed-bundles
>
> regards, Achim
>
>
>
>
> 2014-07-31 15:49 GMT+02:00 Laci Gaspar <lacigas@gmail.com
> <ma...@gmail.com>>:
>
> Thanks Achim!
>
> Regards,
> Laci
>
>
> On 31.07.2014 14:43, Achim Nierbeck wrote:
>
> Hi Laci,
>
> understandable, though I think it's mostly related to your
> installing/un-installing of features many times.
> I'm gonna give the way it works a look later today. So maybe
> more tomorrow :)
>
> Regards, Achim
>
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
Re: feature install problem
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Laci,
well the file you found is in a specific bundle cache directory, most
likely the one of the feature-service therefore you can't edit it to "fix"
your issue :)
You might want to try to "patch" it, though I'm not sure it'll work.
The format is simple,
features.<feature-name>_split_for_name_and_version_<version>=list-of-installed-bundles
regards, Achim
2014-07-31 15:49 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> Thanks Achim!
>
> Regards,
> Laci
>
>
> On 31.07.2014 14:43, Achim Nierbeck wrote:
>
>> Hi Laci,
>>
>> understandable, though I think it's mostly related to your
>> installing/un-installing of features many times.
>> I'm gonna give the way it works a look later today. So maybe more
>> tomorrow :)
>>
>> Regards, Achim
>>
>>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Thanks Achim!
Regards,
Laci
On 31.07.2014 14:43, Achim Nierbeck wrote:
> Hi Laci,
>
> understandable, though I think it's mostly related to your
> installing/un-installing of features many times.
> I'm gonna give the way it works a look later today. So maybe more
> tomorrow :)
>
> Regards, Achim
>
Re: feature install problem
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Laci,
understandable, though I think it's mostly related to your
installing/un-installing of features many times.
I'm gonna give the way it works a look later today. So maybe more tomorrow
:)
Regards, Achim
2014-07-31 14:28 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> Hi
> It's not a problem to start from scratch, since it's a development
> installation. I just wanted to know if there's a way to fix such a
> situation in case we run into it in a production environment. There it
> would be nicer if I could "fix" it somehow instead of setting up a clean
> installation.
>
> Thanks anyway.
> Regards,
> Laci
>
>
> On 31.07.2014 09:54, Achim Nierbeck wrote:
>
> Hi,
>
> right now I don't know of any means of "fixing" this file, need to
> inspect that a bit further.
> As it seems to work with a clean data dir, why don't you start from
> scratch?
>
> regards, Achim
>
>
>
> 2014-07-31 9:06 GMT+02:00 Laci Gaspar <la...@gmail.com>:
>
>> Hi
>> Yes, there seems to be something wrong in the data/cache directory. With
>> an empty data directory I can install the features.
>>
>> In the cache directory for the FeatureService there is a file
>> FeaturesServiceState.properties which lists features which are not
>> installed.
>> Is there a possibility to rebuild that file? I don't quite understand the
>> syntax of it.
>>
>> Regards,
>> Laci
>>
>>
>> On 30.07.2014 22:26, Achim Nierbeck wrote:
>>
>> Hi,
>>
>> strange enough it's not installing any bundles.
>> Could you try this with a clean data folder?
>>
>> regards, Achim
>>
>>
>> 2014-07-30 9:14 GMT+02:00 Laci Gaspar <la...@gmail.com>:
>>
>>> Very strange...
>>> karaf says it's installing the features:
>>> karaf@root> features:install -c -v mspEtg-development
>>> Installing feature mspEtg-development 1.1.0-SNAPSHOT
>>> Installing feature DeliverInvoiceToDossier-development 1.1.0-SNAPSHOT
>>> Installing feature DisableDossierDelivery-development 1.1.0-SNAPSHOT
>>>
>>> but they are not there:
>>> features:list | grep -i DeliverInvoiceToDossier
>>> karaf@root>
>>>
>>> when I try to uninstall them:
>>> karaf@root> features:uninstall DeliverInvoiceToDossier-development
>>> Error executing command: Feature named
>>> 'DeliverInvoiceToDossier-development' has multiple versions installed
>>> (1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify the version to uninstall.
>>>
>>> but they are not there...
>>> karaf@root> features:uninstall
>>> DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
>>> Error executing command: Feature named
>>> 'DeliverInvoiceToDossier-development' with version '1.0.0-SNAPSHOT' is not
>>> installed
>>> karaf@root> features:uninstall
>>> DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
>>> Error executing command: Feature named
>>> 'DeliverInvoiceToDossier-development' with version '1.1.0-SNAPSHOT' is not
>>> installed
>>>
>>> any ideas?
>>>
>>> Thanks,
>>> Laci
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 29.07.2014 20:41, Achim Nierbeck wrote:
>>>
>>> Hi Laci,
>>> give installing with -c and -v a try.
>>> This way you'll see more of what is happening.
>>>
>>> Regards, Achim
>>>
>>> sent from mobile device
>>> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <la...@gmail.com>:
>>>
>>>> Hi
>>>> I'm having a strange problem in ONE of my karaf installations.
>>>> I have a feature (mspEtg) which serves only as an 'envelope' for other
>>>> features (the features.xml lists several other features which should be
>>>> installed all at once).
>>>>
>>>> If I install mspEtg in one of my installation then 'nothing' happens.
>>>> mspEtg gets installed but none of the features listed in features.xml.
>>>> In another karaf installation it works fine.
>>>>
>>>> How can I find out what's going on?
>>>>
>>>> Thanks,
>>>> Laci
>>>>
>>>
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Hi
It's not a problem to start from scratch, since it's a development
installation. I just wanted to know if there's a way to fix such a
situation in case we run into it in a production environment. There it
would be nicer if I could "fix" it somehow instead of setting up a clean
installation.
Thanks anyway.
Regards,
Laci
On 31.07.2014 09:54, Achim Nierbeck wrote:
> Hi,
>
> right now I don't know of any means of "fixing" this file, need to
> inspect that a bit further.
> As it seems to work with a clean data dir, why don't you start from
> scratch?
>
> regards, Achim
>
>
>
> 2014-07-31 9:06 GMT+02:00 Laci Gaspar <lacigas@gmail.com
> <ma...@gmail.com>>:
>
> Hi
> Yes, there seems to be something wrong in the data/cache
> directory. With an empty data directory I can install the features.
>
> In the cache directory for the FeatureService there is a file
> FeaturesServiceState.properties which lists features which are not
> installed.
> Is there a possibility to rebuild that file? I don't quite
> understand the syntax of it.
>
> Regards,
> Laci
>
>
> On 30.07.2014 22:26, Achim Nierbeck wrote:
>> Hi,
>>
>> strange enough it's not installing any bundles.
>> Could you try this with a clean data folder?
>>
>> regards, Achim
>>
>>
>> 2014-07-30 9:14 GMT+02:00 Laci Gaspar <lacigas@gmail.com
>> <ma...@gmail.com>>:
>>
>> Very strange...
>> karaf says it's installing the features:
>> karaf@root> features:install -c -v mspEtg-development
>> Installing feature mspEtg-development 1.1.0-SNAPSHOT
>> Installing feature DeliverInvoiceToDossier-development
>> 1.1.0-SNAPSHOT
>> Installing feature DisableDossierDelivery-development
>> 1.1.0-SNAPSHOT
>>
>> but they are not there:
>> features:list | grep -i DeliverInvoiceToDossier
>> karaf@root>
>>
>> when I try to uninstall them:
>> karaf@root> features:uninstall
>> DeliverInvoiceToDossier-development
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' has multiple versions
>> installed (1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify
>> the version to uninstall.
>>
>> but they are not there...
>> karaf@root> features:uninstall
>> DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' with version
>> '1.0.0-SNAPSHOT' is not installed
>> karaf@root> features:uninstall
>> DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' with version
>> '1.1.0-SNAPSHOT' is not installed
>>
>> any ideas?
>>
>> Thanks,
>> Laci
>>
>>
>>
>>
>>
>>
>> On 29.07.2014 20:41, Achim Nierbeck wrote:
>>>
>>> Hi Laci,
>>> give installing with -c and -v a try.
>>> This way you'll see more of what is happening.
>>>
>>> Regards, Achim
>>>
>>> sent from mobile device
>>>
>>> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <lacigas@gmail.com
>>> <ma...@gmail.com>>:
>>>
>>> Hi
>>> I'm having a strange problem in ONE of my karaf
>>> installations.
>>> I have a feature (mspEtg) which serves only as an
>>> 'envelope' for other features (the features.xml lists
>>> several other features which should be installed all at
>>> once).
>>>
>>> If I install mspEtg in one of my installation then
>>> 'nothing' happens. mspEtg gets installed but none of the
>>> features listed in features.xml.
>>> In another karaf installation it works fine.
>>>
>>> How can I find out what's going on?
>>>
>>> Thanks,
>>> Laci
>>>
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
Re: feature install problem
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
right now I don't know of any means of "fixing" this file, need to inspect
that a bit further.
As it seems to work with a clean data dir, why don't you start from scratch?
regards, Achim
2014-07-31 9:06 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> Hi
> Yes, there seems to be something wrong in the data/cache directory. With
> an empty data directory I can install the features.
>
> In the cache directory for the FeatureService there is a file
> FeaturesServiceState.properties which lists features which are not
> installed.
> Is there a possibility to rebuild that file? I don't quite understand the
> syntax of it.
>
> Regards,
> Laci
>
>
> On 30.07.2014 22:26, Achim Nierbeck wrote:
>
> Hi,
>
> strange enough it's not installing any bundles.
> Could you try this with a clean data folder?
>
> regards, Achim
>
>
> 2014-07-30 9:14 GMT+02:00 Laci Gaspar <la...@gmail.com>:
>
>> Very strange...
>> karaf says it's installing the features:
>> karaf@root> features:install -c -v mspEtg-development
>> Installing feature mspEtg-development 1.1.0-SNAPSHOT
>> Installing feature DeliverInvoiceToDossier-development 1.1.0-SNAPSHOT
>> Installing feature DisableDossierDelivery-development 1.1.0-SNAPSHOT
>>
>> but they are not there:
>> features:list | grep -i DeliverInvoiceToDossier
>> karaf@root>
>>
>> when I try to uninstall them:
>> karaf@root> features:uninstall DeliverInvoiceToDossier-development
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' has multiple versions installed
>> (1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify the version to uninstall.
>>
>> but they are not there...
>> karaf@root> features:uninstall
>> DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' with version '1.0.0-SNAPSHOT' is not
>> installed
>> karaf@root> features:uninstall
>> DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
>> Error executing command: Feature named
>> 'DeliverInvoiceToDossier-development' with version '1.1.0-SNAPSHOT' is not
>> installed
>>
>> any ideas?
>>
>> Thanks,
>> Laci
>>
>>
>>
>>
>>
>>
>> On 29.07.2014 20:41, Achim Nierbeck wrote:
>>
>> Hi Laci,
>> give installing with -c and -v a try.
>> This way you'll see more of what is happening.
>>
>> Regards, Achim
>>
>> sent from mobile device
>> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <la...@gmail.com>:
>>
>>> Hi
>>> I'm having a strange problem in ONE of my karaf installations.
>>> I have a feature (mspEtg) which serves only as an 'envelope' for other
>>> features (the features.xml lists several other features which should be
>>> installed all at once).
>>>
>>> If I install mspEtg in one of my installation then 'nothing' happens.
>>> mspEtg gets installed but none of the features listed in features.xml.
>>> In another karaf installation it works fine.
>>>
>>> How can I find out what's going on?
>>>
>>> Thanks,
>>> Laci
>>>
>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Hi
Yes, there seems to be something wrong in the data/cache directory. With
an empty data directory I can install the features.
In the cache directory for the FeatureService there is a file
FeaturesServiceState.properties which lists features which are not
installed.
Is there a possibility to rebuild that file? I don't quite understand
the syntax of it.
Regards,
Laci
On 30.07.2014 22:26, Achim Nierbeck wrote:
> Hi,
>
> strange enough it's not installing any bundles.
> Could you try this with a clean data folder?
>
> regards, Achim
>
>
> 2014-07-30 9:14 GMT+02:00 Laci Gaspar <lacigas@gmail.com
> <ma...@gmail.com>>:
>
> Very strange...
> karaf says it's installing the features:
> karaf@root> features:install -c -v mspEtg-development
> Installing feature mspEtg-development 1.1.0-SNAPSHOT
> Installing feature DeliverInvoiceToDossier-development 1.1.0-SNAPSHOT
> Installing feature DisableDossierDelivery-development 1.1.0-SNAPSHOT
>
> but they are not there:
> features:list | grep -i DeliverInvoiceToDossier
> karaf@root>
>
> when I try to uninstall them:
> karaf@root> features:uninstall DeliverInvoiceToDossier-development
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' has multiple versions
> installed (1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify the
> version to uninstall.
>
> but they are not there...
> karaf@root> features:uninstall
> DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' with version
> '1.0.0-SNAPSHOT' is not installed
> karaf@root> features:uninstall
> DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' with version
> '1.1.0-SNAPSHOT' is not installed
>
> any ideas?
>
> Thanks,
> Laci
>
>
>
>
>
>
> On 29.07.2014 20:41, Achim Nierbeck wrote:
>>
>> Hi Laci,
>> give installing with -c and -v a try.
>> This way you'll see more of what is happening.
>>
>> Regards, Achim
>>
>> sent from mobile device
>>
>> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <lacigas@gmail.com
>> <ma...@gmail.com>>:
>>
>> Hi
>> I'm having a strange problem in ONE of my karaf installations.
>> I have a feature (mspEtg) which serves only as an 'envelope'
>> for other features (the features.xml lists several other
>> features which should be installed all at once).
>>
>> If I install mspEtg in one of my installation then 'nothing'
>> happens. mspEtg gets installed but none of the features
>> listed in features.xml.
>> In another karaf installation it works fine.
>>
>> How can I find out what's going on?
>>
>> Thanks,
>> Laci
>>
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
Re: feature install problem
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
strange enough it's not installing any bundles.
Could you try this with a clean data folder?
regards, Achim
2014-07-30 9:14 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> Very strange...
> karaf says it's installing the features:
> karaf@root> features:install -c -v mspEtg-development
> Installing feature mspEtg-development 1.1.0-SNAPSHOT
> Installing feature DeliverInvoiceToDossier-development 1.1.0-SNAPSHOT
> Installing feature DisableDossierDelivery-development 1.1.0-SNAPSHOT
>
> but they are not there:
> features:list | grep -i DeliverInvoiceToDossier
> karaf@root>
>
> when I try to uninstall them:
> karaf@root> features:uninstall DeliverInvoiceToDossier-development
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' has multiple versions installed
> (1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify the version to uninstall.
>
> but they are not there...
> karaf@root> features:uninstall
> DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' with version '1.0.0-SNAPSHOT' is not
> installed
> karaf@root> features:uninstall
> DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
> Error executing command: Feature named
> 'DeliverInvoiceToDossier-development' with version '1.1.0-SNAPSHOT' is not
> installed
>
> any ideas?
>
> Thanks,
> Laci
>
>
>
>
>
>
> On 29.07.2014 20:41, Achim Nierbeck wrote:
>
> Hi Laci,
> give installing with -c and -v a try.
> This way you'll see more of what is happening.
>
> Regards, Achim
>
> sent from mobile device
> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <la...@gmail.com>:
>
>> Hi
>> I'm having a strange problem in ONE of my karaf installations.
>> I have a feature (mspEtg) which serves only as an 'envelope' for other
>> features (the features.xml lists several other features which should be
>> installed all at once).
>>
>> If I install mspEtg in one of my installation then 'nothing' happens.
>> mspEtg gets installed but none of the features listed in features.xml.
>> In another karaf installation it works fine.
>>
>> How can I find out what's going on?
>>
>> Thanks,
>> Laci
>>
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Very strange...
karaf says it's installing the features:
karaf@root> features:install -c -v mspEtg-development
Installing feature mspEtg-development 1.1.0-SNAPSHOT
Installing feature DeliverInvoiceToDossier-development 1.1.0-SNAPSHOT
Installing feature DisableDossierDelivery-development 1.1.0-SNAPSHOT
but they are not there:
features:list | grep -i DeliverInvoiceToDossier
karaf@root>
when I try to uninstall them:
karaf@root> features:uninstall DeliverInvoiceToDossier-development
Error executing command: Feature named
'DeliverInvoiceToDossier-development' has multiple versions installed
(1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT). Please specify the version to uninstall.
but they are not there...
karaf@root> features:uninstall
DeliverInvoiceToDossier-development/1.0.0-SNAPSHOT
Error executing command: Feature named
'DeliverInvoiceToDossier-development' with version '1.0.0-SNAPSHOT' is
not installed
karaf@root> features:uninstall
DeliverInvoiceToDossier-development/1.1.0-SNAPSHOT
Error executing command: Feature named
'DeliverInvoiceToDossier-development' with version '1.1.0-SNAPSHOT' is
not installed
any ideas?
Thanks,
Laci
On 29.07.2014 20:41, Achim Nierbeck wrote:
>
> Hi Laci,
> give installing with -c and -v a try.
> This way you'll see more of what is happening.
>
> Regards, Achim
>
> sent from mobile device
>
> Am 29.07.2014 17:05 schrieb "Laci Gaspar" <lacigas@gmail.com
> <ma...@gmail.com>>:
>
> Hi
> I'm having a strange problem in ONE of my karaf installations.
> I have a feature (mspEtg) which serves only as an 'envelope' for
> other features (the features.xml lists several other features
> which should be installed all at once).
>
> If I install mspEtg in one of my installation then 'nothing'
> happens. mspEtg gets installed but none of the features listed in
> features.xml.
> In another karaf installation it works fine.
>
> How can I find out what's going on?
>
> Thanks,
> Laci
>
Re: feature install problem
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Laci,
give installing with -c and -v a try.
This way you'll see more of what is happening.
Regards, Achim
sent from mobile device
Am 29.07.2014 17:05 schrieb "Laci Gaspar" <la...@gmail.com>:
> Hi
> I'm having a strange problem in ONE of my karaf installations.
> I have a feature (mspEtg) which serves only as an 'envelope' for other
> features (the features.xml lists several other features which should be
> installed all at once).
>
> If I install mspEtg in one of my installation then 'nothing' happens.
> mspEtg gets installed but none of the features listed in features.xml.
> In another karaf installation it works fine.
>
> How can I find out what's going on?
>
> Thanks,
> Laci
>
feature install problem
Posted by Laci Gaspar <la...@gmail.com>.
Hi
I'm having a strange problem in ONE of my karaf installations.
I have a feature (mspEtg) which serves only as an 'envelope' for other
features (the features.xml lists several other features which should be
installed all at once).
If I install mspEtg in one of my installation then 'nothing' happens.
mspEtg gets installed but none of the features listed in features.xml.
In another karaf installation it works fine.
How can I find out what's going on?
Thanks,
Laci
Re: Disabling local repository creation on Karaf 3?
Posted by Christian Schneider <ch...@die-schneider.net>.
I strongly advise to not use the system repo as a local repository. It
is very difficult to make sure it will be read only.
Maven (aether) assumes that it can write to the local repository.
Eventually you can combine it with the offline setting of maven so it
knows it does not have to access other repos and write to the local
repository.
See:
http://stackoverflow.com/questions/5238769/is-there-a-way-to-disable-the-local-maven-repository
Having said that using the system repo as local repo might be a
workaround for now if you make sure aether does not write anything in
the system repo.
I think a real solution would be to either define a the system dir as
local in the sense of "does not need to be cached" or to define the
local repository as read only.
Another solution would be to tell maven to not use a local repository.
Till now I did not find such options in maven but I will dig some more.
If aether provides the option
we need then I am pretty sure we can make it configurable in karaf too.
Btw. Why do you need to avoid writing to the local repository? Is it
because of the additional space consumption on the hard disk or do you
have a different constraint?
I agree that it is a bit ugly that karaf copies the system repo to the
local repo but it is something that can just be ignored in most settings.
Christian
Am 29.07.2014 02:01, schrieb thully:
> To elaborate a bit, our application has two distinct builds - one for core
> developers, and one for users. In general, we want developers to easily be
> able to test updates to our core bundles (which are built using Maven). On
> the other hand, we want the end-user build to always use the core bundles in
> the installation directory, though we want to allow users to test add-on
> bundles stored in the Maven repository. In both cases, we don't want Karaf
> (or any of its components) creating additional copies of bundles or
> modifying the .m2 or system repos, and the user build of our application
> should run with a read-only Karaf installation directory.
>
> Based on what I've found, it seems that the best approach for the end-user
> distribution of our application is to put all our bundles in the system
> repository, use that as the local repository and enable .m2/repository as an
> external repository. In the developer environment, we will keep .m2 as the
> local repository and deploy our bundles there.
>
> I only see a few small issues at this point - we will be writing
> resolver-status.properties files to the system repo, and we will have copies
> of Karaf core bundles in both .m2 and system in the developer build. Also,
> on systems with read-only Karaf installation directories, we do get warnings
> about not being able to write resolver-status.properties. However, those
> seem tolerable - is there anything else we should be concerned about?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034479.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
To elaborate a bit, our application has two distinct builds - one for core
developers, and one for users. In general, we want developers to easily be
able to test updates to our core bundles (which are built using Maven). On
the other hand, we want the end-user build to always use the core bundles in
the installation directory, though we want to allow users to test add-on
bundles stored in the Maven repository. In both cases, we don't want Karaf
(or any of its components) creating additional copies of bundles or
modifying the .m2 or system repos, and the user build of our application
should run with a read-only Karaf installation directory.
Based on what I've found, it seems that the best approach for the end-user
distribution of our application is to put all our bundles in the system
repository, use that as the local repository and enable .m2/repository as an
external repository. In the developer environment, we will keep .m2 as the
local repository and deploy our bundles there.
I only see a few small issues at this point - we will be writing
resolver-status.properties files to the system repo, and we will have copies
of Karaf core bundles in both .m2 and system in the developer build. Also,
on systems with read-only Karaf installation directories, we do get warnings
about not being able to write resolver-status.properties. However, those
seem tolerable - is there anything else we should be concerned about?
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034479.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by Christian Schneider <ch...@die-schneider.net>.
These are two different caches. The difference between them is mainly
the lifecycle.
The bundle cache is an OSGi feature. It caches the loaded bundles of the
OSGi framework. So if you start karaf with -clean this cache is deleted.
The .m2 cache has a longer lifetime and can also be shared by different
karaf instances on the server.
To make life for admins easier I often suggest to always start karaf
with -clean and use boot features to define what should run. This makes
karaf very easy to understand for an admin
as he knows what will come up when karaf is started. Of course you loose
some of the OSGi dynamics this way but on the other hand some things are
a lot easier.
For example to upgrade your application simply point the feature repos
to the new version and restart.
So when using this mode of operation the .m2 repository is quite useful.
Christian
On 25.07.2014 20:45, thully wrote:
> This issue did raise another question - if Karaf 3 is using .m2 to cache
> bundles, what is the Karaf bundle cache in ${karaf.data} for? It seems like
> you're storing a redundant copy of each bundle, or 2 redundant copies in the
> case of the system repository... Caching makes perfect sense, but not when
> we already have a cached copy...
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034456.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
This issue did raise another question - if Karaf 3 is using .m2 to cache
bundles, what is the Karaf bundle cache in ${karaf.data} for? It seems like
you're storing a redundant copy of each bundle, or 2 redundant copies in the
case of the system repository... Caching makes perfect sense, but not when
we already have a cached copy...
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034456.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by Christian Schneider <ch...@die-schneider.net>.
Not sure. The reason for the different behaviour is that we now use the
orig maven libs while we had custom ones in 2.x.
Christian
Am 25.07.2014 18:36 schrieb "thully" <tm...@eng.ucsd.edu>:
> Our custom distribution includes everything we use in the system
> repository,
> and does not use remote repositories at all (we've even removed the default
> ones from the configuration). As such, this solution works fine for our
> case.
>
> With that said, is there a way to prevent Karaf from creating a directory
> for a repository on the local disk listed in the configuration if it
> doesn't
> already exist? This is a minor issue, though it still is something annoying
> that didn't happen on 2.x Karaf releases...
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034454.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
Our custom distribution includes everything we use in the system repository,
and does not use remote repositories at all (we've even removed the default
ones from the configuration). As such, this solution works fine for our
case.
With that said, is there a way to prevent Karaf from creating a directory
for a repository on the local disk listed in the configuration if it doesn't
already exist? This is a minor issue, though it still is something annoying
that didn't happen on 2.x Karaf releases...
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034454.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by Christian Schneider <ch...@die-schneider.net>.
Karaf uses the .m2 directory to cache jars it reads from remote
locations. So unless you have everything in your system dir already
disabling the local .m2 repository might severely affect performance of
your system.
You will also depend more on remote repositories if you do not have the
local cache. With the .m2 dir the bets are good you have all bundles
locally in the case your remote
repository becomes unavailable.
There is unfortunately the issue that karaf even caches jars from system
dir in .m2. This is due to the fact that we use the system dir like a
remote repo and caching these jars is how maven reacts by default in
this case.
Christian
Am 24.07.2014 16:45, schrieb thully:
> We have a project (Cytoscape) that uses a custom distribution of Karaf
> (currently 2.2.11) to manage OSGi/dependencies. We are in the process of
> upgrading to Karaf 3.0.1 for our next release, and have already done this on
> our development branch.
>
> For the most part, we've got everything working properly, though there is
> one nagging issue we're still dealing with. Since the upgrade to Karaf 3, it
> seems that a local Maven repository is created at ~/.m2 every time we start
> if one doesn't exist with copies of all the bundles we provide in the system
> repository. While it is possible to change
> org.ops4j.pax.url.mvn.localRepository in org.ops4j.pax.utl.mvn.cfg, that
> just changes the location. We're still stuck with the newly-created
> repository with an extra copy of everything, which wastes disk space
> unnecessarily (particularly on end-user systems where they won't be using
> Maven).
>
> Given that, is there a way to disable this repository creation? I'd prefer
> to continue looking in .m2 (so that developers can test updated bundles),
> but don't want to create it on end user systems.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Disabling local repository creation on Karaf 3?
Posted by Achim Nierbeck <bc...@googlemail.com>.
Could you give the latest 3.0.2-SNAPSHOT a try, cause those issues you're
facing have been fixed as far as I know.
This version is scheduled to be released soon, so it should be safe to test
with it, and will give us instant feedback in case it hasn't been :)
regards, Achim
2014-07-24 23:44 GMT+02:00 thully <tm...@eng.ucsd.edu>:
> I tried that, and it doesn't work. I have my system repository as the only
> one listed in org.ops4j.pax.url.mvn.repositories and
> org.ops4j.pax.url.mvn.defaultRepositories, and added
> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false to the config file.
> Even then, the .m2 directory still gets populated with all my system files
> -
> including Karaf core bundles.
>
> Any ideas? I know I could make my system repository the local repository,
> though that is undesirable as I would still like to have bundles installed
> in .m2 accessible to our project. That seemed to work fine in Karaf 2.2.11,
> though apparently something has changed in 3.0.1.
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034431.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: Disabling local repository creation on Karaf 3?
Posted by Stuart McCulloch <mc...@gmail.com>.
On 24 Jul 2014 23:06, "thully" <tm...@eng.ucsd.edu> wrote:
>
> I just noticed that after I replied. In any case, the main problem with
what
> you've suggested is that it removes .m2 entirely. What I want is to keep
.m2
> as an available repository, but *not* to copy the entire system repository
> there. That seemed to be how it worked in Karaf 2.2.11 - is there a way to
> get this behavior on 3.0.1? (using 3.0.2 isn't an option until it is
> released...)
>
You could try just adding your .m2 repository to
org.ops4j.pax.url.mvn.repositories (ie lock things down as per those
instructions, but then explicitly add .m2 back as a snapshots+releases
repository). That should let Pax-URL use it as a source of bundles, but not
cache extra content there.
> --
> View this message in context:
http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034434.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
I just noticed that after I replied. In any case, the main problem with what
you've suggested is that it removes .m2 entirely. What I want is to keep .m2
as an available repository, but *not* to copy the entire system repository
there. That seemed to be how it worked in Karaf 2.2.11 - is there a way to
get this behavior on 3.0.1? (using 3.0.2 isn't an option until it is
released...)
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034434.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by Stuart McCulloch <mc...@gmail.com>.
On 24 Jul 2014 22:44, "thully" <tm...@eng.ucsd.edu> wrote:
>
> I tried that, and it doesn't work. I have my system repository as the only
> one listed in org.ops4j.pax.url.mvn.repositories and
> org.ops4j.pax.url.mvn.defaultRepositories, and added
> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false to the config file.
^ note that the instructions I posted say to comment this line out
completely, because *any* setting of "defaultLocalRepoAsRemote" is treated
as true by Pax-URL, and you'll get ~/.m2/repository added to your repo list.
> Even then, the .m2 directory still gets populated with all my system
files -
> including Karaf core bundles.
>
> Any ideas? I know I could make my system repository the local repository,
> though that is undesirable as I would still like to have bundles installed
> in .m2 accessible to our project. That seemed to work fine in Karaf
2.2.11,
> though apparently something has changed in 3.0.1.
>
>
>
> --
> View this message in context:
http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034431.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
I tried that, and it doesn't work. I have my system repository as the only
one listed in org.ops4j.pax.url.mvn.repositories and
org.ops4j.pax.url.mvn.defaultRepositories, and added
org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false to the config file.
Even then, the .m2 directory still gets populated with all my system files -
including Karaf core bundles.
Any ideas? I know I could make my system repository the local repository,
though that is undesirable as I would still like to have bundles installed
in .m2 accessible to our project. That seemed to work fine in Karaf 2.2.11,
though apparently something has changed in 3.0.1.
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034431.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Disabling local repository creation on Karaf 3?
Posted by Andreas Kuhtz <an...@gmail.com>.
Hi,
Check the steps provided here:
http://karaf.922171.n3.nabble.com/Karaf-ignores-Bundles-in-KARAF-HOME-system-tp4034337p4034342.html
2014-07-24 16:45 GMT+02:00 thully <tm...@eng.ucsd.edu>:
> We have a project (Cytoscape) that uses a custom distribution of Karaf
> (currently 2.2.11) to manage OSGi/dependencies. We are in the process of
> upgrading to Karaf 3.0.1 for our next release, and have already done this
> on
> our development branch.
>
> For the most part, we've got everything working properly, though there is
> one nagging issue we're still dealing with. Since the upgrade to Karaf 3,
> it
> seems that a local Maven repository is created at ~/.m2 every time we start
> if one doesn't exist with copies of all the bundles we provide in the
> system
> repository. While it is possible to change
> org.ops4j.pax.url.mvn.localRepository in org.ops4j.pax.utl.mvn.cfg, that
> just changes the location. We're still stuck with the newly-created
> repository with an extra copy of everything, which wastes disk space
> unnecessarily (particularly on end-user systems where they won't be using
> Maven).
>
> Given that, is there a way to disable this repository creation? I'd prefer
> to continue looking in .m2 (so that developers can test updated bundles),
> but don't want to create it on end user systems.
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Disabling local repository creation on Karaf 3?
Posted by thully <tm...@eng.ucsd.edu>.
That actually just occurred to me, and it seems to work. However, it does
leave me with one undesirable side effect - an empty .m2 directory is
created on systems that don't have one. Is this a known issue, and is there
a workaround? To me, it seems like a regression from 2.2.11 - there I was
able to have .m2 as a repo without it being populated or the directory
created...
--
View this message in context: http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034436.html
Sent from the Karaf - User mailing list archive at Nabble.com.