[forge-dev] Forge 2.0 and OSGi

[Lincoln Baxter, III]

I spent a lot of time abstracting from Maven. What do we need to change in
what's already there to support what you are proposing?

~Lincoln

On Mon, Oct 15, 2012 at 2:50 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> 4. Would the current DependencyResolver abstraction work for that?
> https://github.com/forge/core/blob/master/shell-api/src/main/java/org/jboss/forge/project/dependencies/DependencyResolver.java
>
> ~Lincoln
>
>
> On Mon, Oct 15, 2012 at 12:31 PM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:
>
>> Hi Lincoln,
>>
>> Comments in line...
>>
>>
>> On Oct 15, 2012, at 18:19 , "Lincoln Baxter, III" <
>> lincolnbaxter at gmail.com> wrote:
>>
>> Thank you all for this discussion - I have just now gotten caught up.
>> Just to be clear, I am not thrilled about the idea of requiring a special
>> tool-suite to develop on Forge itself, but I would be willing to put up
>> with it if using OSGi allows us to achieve our goals, which are (top 3):
>>
>> 1. Modularity and ClassLoader Isolation
>>
>> Check (plus dynamic services will get us a lot further than JBM)
>>
>> 2. Plugin/Facet services which can be depended upon by other
>> plugins/facets (essentially enabling re-use of work and exponential
>> progress between plugins.)
>>
>> Check
>>
>> 3. A *standard* *and simple* Maven / CDI development model for plugin
>> authors (no Felix)
>>
>> Check and Check, but...
>> Either Maven or BndTools (or whatever) will work for plugin authors, as
>> long as it produces an OSGi bundle (which Maven does).
>> CDI, could be done, not sure if we should... CDI-OSGi integration is now
>> in the specification process (I'm in the EG), but it might be a little
>> early to start building on that. I would propose building on the service
>> registry, so that any dependency injection (including weld-osgi) will work.
>> Plugin developers don't really have to know about it, it's more of an
>> architectural choice.
>>
>> 4. Modules distributable and dependencies resolvable via normal maven
>> repositories (NOT with p2)
>>
>> Check,  although I would want to make the model more general. Let's deal
>> with jar files in general, which CAN be resolved by Maven. Having Maven as
>> one of the options instead of the only option will also move us closer to
>> multi build system support. An abstraction on top of the repository concept
>> would be a start. This is also done by BndTools, which has support for
>> several kind of repositories (including Maven).
>>
>> Cheers,
>>
>> Paul
>>
>>
>>
>> If these things are possible with OSGi and a little bit of elbow grease,
>> which it sounds like they are, then I think we should seriously consider
>> this for Forge 2.0.
>>
>> ~Lincoln
>>
>> On Fri, Sep 28, 2012 at 8:05 AM, Max Rydahl Andersen <
>> max.andersen at redhat.com> wrote:
>>
>>> > Max, I hope you are kidding about going to p2 and tycho? :-)
>>>
>>> just as much as I'm hoping you are kidding about osgi ? :)
>>>
>>> /max
>>>
>>> >
>>> > Paul, bnd is fine until all your dependencies have correct manifests.
>>> What happens if one of the jars that we depend on does not have the 'Export
>>> packages' entry? We cannot use this jar inside an OSGi environment, I think.
>>> >
>>> > Regards,
>>> > Ivan
>>> >
>>> > On Wed, Sep 26, 2012 at 4:59 PM, Max Rydahl Andersen <
>>> max.andersen at redhat.com> wrote:
>>> >
>>> > On 26 Sep 2012, at 14:53, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>> wrote:
>>> >
>>> > > Hi Max,
>>> > >
>>> > > About your "server" question in the last sentence. If you refer to
>>> my post, I was trying to make an analogy:
>>> > >
>>> > > server <-> applications == Forge core <-> Forge plugins
>>> > >
>>> > > Please, let us not go to p2, tycho and Equinox? :-)
>>> >
>>> > why not ? tons of plugin devs could learn from a proper setup tool :)
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>>
>>> _______________________________________________
>>> 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."
>> _______________________________________________
>> 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/20121015/48eeae1b/attachment.html