Here is the information about Weld-OSGi. Anyone want to try it out? ~Lincoln ---------- Forwarded message ---------- From: Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; Date: Sat, Oct 13, 2012 at 8:48 AM Subject: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !! To: Lincoln Baxter III <lincolnbaxter(a)gmail.com&gt; http://in.relation.to/Bloggers/NotOneTwoWeldReleases1110FinalAnd120Beta1 --- Lincoln Baxter's Droid http://ocpsoft.org "Keep it Simple" -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

And this provides CDI injection between bundles/exposed services? On Mon, Oct 15, 2012 at 4:33 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt; wrote: Definitely try it, it's very cool. Just to make sure you get the right idea, this is a prototype for the OSGI-CDI spec (RFC-192) which is still in early development. It is to be expected that there will be some changes. Paul On Oct 15, 2012, at 22:28 , "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > Here is the information about Weld-OSGi. > > Anyone want to try it out? > > ~Lincoln > > ---------- Forwarded message ---------- > From: Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; > Date: Sat, Oct 13, 2012 at 8:48 AM > Subject: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !! > To: Lincoln Baxter III <lincolnbaxter(a)gmail.com&gt; > > > http://in.relation.to/Bloggers/NotOneTwoWeldReleases1110FinalAnd120Beta1 > > --- > Lincoln Baxter's Droid > http://ocpsoft.org > "Keep it Simple" > > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Since CDI annotations is a requirement, isn't this something we will need? What do you recommend as an alternative? What is it missing that would be a blocker? Sorry for all the tough questions :) Thanks for your time!!! ~Lincoln On Mon, Oct 15, 2012 at 5:40 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt; wrote: It provides several things: -Publish OSGi services using CDI annotations -Inject OSGi services in CDI beans using @Inject -Inject OSGi APIs such as the bundlecontext using @Inject Other dependency injection solutions for OSGi (Felix DM, Blueprint, Declarative Services etc.) can already do that using non-cdi annotations. That's why I'm not really pushing on using this CDI bridge, because functionally it doesn't offer anything extra (it's still lacking some important features), and it's not finished yet. In the future this will be very useful however to close the gap between the Java EE and OSGi programming models. Paul On Oct 15, 2012, at 23:33 , "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > And this provides CDI injection between bundles/exposed services? > > On Mon, Oct 15, 2012 at 4:33 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt; wrote: > Definitely try it, it's very cool. Just to make sure you get the right idea, this is a prototype for the OSGI-CDI spec (RFC-192) which is still in early development. It is to be expected that there will be some changes. > > Paul > > > On Oct 15, 2012, at 22:28 , "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > >> Here is the information about Weld-OSGi. >> >> Anyone want to try it out? >> >> ~Lincoln >> >> ---------- Forwarded message ---------- >> From: Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; >> Date: Sat, Oct 13, 2012 at 8:48 AM >> Subject: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !! >> To: Lincoln Baxter III <lincolnbaxter(a)gmail.com&gt; >> >> >> http://in.relation.to/Bloggers/NotOneTwoWeldReleases1110FinalAnd120Beta1 >> >> --- >> Lincoln Baxter's Droid >> http://ocpsoft.org >> "Keep it Simple" >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Hello Paul, Lincoln, since the discussion started about moving to OSGi I have been reading, investigating and experimenting a bit and want to share my experiences as a novice - are you smiling already? I started with the current working Forge set of jars and tried to throw it at Felix - hindlooking somewhat naive I admit. Then the adventure started :-) * the BndTools 2.0.0 alpha command line "wrap" generated the new Manifest internally, but didn't write it into the jar in the end - after some frustrating experiments and reading of the documentation (dating 2006?!?) ~20 times I debugged and fixed the problem - comment by Peter Kriens: command line "wrap" is "for quick use, for serious use, always make a bnd file that controls the process" - which practically means: best write the Manifest yourself, honestly I can't see so much difference between calling "jar ufm <jar> <manifest.part>" and "bnd <bndfile> -o <jar> <jar>"

* the structure of Bnd-projects is totally different to maven projects - I tried to setup the bnd source whithout Bnd-Tools, this is _no_ fun - after ~15 years of programming thats now the 15th version of project structure - not again please?!

* the current state of jars in maven repositories out there makes integration into OSGi a nightmare!! - wrong manifests - manifests full of hundreds of Attributes - totally useless - manifests importing dependencies without declaring them "optional" - please investigate each and every dependency yourself and rewite them - manifests declaring dependencies with version restriction which is not provided by the targeted bundle - what a mess :-/ - IMHO in essence the current state makes the OSGi-landscape an island

* after reading the IMHO excellent book "OSGi in Action" @Manning I understand, that the resulting class loading inside the framework is far from easy to understand, if you go only one level deeper into the real mechanics - it's still no magic going on there

* it's all about control - yes, sure, I understand that - but in the end we have to hide the complexity completely! After so many years of struggle I do not expect all Java programmers to gladly jump on the OSGi bandwaggon just because of the advent of Forge 2.0 I am completely convinced, that OSGi is the best currently available instantiation of a framework we want in a tool like Forge, but the current situation makes the move substantial and painful - compared to the current easy going programming model.

So I also want to stress the necessity of a "Manifest" for the "Forge goes OSGi" project - if there is one: - try hard to stick to maven as build environment. Reasons: user base, documentation, stability, versatility

- CDI is IMHO the new common understanding, stick to it please. No OSGi on the surface. - define precisely the core / plugin bundle interaction - e.g. from the view point of the "user" we could - present a version of core internally for each major version of dependent plugins to enable her to use old and new plugins side-by-side - present a dialog: "which version of core do you want to start" to enable use of new and old plugins - tell her that she has lots of plugins, but due to the version of core none of them are usable - due to the nature of OSGi I am convinced, that a great deal of thought should be invested in the _vision_ we have of Forge before starting the hacking sessions - especially regarding the current state of it: versatile, flexible, open, based on sound tooling,.. Sorry if that was not very productive, after 3 weeks of struggling just had to write that down :-) Are you experts smiling? At least I hope you do! Thanks for your time, commitment and the incredible Forge! Forge on, Thomas Am 15.10.2012 23:55, schrieb Paul Bakker: > First of all I don't think it should be a requirement, you can get a very similar programming model doing pure OSGi. The alternative I use most is Felix DM: http://felix.apache.org/site/apache-felix-dependency-manager-getting-star.... > You can either use a Java API or annotations (probably we should use annotations). It can do pretty much everything CDI can, but based on OSGi services. > > I'm obviously not against CDI at all, I'm a big fan of it, just think we should be careful using a framework that will most probably change significantly in the next few months. But before making that choice, maybe we should include Mathieu and David in this discussion. > > Paul > > > > > > On Oct 15, 2012, at 23:47 , "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > >> Since CDI annotations is a requirement, isn't this something we will need? What do you recommend as an alternative? What is it missing that would be a blocker? >> >> Sorry for all the tough questions :) Thanks for your time!!! >> >> ~Lincoln >> >> On Mon, Oct 15, 2012 at 5:40 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt; wrote: >> It provides several things: >> -Publish OSGi services using CDI annotations >> -Inject OSGi services in CDI beans using @Inject >> -Inject OSGi APIs such as the bundlecontext using @Inject >> _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Hey Thomas, Thanks for your great feedback. I have to say that so far I am having the same experience as you. I have gone through a few hoops to try to get this project to run or do anything, but nothing happening so far. Not really sure what the deal is. * Regarding the programming model: * It is a requirement that OSGi be not in any way be exposed to plugin-developers. This is something that we simple cannot be flexible on. CDI is the standard DI model for Java EE (soon to be Java SE as well) and I since Forge 2.0 isn't exactly stable at the moment... I don't really think that we should be too concerned with the Weld OSGi project being "unstable" either. If anything, it would help both projects to work together - certainly help Weld OSGi get more feedback, and we can get involved in the process while we can still have an influence if we need features to be implemented or changed to support our use-cases. I think this is the perfect reason to try it. If we decide to go with OSGi, and for some reason Weld OSGi is not working for us, then we absolutely must re-create all that "magic" i've already created :) It's essential for adoption. OSGi was never meant to be exposed for every-day development tasks. Part of the selling point of Forge is that it uses the same programming model as the apps you are developing, so you don't need to learn new skill sets. *Regarding project structure: * Paul, is it at all possible for you to refactor this project to use Maven instead of ANT?* *If that is a lot of work, or too complicated, this may signify that it is not a great solution for us yet. We must stay very close to the tools people are used to working with. As it stands, having to install BND tools from a CI archive is a bit of a stretch, but one we can re-mediate by hosting the file on the forge website in the plugin guide. I am also not in favor of a project layout which requires an IDE to build. We need to stick with Maven here. *Regarding modularity: *I'm still not convinced that we really *need* OSGi. I think that if it simplifies our development experience, while continuing to meet our requirements, then we should use it, but if it does not, and is too big a paradigm shift, then we should still with what we are doing. That said, I'm hoping for the former, that we can use it to achieve our goals, but I think we really need to see evidence that it will be able to meet the objectives that I stated a few emails ago. That said, the prototype is a great start to proving out the technology, and the fact that there is little code gives me a lot of hope that OSGi will work for us with a little help from CDI, Maven, and our creativity. If we can get it working with Maven as the build tool/project structure, and CDI as the plugin programming model, then I will be sold. ~Lincoln On Tue, Oct 16, 2012 at 7:00 AM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt;wrote: > Hi Thomas, > > Thanks for trying :-) Comments in line... > > Paul > > On Oct 16, 2012, at 9:14 , Thomas Frühbeck <fruehbeck(a)aon.at&gt; wrote: > > Hello Paul, Lincoln, > > since the discussion started about moving to OSGi I have been reading, > investigating and experimenting a bit and want to share my experiences as a > novice - are you smiling already? > > I started with the current working Forge set of jars and tried to throw > it at Felix - hindlooking somewhat naive I admit. Then the adventure > started :-) > > * the BndTools 2.0.0 alpha command line "wrap" generated the new > Manifest internally, but didn't write it into the jar in the end > - after some frustrating experiments and reading of the > documentation (dating 2006?!?) ~20 times I debugged and fixed the problem > - comment by Peter Kriens: command line "wrap" is "for quick use, > for serious use, always make a bnd file that controls the process" - which > practically means: best write the Manifest yourself, honestly I can't see > so much difference between calling "jar ufm <jar> <manifest.part>" and "bnd > <bndfile> -o <jar> <jar>" > > > Use BndTools instead. There is a wizard "Wrap JAR as OSGi bundle" > > > * the structure of Bnd-projects is totally different to maven > projects - I tried to setup the bnd source whithout Bnd-Tools, this is _no_ > fun > - after ~15 years of programming thats now the 15th version of > project structure - not again please?! > > > Don't try playing with bndtools projects without bndtools. That's like > playing with Maven projects without Maven ;-) > BndTools projects are structured as standard Eclipse projects, only the > dependency management is done by BndTools (and that's why you should not > try to work around that). > > > * the current state of jars in maven repositories out there makes > integration into OSGi a nightmare!! > - wrong manifests > - manifests full of hundreds of Attributes - totally useless > - manifests importing dependencies without declaring them > "optional" - please investigate each and every dependency yourself and > rewite them > - manifests declaring dependencies with version restriction which > is not provided by the targeted bundle > - what a mess :-/ > - IMHO in essence the current state makes the OSGi-landscape an > island > > > Depending on what you are trying to use this can be the case > unfortunately. It's getting better though, more and more libraries come > with correct manifests. It's mostly a problem with frameworks (as opposed > to libraries). The up-side is that plugin developers will hardly ever > introduce frameworks in their plugins, because Forge already offers an easy > programming model. > > > * after reading the IMHO excellent book "OSGi in Action" @Manning I > understand, that the resulting class loading inside the framework is far > from easy to understand, if you go only one level deeper into the real > mechanics - it's still no magic going on there > > > Isolated classloading is a complicated topic in any modular approach, as > an application developer you hardly ever have to deal with that level > however. > > > * it's all about control - yes, sure, I understand that - but in the > end we have to hide the complexity completely! After so many years of > struggle I do not expect all Java programmers to gladly jump on the OSGi > bandwaggon just because of the advent of Forge 2.0 > > I am completely convinced, that OSGi is the best currently available > instantiation of a framework we want in a tool like Forge, but the current > situation makes the move substantial and painful - compared to the current > easy going programming model. > > > The currently programming model is easy because (mostly Lincoln) did all > kind of CDI magic to create this programming model. Out of the box it's > really not that easy when looking at just the low-level building blocks. > It's the same when we build on OSGI, we have to provide the easy > programming model. I strongly believe that it will be as easy as it is now. > > > > So I also want to stress the necessity of a "Manifest" for the "Forge > goes OSGi" project - if there is one: > - try hard to stick to maven as build environment. Reasons: user > base, documentation, stability, versatility > > > You are right about the user base, but for the rest it's really very > similar. > > - CDI is IMHO the new common understanding, stick to it please. No > OSGi on the surface. > - define precisely the core / plugin bundle interaction > - e.g. from the view point of the "user" we could > - present a version of core internally for each major version > of dependent plugins to enable her to use old and new plugins side-by-side > - present a dialog: "which version of core do you want to > start" to enable use of new and old plugins > - tell her that she has lots of plugins, but due to the > version of core none of them are usable > - due to the nature of OSGi I am convinced, that a great deal of > thought should be invested in the _vision_ we have of Forge before starting > the hacking sessions - especially regarding the current state of it: > versatile, flexible, open, based on sound tooling,.. > > Sorry if that was not very productive, after 3 weeks of struggling just > had to write that down :-) > Are you experts smiling? At least I hope you do! > > Thanks for your time, commitment and the incredible Forge! > > Forge on, > Thomas > > > > > Am 15.10.2012 23:55, schrieb Paul Bakker: > > First of all I don't think it should be a requirement, you can get a very > similar programming model doing pure OSGi. The alternative I use most is > Felix DM: > http://felix.apache.org/site/apache-felix-dependency-manager-getting-star... > . > You can either use a Java API or annotations (probably we should use > annotations). It can do pretty much everything CDI can, but based on OSGi > services. > > I'm obviously not against CDI at all, I'm a big fan of it, just think > we should be careful using a framework that will most probably change > significantly in the next few months. But before making that choice, maybe > we should include Mathieu and David in this discussion. > > Paul > > > > > > On Oct 15, 2012, at 23:47 , "Lincoln Baxter, III" < > lincolnbaxter(a)gmail.com&gt; wrote: > > Since CDI annotations is a requirement, isn't this something we will > need? What do you recommend as an alternative? What is it missing that > would be a blocker? > > Sorry for all the tough questions :) Thanks for your time!!! > > ~Lincoln > > On Mon, Oct 15, 2012 at 5:40 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt;wrote: > >> It provides several things: >> -Publish OSGi services using CDI annotations >> -Inject OSGi services in CDI beans using @Inject >> -Inject OSGi APIs such as the bundlecontext using @Inject >> >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."