Re: How t configure Karaf to not look for newest SNAPSHOTs

[lichtin]

Thank you all for the tips.
Indeed in my case I can simply remove all repositories 

org.ops4j.pax.url.mvn.repositories=

and this works very well to avoid any remote lookups.

- Martin

PS: Still baffling that "org.ops4j.pax.url.mvn.globalUpdatePolicy" has had
no effect.


Guillaume Nodet-2 wrote
> Well, disabling snapshot repositories as indicated by JB should work.
> The default list looks like (in etc/org.ops4j.pax.url.mvn.cfg):
> 
> http://repo1.maven.org/maven2@id=central,
> http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
> http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
> http://zodiac.springsource.com/maven/bundles/release@id=gemini,
> http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases,
> https://oss.sonatype.org/content/repositories/snapshots@id=sonatype.snapshots.deploy@snapshots@noreleases,
> https://oss.sonatype.org/content/repositories/ops4j-snapshots@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases,
> http://repository.springsource.com/maven/bundles/external@id=spring-ebr-repository@snapshots@noreleases
> 
> So go for something like
> 
> http://repo1.maven.org/maven2@id=central,
> http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
> http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
> http://zodiac.springsource.com/maven/bundles/release@id=gemini
> 
> 
> Or maybe even
> 
> http://repo1.maven.org/maven2@id=central
> 
> Cheers,
> Guillaume
> 
> 2016-09-16 11:35 GMT+02:00 Markus Rathgeb 

> maggu2810@

> :
> 
>> Hi,
>>
>> I assume he wants to configure the local repository as the only one that
>> provides snapshots. So snapshots from .m2 are used, but no lookup for
>> newer
>> remote provided versions is done.





--
View this message in context: 
http://karaf.922171.n3.nabble.com/How-t-configure-Karaf-to-not-look-for-newest-SNAPSHOTs-tp4048075p4048085.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: configuration admin files with property references in the values: how's it done?

[Benson Margulies]

Never mind, I worked out for myself that fileinstall does the job.


On Fri, Sep 16, 2016 at 11:17 AM, Benson Margulies  wrote:
> I've been asked to try an experiment in moving some of the code we run
> in Karaf into a minimal Felix container deployment. I've run into one
> snag: Some of my .cfg files in Karaf take advantage of writing values
> that contain system property references, like
> ${karaf.etc}/something/something.
>
> I had a quick look around in Karaf source, but I failed to find the
> implementation of this, which would appear to need to be an
> alternative ConfigurationAdmin or at least Felix confadmin persistence
> manager. If someone could give me a pointer, I'd be grateful.

configuration admin files with property references in the values: how's it done?

[Benson Margulies]

I've been asked to try an experiment in moving some of the code we run
in Karaf into a minimal Felix container deployment. I've run into one
snag: Some of my .cfg files in Karaf take advantage of writing values
that contain system property references, like
${karaf.etc}/something/something.

I had a quick look around in Karaf source, but I failed to find the
implementation of this, which would appear to need to be an
alternative ConfigurationAdmin or at least Felix confadmin persistence
manager. If someone could give me a pointer, I'd be grateful.

Re: Karaf Cellar - updating a bundle in cluster

[Sergiy Shyrkov]

Thank you very much JB!
Will it be available after push here:  
https://github.com/apache/karaf-cellar ?

Or it will be other location?

Kind regards
Sergiy

On Thu, 15 Sep 2016 15:24:44 +0200, Jean-Baptiste Onofré   
wrote:



I will rebase & push.

Regards
JB

On 09/15/2016 02:11 PM, Sergiy Shyrkov wrote:

Hello,


I have bundle-update on a local branch (I did feature update too).

:-) Is there any chance I can get those changes (even as a diff file for
now)?

Kind regards
Sergiy

On Thu, 15 Sep 2016 14:07:10 +0200, Jean-Baptiste Onofré
 wrote:


Hi,

I have bundle-update on a local branch (I did feature update too).

And good idea for modified (to be tested).

Regards
JB

On 09/15/2016 02:00 PM, Sergiy Shyrkov wrote:

Hello JB,

thank you for the prompt reply!

you can perform cluster:bundle-update / cluster:bundle-install, the
event will trigger an update on the nodes.

You mean cluster:bundle-uninstall and then bundle-install here
(bundle-update does not exist)?


The synchronizer (during pull) can do: if the bundle is on the
cluster, and the cluster is also present locally on the node, then we
trigger bundle update (systematically).

Yes, sounds good. In order to avoid synchronizer from triggering
unneeded updates, we could perhaps additional check that:

new URL(state.getLocation()).openConnection().getLastModified() >
localBundle.getLastModified()

What do you think?

Kind regards
Sergiy

On Thu, 15 Sep 2016 13:40:12 +0200, Jean-Baptiste Onofré
 wrote:


Hi Sergiy,

It depends at which level.

When the cluster is "live", you can perform cluster:bundle-update /
cluster:bundle-install, the event will trigger an update on the  
nodes.


The question is more when a node joins the cluster (and so the
Synchronizer is called). IMHO, it's not a good idea to introduce a
timestamp. The synchronizer (during pull) can do: if the bundle is on
the cluster, and the cluster is also present locally on the node,  
then

we trigger bundle update (systematically).

Regards
JB

On 09/15/2016 01:34 PM, Sergiy Shyrkov wrote:

Hello guys,

I would like to ask you about the recommended way of implementing a
"bundle update" in cluster with Karaf Cellar.
Basically, Cellar has no notion of an "update" for existing bundle.  
As

we are working also with SNAPSHOTs of bundles we are missing the
possibility to "update" a bundle in cluster.

What would be possible solutions for this?
We were looking at adjusting
org.apache.karaf.cellar.bundle.BundleState
to introduce lastUpdated timestamp there and in the  
BundleSynchronizer

check it and perform bundle.update() for those bundles, where
"cluster"
lastUpdated is after the local one.

Thank you in advance!

Kind regards
Sergiy
















--
Sergiy Shyrkov
Software Architect
Jahia Solutions Group SA
http://www.jahia.com

Re: Unable to use http://karaf.apache.org/xmlns/shell/v1.0.0

[jochenw]

Hi,

maybe it should be up to kotoole to attache something to the Jira.

In my case, the error with http://karaf.apache.org/xmlns/shell/v1.0.0 says:

org.xml.sax.SAXParseException; systemId:
bundle://80.0:2/org/apache/karaf/shell/console/commands/karaf-shell-1.1.0.xsd;
lineNumber: 28; columnNumber: 44; src-import.3.1: Namespace-Attribut
"http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0; eines
-Elementinformationselements muss mit dem targetNamespace-Attribut
"http://karaf.apache.org/xmlns/shell/v1.1.0; des importierten Dokuments
identisch sein.

(sorry about the German - I have German Windows on my notebook).

I tried to narrow that down, and commented all other things from by
blueprint.xml. And - it works. But as soon as taking in the section with
cm:property-placeholder, the error comes back.

I also tried it with the voting tutorial from here: 
https://github.com/cschneider/Karaf-Tutorial/tree/master/voting
   , but
replacing the karaf version by 4.0.6 and installing CXF 3.1.7 when running
it instead of 2.7.7. Works perfectly, but as soon as adding 








to the blueprint file command.xml, the error comes up.

Regards,
Jochen





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Unable-to-use-http-karaf-apache-org-xmlns-shell-v1-0-0-tp4047826p4048081.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: How t configure Karaf to not look for newest SNAPSHOTs

[Guillaume Nodet]

Well, disabling snapshot repositories as indicated by JB should work.
The default list looks like (in etc/org.ops4j.pax.url.mvn.cfg):

http://repo1.maven.org/maven2@id=central,
http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
http://zodiac.springsource.com/maven/bundles/release@id=gemini,
http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases,
https://oss.sonatype.org/content/repositories/snapshots@id=sonatype.snapshots.deploy@snapshots@noreleases,
https://oss.sonatype.org/content/repositories/ops4j-snapshots@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases,
http://repository.springsource.com/maven/bundles/external@id=spring-ebr-repository@snapshots@noreleases

So go for something like

http://repo1.maven.org/maven2@id=central,
http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
http://zodiac.springsource.com/maven/bundles/release@id=gemini


Or maybe even

http://repo1.maven.org/maven2@id=central

Cheers,
Guillaume

2016-09-16 11:35 GMT+02:00 Markus Rathgeb :

> Hi,
>
> I assume he wants to configure the local repository as the only one that
> provides snapshots. So snapshots from .m2 are used, but no lookup for newer
> remote provided versions is done.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: How t configure Karaf to not look for newest SNAPSHOTs

[Markus Rathgeb]

Hi,

I assume he wants to configure the local repository as the only one that
provides snapshots. So snapshots from .m2 are used, but no lookup for newer
remote provided versions is done.

Re: How t configure Karaf to not look for newest SNAPSHOTs

[Jean-Baptiste Onofré]

Hi Martin,

you can configure local repository as remote and remove the @snapshot 
flag. Then it will only consider release.


Regards
JB

On 09/16/2016 08:16 AM, Martin Lichtin wrote:

Hi

I have several bundles and features that are -SNAPSHOT versioned,
residing in $HOME/.m2/repository (together with all the other bundles)

Karaf (v3.0.8) should _not_ attempt to look for a newer version, but
simply use what is there. Is this possible?
I have org.ops4j.pax.url.mvn.globalUpdatePolicy=never set in
org.ops4j.pax.url.mvn.cfg
but still I see how Karaf tries to contact remote repos.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

How t configure Karaf to not look for newest SNAPSHOTs

[Martin Lichtin]

Hi

I have several bundles and features that are -SNAPSHOT versioned, residing in 
$HOME/.m2/repository (together with all the other bundles)

Karaf (v3.0.8) should _not_ attempt to look for a newer version, but simply use 
what is there. Is this possible?
I have org.ops4j.pax.url.mvn.globalUpdatePolicy=never set in 
org.ops4j.pax.url.mvn.cfg
but still I see how Karaf tries to contact remote repos.