Re: OSGi-Bundles Distribution, generating the config.ini
2009/6/12 itripl itriple...@trash-mail.com
well, that do not sound like the best way. I heard there is a way to do it
with ant-contrib, but at the moment, I do not have the time to find out
how.
Maybe I can try it in a few weeks. When it does not work, I'm going to try
to create a maven plugin.
FYI, in case you need example code showing how to create a config.ini file:
http://paxrunner.ops4j.org/space/Pax+Runner
https://scm.ops4j.org/repos/ops4j/projects/pax/runner/pax-runner-platform-equinox/src/main/java/org/ops4j/pax/runner/platform/equinox/internal/EquinoxPlatformBuilder.java
several people from OPS4J have also been looking at assembling an OSGi
application as a zip (http://issues.ops4j.org/browse/PAXCONSTRUCT-91)
also the next OSGi spec (r4.2) defines a standard Java API for launching
frameworks, which means you can write your own launcher without having
to mess about with framework specific config files, etc.
HTH
Agemo Cui wrote:
I ever got each subproject to generate a resource file called
filter.properties in the target directory directly.
If the subproject's name is example, then the resource file has the
following content:
example.build.finalName=${pom.build.finalName}
Then I created a new subproject called resource-filter in the last(it
will
be the last subproject to be built) and its packaging mode is pom(It
looks
like only this mode could just filter resource without package).
The work of this subproject was to filter the config.ini by reference
to
all those generated filter.properties for each subproject.
Sure, the config.ini was configured like ${example.build.finalName}.
However, I just felt not very well to use this way mentioned.
But it did can fix the problem.
Expect a better way. Actually, if you can, I think a maven plugin could
be
created for this purpose only. That would be great.
Agemo
On Tue, Jun 2, 2009 at 5:22 AM, itripl
itriple...@trash-mail.comwrote:
Hi all,
I am trying to distribute OSGi-bases Application using Maven. In best
case,
when I distribute the application to other people not using Maven or
OSGi,
they just should klick a start.bat and the application should start
including the OSGi-Framework.
At the moment, I am using the Maven-Bundle-Plugin to generate the
manifest.mf and the Maven-Assembly-Plugin to package all Bundles to a
.zip
including all other resources. The problem is, that I don't know hot to
generate the config.ini and the start.bat. The config.ini is important,
because all necessary bundles should start, when the OSGi-Framework
starts.
I read somewhere, that it is possible to do this using the
Maven-Dependency-Plugin, but I just couldn't figure out, how to do this.
I have 3 projects:
- translatorService
- translatorClient
- multiProject - Project with Dependencies to the Service and Client to
have them in the .zip built by Maven-Assembly-Plugin
A extract from the multiProjects pom.xml
dependencies
dependency
groupIdde.si.osgi/groupId
artifactIdtranslatorService/artifactId
version0.0.1/version
/dependency
dependency
groupIdde.si.osgi/groupId
artifactIdtranslatorClient/artifactId
version0.0.1/version
/dependency
/dependencies
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorassembly.xml/descriptor
/descriptors
/configuration
executions
execution
idmake-assembly/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
/plugin
And a extract from the translatorClient
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.0/version
extensionstrue/extensions
configuration
manifestLocation${basedir}/META-INF/manifestLocation
instructions
Private-Package${bundle.namespace},${bundle.namespace}.internal/Private-Package
Export-Package${bundle.namespace}/Export-Package
Bundle-Activator${bundle.namespace}.internal.Activator/Bundle-Activator
/instructions
/configuration
executions
execution
phaseprocess-class/phase
goals
goalmanifest/goal
/goals
/execution
/executions
/plugin
How do you manage your OSGi-Applications using Maven?
--
View this message in context:
http://www.nabble.com/OSGi-Bundles-Distribution%2C-generating-the-config.ini-tp23827768p23827768.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands,
Re: OSGi services as extension point mechanism
Thanks Neil! I see the issues now. Basically all the problems in that particular eclipse implementation, not in the idea of extension points. BTW which would you go with DS or iPOJO to implement plugins? On Fri, Jun 12, 2009 at 5:27 PM, Neil Bartlett njbartl...@gmail.com wrote: Hi Dmitry, Since you ask, here are the top three issues I have with Eclipse Extensions: 1) Bundles offering either extensions or extension points must be singletons, i.e. you can only have one version installed, and there is no support for checking the compatibility of an extension with the API of the extension point by version. 2) Lack of control. Extensions are read from any bundle that has a plugin.xml and is at least RESOLVED. But we have little control over the RESOLVED state, and in particular there is no way to request that a bundle be unresolved except by fully uninstalling it. DS on the other hand works with ACTIVE state, which means we have explicit control of the visibility of bundles through activating and deactivating them. 3) Bolted-on dynamics. The Extension Registry APIs were designed before Eclipse used OSGi as its underlying module system, and thus before it was possible to dynamically install and uninstall bundles at runtime. They have since been extended with dynamic capabilities but the extensions are difficult to use, and in practice very few Eclipse plug-in developers pay any attention to dynamics. This is why Eclipse *still* insists that you restart after installing new plug-ins, four years after adopting OSGi. Since DS offers the same laziness benefits as extensions, the one remaining advantage of extensions versus DS is their support for richer and more structured metadata, in the form of an XML tree versus the name/value pairs used with services/DS. Regards, Neil On Thu, Jun 11, 2009 at 11:10 PM, Dmitry Skavishskav...@gmail.com wrote: Neil, The extension point mechanism Eclipse uses is NOT based on OSGi It IS based on OSGi. It is an example of the extender pattern which is common in OSGi. But it is not based on Services. Could you please elaborate a bit how it is based on OSGi? I mean I understand that Eclipse is based on OSGi itself and the plugins are OSGi bundles, I mean how Eclipse extension points mechanism is based on OSGi? If you have some link that would be great! If I want to use say declarative services (or simply services) as extension points mechanism it seems I have only one key: service interface, that is when I declare my service I just announce to the framework that I have a service, I don't specify which extension point this service is intended to extend. Correct, this an advantage of services -- they do not need advance knowledge of which bundles will consume them. It's an advantage if you need a service, but extension point is not exactly a service. For example you have an interface Command and there are two different extension points (A and B) which could be extended by those commands. I am creating a plugin to extend A, I don't want to extend B because my commands are for A only. And there is some other plugin which extends B using its own commands. The problem here is that my plugin which extend A and this other plugin which extend B they both use this very convenient interface Command. So they cannot just declare that they provide services Command because A and B will try to consume commands from both of them. Of course I can create unique interfaces for A and B and extend them through those unique interfaces, but in many cases it's artificial. Basically I am forced to create those unique interfaces because interface is the only key here. I guess I can add some parameter to the service (i.e. extension point name) and have the framework code filter out services by this parameter when requested. It could work, but I don't really like this approach because these parameters are somewhat soft constraints and not enforced by OSGi in any way. It sounds like you want to ensure that services can only be consumed by certain bundles, like Eclipse Extensions. Why? because those are not services. they are extensions. a service provides some service and does not know about how it is used. an extension in many cases extends a very specific functionality and very often aware what it extends and how it is used. Another reason I don't like it is because I suspect that the service (extension) will be loaded when a component requesting this service is loaded, but I want it to be loaded only when I specifically requested this service. If you use Declarative Services then the implementation object for the service will be loaded lazily, i.e. only when a consumer actually attempts to use it. Because of this, in my opinion, DS has most of the advantages of Eclipse's Extensions, and none of the
What is the correct service import behavior?
Hello,
Seems I have been chewing on the service dynamics issue forever. Just as I
though I got a workable concept about tracking and releasing services I stumble
on a contradicting concept. The problem is this:
According to my understanding it is not acceptable importer behavior to ever
call service objects that are unregistered. Achieving this requires the service
to be tracked and every piece of code that calls the service be synchronized
with the tracking code. I'll name this the dedicated lock approach:
private Object lock;
private Hello service;
void set(Hello service) {
synchronized (lock) {
this.service = service;
}
}
Hello get() {
synchronized (lock) {
if (service == null) {
throw new ServiceUnavailableException();
}
return service;
}
}
void usefulMethod() {
synchronized (lock) {
get().greet(World);
}
}
Some say we should never call out from the bundle while holding a lock but I
think we are safe if we use a dedicated private lock for every tracked service.
In any case I can't think of any other way to be safe at all times. Lately
however I have been encountering the local-cache approach, which seems to
state we don't need to be that paranoid. E.g.
void usefulMethod() {
Hello service = get();
/* At this spot right here the service can go down! */
service.greet(World);
}
Here we risk calling a service in an undetermined state. Do we expect every
exporter to invalidate his objects to keep us safe? E.g. the exporter must keep
a closed flag around, mark the service as invalid in a thread-safe manner, and
start tossing exceptions at callers from that point on.
iPojo follows the local cache approach - right Richard?
Peaberry follows the dedicated lock approach - right Stuart?
I'd be grateful if you help me compare these import modes. That is if I got it
right who uses what :)
Cheers,
Todor
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: What is the correct service import behavior?
On 6/14/09 5:08 PM, Todor Boev wrote:
Some say we should never call out from the bundle while holding a lock but I
think we are safe if we use a dedicated private lock for every tracked service.
In any case I can't think of any other way to be safe at all times. Lately
however I have been encountering the local-cache approach, which seems to
state we don't need to be that paranoid. E.g.
void usefulMethod() {
Hello service = get();
/* At this spot right here the service can go down! */
service.greet(World);
}
Here we risk calling a service in an undetermined state. Do we expect every
exporter to invalidate his objects to keep us safe? E.g. the exporter must keep
a closed flag around, mark the service as invalid in a thread-safe manner, and
start tossing exceptions at callers from that point on.
iPojo follows the local cache approach - right Richard?
Yes. iPOJO is of the philosophy that service departures will likely lead
to errors, so you are better off being prepared to catch them and fail
gracefully, sort of like errors in distributed computing. Even if you
hold a dedicated lock, there is no guarantee that calling a method on
the service object won't throw an exception. Locks don't stop the
service from going away (think bluetooth device), in some cases if it
goes away it is gone, period.
Given that you have to deal with this case anyway, you might as well
just treat all services the same way rather than trying to figure which
is which case. This will become even more complicated as people start
using distributed services from R4.2.
But depending on your application and what control you have over
everything, then either approach is fine.
- richard
Peaberry follows the dedicated lock approach - right Stuart?
I'd be grateful if you help me compare these import modes. That is if I got it
right who uses what :)
Cheers,
Todor
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: What is the correct service import behavior?
Richard S. Hall wrote: Yes. iPOJO is of the philosophy that service departures will likely lead to errors, so you are better off being prepared to catch them and fail gracefully, sort of like errors in distributed computing. Even if you hold a dedicated lock, there is no guarantee that calling a method on the service object won't throw an exception. Locks don't stop the service from going away (think bluetooth device), in some cases if it goes away it is gone, period. I completely agree. This is all about crashing safely, not trying to avoid crashes with synchronization. Crashing safely means we always get an exception when trying to access a missing service. If we allow some final calls to an unregistered service object we risk getting random return values and other behavior that can corrupt the importing bundle. Here the question is if we should count on the exporter to place extra invalidation code in his service object so it consistently throws exceptions at late retainers? Or should we take matters in our own hands and guarantee a ServiceUnavailableException will always be thrown from our own internal tracking code? Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: What is the correct service import behavior?
Todor Boev wrote: Richard S. Hall wrote: Yes. iPOJO is of the philosophy that service departures will likely lead to errors, so you are better off being prepared to catch them and fail gracefully, sort of like errors in distributed computing. Even if you hold a dedicated lock, there is no guarantee that calling a method on the service object won't throw an exception. Locks don't stop the service from going away (think bluetooth device), in some cases if it goes away it is gone, period. Ah..I get it! You mean we should not bother to block the unexport of the service when the framework calls into our ServiceListener because that won't keep the service functional until our last calls to it return. Come to think of a service can throw an exception due to a missing transitive dependency anyway. Seems I am still not completely free from that safe mentality :P Seems in the end we should count on the service exporter to toss exceptions at us rather than do random nastiness out of a partially destroyed service. Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
