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.
But then you shouldn't be forcing them to shade either - you should just have one
global classloader for the plugins then.
/max
~Lincoln
On Mon, Apr 18, 2011 at 12:37 PM, Max Rydahl Andersen <max.andersen(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com> wrote:
> > >> > Heya,
> > >> >
> > >> > Lincoln, I just saw your commits to hibernattools plugin at
(
https://github.com/forge/plugin-hibernate-tools/commit/8b208b4a8e79dbb8a0...)
> > >> >
> > >> > 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(a)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"