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@gmail.com> wrote:
Hi Lincoln,

Comments in line...


On Oct 15, 2012, at 18:19 , "Lincoln Baxter, III" <lincolnbaxter@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@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@redhat.com> wrote:
>
> On 26 Sep 2012, at 14:53, Ivan St. Ivanov <ivan.st.ivanov@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev




--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."