Niclas - Please see comments inline..../Thomas
-----Original Message-----
From: Niclas Hedhman [mailto:[email protected]]
Sent: Monday, March 07, 2011 1:28 AM
To: Glaeser, Thomas
Subject: Re: Gradle's OSGi plugin
You dropped the list, but;
<TG>Sorry, I thought I did a reply all.</TG>
I don;t know why my point is so hard to understand... Let;s go with an
hypothetical example;
<TG>I feel the same over here. Looks like we don't speak the same language. I
believe it is overdue to get together on the phone and talk. Please let me know
outside of this thread how I can reach you.</TG>
ProjectA dependsOn ProjectB. ProjectA's bundle comes to let's say 100kB, and
ProjectB is 15MB. ProjectB doesn't produce any OSGi bundle output. ProjectA
therefor wants to embed the ProjectB's jars. I think you are with me so far.
Now, ProjectA is NOT primarily a OSGi project, but used for standalone apps, or
is inside WAR deployments.
So, IF you ship ProjectA's primary jar, for SE/EE deployment, with the ProjectB
dependencies inside, you will have massive bloat, as the Java SE/EE can not
consume ProjectB's jars inside ProjectA's jar.
<TG>Not true for EE. But that's not what I'm proposing. In fact for the SE case
I would consider this rather bad design. You are misusing OSGi's bundle
classpath just to avoid bundleizing projectB. If you follow this path you will
end up with a bunch of ueber-jars. You are just moving from jar hell to bundle
hell. I know this can be done, but there are very rare cases that would justify
such an approach. You better bundleize projectB.</TG>
This is a usecase that MUST be supported, since it affects a lot of open source
projects out there. Examples; Qi4j, CXF, ActiveMQ, Camel, and many, many
others. This can be solved by producing one artifact for the 100kB jar that is
meant for Java SE/EE usage, and another 15.1MB jar that is standalone, drop-in
bundle which doesn't need 25 other bundles (not available, and must be created
by the consumer) to run.
<TG>You are justifying this use case by arguing that a large jar embeds a small
jar. That you have to produce two artifact versions from your projectB gives
some indication that we have a design issue here. Why not producing the
resulting artifact for projectB as an OSGi bundle only? Together with the
bundle from projectA you get two OSGi-aware bundles with no embedded jars that
can be used in Java SE/EE world +and+ with OSGi. In your Gradle script for
projectA you simple declare your project dependency this way:
dependencies {
providedCompile project(':projectB')
}
The only difference is that when moving from the java-plugin to the new
osgi-plugin you have to change "compile" to "providedCompile". When moving from
the war-plugin to the new osgi-plugin you don't have to change anything.
</TG>
Second point in hand;
OSGi is NOT about deployment descriptors, unlike Java EE world. OSGi bundles
SHOULD (strongly so) be completely agnostic to which container they run in. If
you have not understood this, then you are missing the whole point of OSGi. I
created Pax Runner to be able to validate that created bundles are compliant
with the OSGi spec by running them on the 3 readily available containers.
Others (Toni Menzel) created a test framework, Pax Exam, on top of Pax Runner
to hammer home the whole point some more.
THEREFOR; deployment descriptors are NOT part of a OSGi plugin's
responsibility, IMNSHO.
<TG>No objections, agree on the statements to the subject. That's why the
deployment part would be covered by additional container specific plugins.
PaxExam is a good example. Please have a look at
http://wiki.ops4j.org/display/paxexam/Using+Pax+Runner+provisioning+methods.
Please notice that the ServiceMix +features+ descriptor is supported here. This
should be provided by an additional servicemix-plugin. To add support for
Equinox an equinox-plugin would add support for the Eclipse +feature+
descriptor. The same could be true for other frameworks. But now comes the
important part: These descriptors SHALL be generated from the Gradle dependency
configurations. That's why it is important to have different sets of
dependencies already available with the new osgi-plugin.</TG>
I acknowledge that there is a 3rd usecase; WAB. We have not yet seen a lot of
these out in the wild, so far, but likely to increase some. As I see it ATM, it
is 'just' a subset of requirements from Usecase 1 above, so I imagine that the
convention is; "wab=true" and that pulls in the runtime dependencies with a WAR
compatible layout, as described by Kriens.
<TG>There are no three use cases; there is only one: OSGi bundles get deployed
into target-containers. These target-containers can be as simple as an
OSGi/Minimum execution environment and as complex as a Spring DM target
platform. The new osgi-plugin MUST support all of them equally. Luckily Gradle
provides this support out of the box by allowing to divide your dependencies
into several configurations.</TG>
I hope the above makes sense, otherwise I don't know how to explain it.
<TG>Feeling the same over here. Cheers.</TG>
Cheers
Niclas
On Mon, Mar 7, 2011 at 1:51 AM, Glaeser, Thomas <[email protected]>
wrote:
> Niclas - Please see comments inline..../Thomas
>
> -----Original Message-----
> From: Niclas Hedhman [mailto:[email protected]]
> Sent: Saturday, March 05, 2011 9:47 AM
> To: Glaeser, Thomas
> Subject: Re: Gradle's OSGi plugin
>
> On Fri, Mar 4, 2011 at 8:44 PM, Glaeser, Thomas
> <[email protected]> wrote:
>> Now I would argue that an OSGi bundle is very similar to a WAR. I
> believe that Peter Kriens documentation about WAB confirms this. Both
> are container applications.
>
> This is an incorrect assertion/conclusion.
>
> <TG>I'm using WAB as an example only to make one simple point. OSGi
> bundles require a container to run. In contrast to plain Java, with
> OSGi we deploy (provision) the bundle into a container. This is very
> similar to deploying a WAR into a Java EE container.</TG>
>
> Only the Web Application Bundle feature that was introduced as a spec
> in OSGi 4.2 has any resemblance to WAR files. The vast majority of
> bundles available, produced and upcoming are, and will be, regular
> Jars with additional Manifest entries.
>
> <TG>Agreed, as long as your OSGi container provides only basic Java SE
> execution environment.</TG>
>
> Hence, I think your argument that follows is flawed from the
> beginning...
>
> <TG>Besides the OSGi Core specification there is also an Enterprise
> specification. I would strongly recommend that the new Gradle OSGi
> plugin is not only able to support Java SE applications but also the
> Java EE case. But besides this, I would argue that the vast majority
> of bundles available will get deployed into some preconfigured
> container, either an Eclipse Target Platform, Spring DM, or any other
> preconfigured target container. That's the real world use case we have to
> cover.
> That's what makes this Gradle plugin so challenging, we have to deal
> with a generic configurable target container. It is important to
> conceptually agree that with OSGi we are talking about container
> applications.</TG>
>
>> This would have some consequences for the new OSGi plugin
>> - It would need to apply the Java plugin internally the same way the
>> WAR plugin does
>
> This is likely to be correct, and what now sits in the GitHub does
> this (IIRC).
>
>> - The meaning of the provided* configurations are the same as with
>> the
>
>> WAR plugin
>> (- There would be additional supply* configurations; that's something
>> the WAR doesn't have)
>>
>> When migration your project from POJO to OSGi the following would
>> need
>
>> to be done
>> - Apply the OSGi plugin +instead+ of the Java plugin
>> - Replace most, if not all, of your compile/runtime dependencies by
>> providedCompile/providedRuntime
>
> And here is where I think, we need to come to a common understanding.
> I argue that;
> 1. The Java plugin produced JAR remains intact, with the additional
> Manifest entries as is now produced by the OSGi plugin.
> 2. An additional(!) artifact is produced, IF the user specifies
> "wab=true" or similar, probably on the project itself.
> 3. The WAB build embeds the runtime deps, put things in WEB-INF etc
> as described by BND WAB support documentation, i.e. Include-Resources
> and stuff should also be 'by convention'.
>
> <TG>If the new osgi-plugin behaves like the Java plugin then we are
> able to cover only the simples Java SE case.</TG> <TG>Don't understand
> why we would need to produce a second artifact in case of WAB. The
> only difference to a normal OSGi bundle is that the layout is fixed by
> the Java EE specification.</TG>
>
>> I would consider this a minor migration effort. One has to divide the
> project dependencies into three buckets anyway when moving to OSGi.
> When running with Equinox, the feature descriptor would list
> additional dependencies (supply*) that need to be injected into the
> execution environment in order to run your bundle.
>
> I am not fond of requiring the Gradle osgi-plugin to support
> non-osgi-endorsed extensions. It quickly becomes convoluted. I assume
> "Feature Descriptor" is an Equinox/Eclipse specific thing, but if not,
> please point me to the spec where it is described.
>
> <TG>Yes, this is Equinox/Eclipse specific and therefore should not go
> into a generic osgi-plugin. However, all target containers will
> require some form of deployment descriptor in order to cover the
> supply* dependencies.</TG>
>
>> Everything build with the new OSGi plugin could be executed in an
>> OSGi
> container +or+ as normal Java application, the only difference is how
> you would create the classpath from the three sets of configurations.
> Does this make sense?
>
> Yes, that sounds right, but you are then contradicting yourself, when
> you say that the JAR would contain runtime dependencies and include
> them in WEB-INF/lib, which on one hand can work with them placed on
> the regular classpath as well, which only adds perhaps 15MB to the JAR
> (perhaps 50kB otherwise), BUT WAB-by-Kriens also suggest to put the
> classes in WEB-INF/classes to be fully compatible with WAR deployments.
>
> <TG>Don't see any contradiction here. I'm only saying that normal Java
> applications are simply not sensitive to the OSGi metadata like header
> fields from the manifest. To handle embedded libraries the basic
> manifest header field Class-Path could be used.</TG>
>
> Bottom line; I think that two artifacts must be generated, which
> shouldn't be a problem for Gradle. But how should that be done to
> remain compatible with Maven repositories?
>
> <TG>Again, I'm not sure why two artifacts would be needed, but
> generally producing two artifacts per OSGi bundle seems to be very
> odd.</TG>
>
> <TG>My bottom line; You had OSGi SE plugin in mind while I'm
> convinced we need one osgi-plugin that is capable to handle both Java
> SE and Java EE applications. WAB is just a very specific EE
> sample.</TG>
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
