Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project

2017-02-18 Thread Randy Leonard
To all:

This was actually quite easy to do.
 - Follow the instructions here: 
http://enroute.osgi.org/tutorial_eval/050-start.html 

 - But with one caveat… create bnd projects, *not maven projects*.  Then 
manually insert your pom.xml files into your bnd projects.

Once this is done, you get the hot-replacement provided by bnd during bundle 
development and can still use ‘mvn clean install’ to deploy to your m2 
repository.

The only caveat is you will need to synchronize dependencies in both bnd.bnd 
and pom.xml files.  But for our situation, only using maven for apache cxf 
client stubs… so pretty straightforward stuff.

We now have a number of OSGi enRoute workspaces which provide services to each 
other and Liferay portal workspaces.  Modifications to one workspace are 
immediately available in all other enRoute workspaces, and almost immediately 
within Liferay workspaces.  We only submit to continuous integration after 
changes spanning all workspaces are proven to be correct in the development 
environment.

Let me know if there is interest in how we have done this, and I can set up a 
git repository showing how this all works.

Randy

———

>> leveraged aQute.bnd.deployer.repository.LocalIndexedRepo within Liferay7 ..."
> Can you expand on what this means please? A use-case would be good.
Gradle works with several types of repositories, as listed here:
  - 
https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories
 

 
>

But the default repository type used by enRoute is not listed in the above 
link, and is instead defined by an enRoute/aQute plugin:
 - aQute.bnd.deployer.repository.LocalIndexedRepo


What this means:
  - Liferay does not natively support enRoute repositories unless it can be 
configured to import the aQute gradle plugin.


Ultimately, the issue is finding a repository scheme that both enRoute and 
Liferay can agree upon.  Seems there are three options:
1. Use Maven to build enRoute projects… ugh (dual build systems to synchronize, 
or lose hot-replacement offered by gradle-build approach)
2. Get Liferay to understand enRoute’s default repository type of 
LocalIndexedRepo
3. Get enRoute to generate Ivy repositories, as I believe Liferay will work 
with those just fine


Option 2 approach:
  - enRoute obtains LocalIndexedRepo support by importing aQute libraries at 
the start of the build.gradle file, and I could presumably do the same with 
Liferay projects
  - But I would still need to define the LocalIndexedRepo repositories 
somewhere, and further define dependencies via BSN notation?

Option 3 approach:
  - Modify build enRoute scripts and build.bnd files to leverage Ivy 
repositories
  - Register Ivy repositories and dependencies in Liferay’s build.gradle file


Hope I have made things more clear?  Your thoughts?

Randy

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] osgi broker bundle

2017-02-18 Thread chris . gray
As I said I haven't tried Moquette yet because I didn't yet have the need
to run an MQTT broker in an OSGi context. However the developer
specifically mentions the *possibility* of "running inside an embedded
OSGi broker like Concierge" so it would be worth contacting him about it.

https://projects.eclipse.org/proposals/moquette-mqtt

If you want to run a broker on an embedded device then probably your
device is some kind of "gateway" between a local network of
sensors/actuators and some kind of "cloud", am I close? In that case I
must say "Welcome to the Fog". :-)

In this use case you probably want your own broker to act in "bridging"
mode, and then you will find that mosquitto is not very dynamic - to
change the bridging configuration you need to stop mosquitto, update the
mosquitto.conf file and restart it, a mere "HUP" is not enough.  So any
OSGi service you create to control the mosquitto lifecycle is going to be
pretty ugly.

Whether Moquette is any better in this case remains to be seen, if the
developer's idea of OSGi is "slap on an Activator and a manifest" then
you're not much further ... how much this all matters depends on your use
case and how much dynamic behaviour you need ...


> oki :) i'll try thay out and will let you know how it was.
> As i said i'll need the broker as a bundle in my concierge container.
> Will update you in this next week on my findings.
> Have a great week end.
> Cheers! 😊
>
> On 17 Feb 2017 22:18, "Achim Nierbeck"  wrote:
>
>> must be a typo :)
>>
>> mosquitto, but that's a "standalone" mqtt broker. In general it should
>> be
>> enough, depending on your use-cases :)
>>
>>
>> https://projects.eclipse.org/projects/technology.mosquitto
>>
>> 2017-02-17 22:16 GMT+01:00 Mestiri Meher :
>>
>>> thanks guys for your answers.
>>> Achim are you talking about moquito or moquette ?
>>>
>>> Chris, does osgfying the moquette is sthg straight forward ? do you
>>> have
>>> a moquette or mosquitto already ogfyied as bundle ?
>>>
>>>
>>> On 17 Feb 2017 21:56, "Achim Nierbeck"  wrote:
>>>
>>> Hi,
>>>
>>> I second that, and I can tell mosquito works out nicely for me.
>>> If you look for a tool to investigate what data is sent to your mqtt
>>> broker, I suggest mqttfx.
>>> It's a nice tool to investigate your broker.
>>>
>>> regards, Achim
>>>
>>> 2017-02-17 20:42 GMT+01:00 :
>>>
 If you really only need MQTT then I think you should be looking at a
 dedicated MQTT broker rather than an all-singing, all-dancing message
 boroker like ActiveMQ. Moquette looks promising (caveat - I haven't
 tried
 it. yet)

 > Hi guys,
 >
 > I'm looking on how deploying an MQTT broker into an osgi
 environment.
 >
 > I'm running my osgi container in an embedded environment.
 >
 > I tried installing apache Karaf as it already has the ActiveMQ
 broker
 > integration easy, but i was not able to install it as it needs some
 junit
 > libraries that does not comply with the jre embedded.
 >
 > The other solution I'm thinking of is installing the ActiveMQ broker
 > against Felix.
 >
 > I found in an mvn repo an osgi bundle for the activeMQ but it needs
 its
 > dependencies.
 >
 > So I tried adding them as bundles but I faced an issue right now
 because
 > when I start that bundle it asks for a dependency that I can't find
 it.
 >
 > ->  Unable to resolve org.apache.activemq.activemq-osgi
 version=5.14.3:
 >missing requirement org.osgi.service.blueprint;
 version=[1.0.0,2.0.0)]
 >
 > Do you have an idea on how I have to proceed ?
 >
 > Thanks in advance :)
 > Meher
 > ___
 > OSGi Developer Mail List
 > osgi-dev@mail.osgi.org
 > https://mail.osgi.org/mailman/listinfo/osgi-dev


 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org
 https://mail.osgi.org/mailman/listinfo/osgi-dev

>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf  Committer & PMC
>>> OPS4J Pax Web  Committer
>>> & Project Lead
>>> blog 
>>> Co-Author of Apache Karaf Cookbook 
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf  Committer & PMC
>> OPS4J Pax Web 

Re: [osgi-dev] Components are not started, although marked with immediate=true

2017-02-18 Thread Tim Ward
Are any of the activate or deactivate methods blocking? DS lifecycle methods 
must not be blocking.

Tim

Sent from my iPhone

> On 17 Feb 2017, at 20:09, BJ Hargrave  wrote:
> 
> Seems like they should all be active. You may need to check with the 
> felix-dev list about Felix SCR's handling of this.
> --
> 
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>  
>  
> - Original message -
> From: "Thomas Driessen" 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: osgi-dev@mail.osgi.org
> Cc:
> Subject: [osgi-dev] Components are not started, although marked with 
> immediate=true
> Date: Fri, Feb 17, 2017 2:46 PM
>  
> Hi,
>  
> I have a problem with immediate services and hoped that you guys maybe can 
> help.
>  
> I'm currently trying to implement several services within one bundle (see 
> below for code).
> I have set all of them to be immediate (by immediate=true), but still, when I 
> start the OSGi container with my bundle in it, only Con1, InDataPort1 and 
> OutDataPort1 are active. The rest is satisfied but not active according to 
> felix.scr console output:
>  
> g! list
> BundleId Component Name Default State
>Component Id State  PIDs (Factory PID)
> [  10]   test.Con1  enabled
>[   0] [active  ]
> [  10]   test.InDataPort1  enabled
>[   1] [active  ]
> [  10]   test.OutDataPort1  enabled
>[   2] [active  ]
> [  10]   test.Process1  enabled
>[   3] [satisfied   ]
> [  10]   test.Thread1_1  enabled
>[   4] [satisfied   ]
> [  10]   test.Thread1_2  enabled
>[   5] [satisfied   ] 
>  
> Am I doing something wrong?
> I assumed that all services should be started as soon as they are satisfied.
>  
> Any advice is highly appreciated.
>  
> Kind regards,
> Thomas
>  
> 
> @Component(immediate = true, service = IProcess.class, property = 
> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Process1")
> public class Process1 implements IProcess {
>   
>  @Reference(target = "(uid=test.Thread1_1)")
>  private volatile IPeriodicThread thread1;
>  
>  @Reference(target = "(uid=test.Thread1_2)")
>  private volatile IPeriodicThread thread2;
> }
>  
>  
> @Component(service = IPeriodicThread.class, property = 
> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_1", immediate = 
> true)
> public class Thread1_1 implements IPeriodicThread {
>   
>  @Reference(target = "(uid=test.OutDataPort1)")
>  private volatile IOutDataPort outport;
>   
>  @Activate
>  public void initialize_FW() {
>init();
>  }
>  
>  @Deactivate
>  public void finalize_FW() {
>deinit();
>  }
> }
>  
>  
> @Component(service = IPeriodicThread.class, property = 
> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_2", immediate = 
> true)
> public class Thread1_2 implements IPeriodicThread {
>   
>  @Reference(target = "(uid=test.InDataPort1)")
>  private volatile IOutDataPort outport;
>   
>  @Activate
>  public void initialize_FW() {
>init();
>  }
>  
>  @Deactivate
>  public void finalize_FW() {
>deinit();
>  }
> }
>  
>  
> @Component(service = IOutDataPort.class, property = "uid=test.OutDataPort1", 
> immediate = true)
> public class OutDataPort1 implements IOutDataPort {
> 
>  @Reference(target = "(target=test.OutDataPort1)", cardinality = 
> ReferenceCardinality.OPTIONAL, policyOption = ReferencePolicyOption.GREEDY)
>  private volatile IPortConnection incomingPortConnections;
>  
>  private volatile Set outgoingPortConnections = new ConcurrentSkipListSet();
>  
>  @Reference(target = "(source=test.OutDataPort1)", cardinality = 
> ReferenceCardinality.OPTIONAL, policyOption = ReferencePolicyOption.GREEDY)
>  public void addOutgoingPortConnection(final IPortConnection con) {
>outgoingPortConnections.add(con);
>  }
>  
>  public void removeOutgoingPortConnection(final IPortConnection con) {
>outgoingPortConnections.remove(con);
>  }
> }
>  
>  
> @Component(service = IInDataPort.class, property = "uid=test.InDataPort1", 
> immediate = true)
> @SuppressWarnings("all")
> public class InDataPort1 implements IInDataPort {
> 
>  @Reference(target = "(target=test.InDataPort1)", cardinality = 
> ReferenceCardinality.OPTIONAL, policyOption = ReferencePolicyOption.GREEDY)
>  private volatile IPortConnection incomingPortConnections;
>  
>  private volatile Set outgoingPortConnections = new ConcurrentSkipListSet();
>  
>  @Reference(target = "(source=test.InDataPort1)", cardinality = 
> ReferenceCardinality.OPTIONAL, policyOption = ReferencePolicyOption.GREEDY)
>  public void addOutgoingPortConnection(final IPortConnection con) {
>outgoingPortConnections.add(con);
>  }
>  
>  public void removeOutgoingPortConnection(final IPortConnection con) {
>outgoingPortConnections.remove(con);
>  }
> }
>  
>  
> @Component(service = IPortConnection.class, property = { 
>