I don't want to force plugin-developers to create modules for every dependency that their plugin requires. That's why I've been avoiding OSGI or JBoss Modules.

~Lincoln

On Mon, Apr 18, 2011 at 12:37 PM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:

> What do you think about using Maven APIs to inspect the POM and fetch dependencies dynamically for each plugin, then isolate them in the plugin's classloader?

Why not just load them in to one classloader so you don't have collisions when there are mixed dependencies on Forge it self ?

How about shared data instances ? How does that work ?

...as a side note...creating our own module system now - I feel that is a very bad direction :(
Might as well adopt osgi plugin system if you want this kind of separation ?

/max

>
> ~Lincoln
>
> On Mon, Apr 18, 2011 at 11:56 AM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:
>
> On Apr 18, 2011, at 15:15, Lincoln Baxter, III wrote:
>
> > "if there is a standard location for dependencies"
> >
> > What do you mean?
>
> Your "standard" for shading is that you put all classes into the plugin.jar.
>
> A "standard" for dependencies for a plugin.jar could be "next to the plugin.jar".
>
> Would still have the problem of overlapping jars but then at least its easier to see where the duplication is.
>
> /max
>
> >
> > Thx,
> > ~Lincoln
> >
> > On Mon, Apr 18, 2011 at 6:20 AM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:
> >
> > > I was thinking we might already be able to do that using the existing pom.xml metadata that's stored in the artifact itself, or is that too tricky?
> >
> > if there is a standard location for dependencies then it should be fine - at least better than shading ;)
> >
> > /max
> >
> > >
> > > On Mon, Apr 11, 2011 at 6:51 PM, Max Andersen <manderse@redhat.com> wrote:
> > > I was thinking Plugin jar having references to dependent jars via manifest.mf
> > >
> > > /max (sent from my phone)
> > >
> > >
> > > On 12/04/2011, at 00.39, "Lincoln Baxter, III" <lincolnbaxter@gmail.com> wrote:
> > >
> > >> Can you give an example of how you would bundle the JARs? (Just put them in /META-INF/dependencies/ ... ?) And would that not cause just as many class conflicts? If you shade/relocate then the deps *should be* completely isolated.
> > >>
> > >> On Mon, Apr 11, 2011 at 4:11 PM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:
> > >> well, recommending just bundling jars would be a better approach than shading IMO.
> > >>
> > >> /max
> > >>
> > >> On Apr 11, 2011, at 16:00, Lincoln Baxter, III wrote:
> > >>
> > >> > Yeah, shading is currently the recommended approach. Conflicts should be avoided by using relocations. I know this is... not a great method, but for now it's all we've got. Open to suggestions.
> > >> >
> > >> > ~Lincoln
> > >> >
> > >> > On Mon, Apr 11, 2011 at 3:41 AM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:
> > >> > Heya,
> > >> >
> > >> > Lincoln, I just saw your commits to hibernattools plugin at (https://github.com/forge/plugin-hibernate-tools/commit/8b208b4a8e79dbb8a01d10d266ee81afd2cf7106)
> > >> >
> > >> > Is shading of jars really the recommended approach for plugins in Forge ?
> > >> >
> > >> > How are you going to share/avoid collisions of libraries across plugins if they need to bundle via shading ?
> > >> >
> > >> > /max
> > >> > http://about.me/maxandersen
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > forge-dev mailing list
> > >> > forge-dev@lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/forge-dev
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Lincoln Baxter, III
> > >> > http://ocpsoft.com
> > >> > http://scrumshark.com
> > >> > "Keep it Simple"
> > >>
> > >> /max
> > >> http://about.me/maxandersen
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Lincoln Baxter, III
> > >> http://ocpsoft.com
> > >> http://scrumshark.com
> > >> "Keep it Simple"
> > >
> > >
> > >
> > > --
> > > Lincoln Baxter, III
> > > http://ocpsoft.com
> > > http://scrumshark.com
> > > "Keep it Simple"
> >
> > /max
> > http://about.me/maxandersen
> >
> >
> >
> >
> >
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.com
> > http://scrumshark.com
> > "Keep it Simple"
>
> /max
> http://about.me/maxandersen
>
>
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"

/max
http://about.me/maxandersen






--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"