[forge-dev] Fwd: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !!

Lincoln Baxter, III lincolnbaxter at gmail.com
Tue Oct 16 15:24:18 EDT 2012 

Adding David Lloyd.

On Tue, Oct 16, 2012 at 3:06 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> 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 at gmail.com>wrote:
>
>> Hi Thomas,
>>
>> Thanks for trying :-) Comments in line...
>>
>> Paul
>>
>> On Oct 16, 2012, at 9:14 , Thomas Frühbeck <fruehbeck at aon.at> 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-started.html
>> .
>> 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 at gmail.com> 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 at gmail.com>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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20121016/a4b4f612/attachment-0001.html

More information about the forge-dev mailing list