On Mon, Mar 7, 2011 at 11:45 PM, Glaeser, Thomas <[email protected]> wrote: > <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>
The main problem is timezones. I am in China, and while I am available, you are sleeping. Maybe during the weekend. > <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> I don't "own" projectB. It is not mine to publish. So, then you end up with the 'hell' that Spring DM (and others for that matter) tried, publishing these projects under other names. And when they are available under other names, should they be trusted? Sometimes, sometimes not. You might not be very paranoid, but there are plenty of people who are. > <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: See above. And the WAB, as I said, is a subset. Shipping my product as a single deployable bundle has merits. And I would even argue that it is less 'hell' the fewer the bundles you need to manage. > 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> Again, I think you are assuming that I "own" the entire space. More often than not, I don't. > 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> This is not related to the osgi plugin. There is nothing the build system need to do to support this. > <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> Uhhhh.... "into several configurations" == different usecases. Never mind that your and my definition of use-case seems to vary beyond recognition; Simple question; Do you agree that building a WAB which is also a deployable WAR, as Kriens suggest on http://www.aqute.biz/Bnd/Format (subheading Web Archive Bundles), is a desirable option? If not, we can stop this discussion. Cheers -- 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
