That doesn't solve the problem of having to drop jar files onto the classpath in order for plugins to work. I want one JAR per plugin.<br><br>~Lincoln<br><br><div class="gmail_quote">On Mon, Apr 18, 2011 at 12:59 PM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
On Apr 18, 2011, at 18:57, Lincoln Baxter, III wrote:<br>
<br>
> 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.<br>
<br>
</div>But then you shouldn't be forcing them to shade either - you should just have one global classloader for the plugins then.<br>
<div><div></div><div class="h5"><br>
/max<br>
<br>
><br>
> ~Lincoln<br>
><br>
> On Mon, Apr 18, 2011 at 12:37 PM, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
><br>
> > 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?<br>
><br>
> Why not just load them in to one classloader so you don't have collisions when there are mixed dependencies on Forge it self ?<br>
><br>
> How about shared data instances ? How does that work ?<br>
><br>
> ...as a side note...creating our own module system now - I feel that is a very bad direction :(<br>
> Might as well adopt osgi plugin system if you want this kind of separation ?<br>
><br>
> /max<br>
><br>
> ><br>
> > ~Lincoln<br>
> ><br>
> > On Mon, Apr 18, 2011 at 11:56 AM, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
> ><br>
> > On Apr 18, 2011, at 15:15, Lincoln Baxter, III wrote:<br>
> ><br>
> > > "if there is a standard location for dependencies"<br>
> > ><br>
> > > What do you mean?<br>
> ><br>
> > Your "standard" for shading is that you put all classes into the plugin.jar.<br>
> ><br>
> > A "standard" for dependencies for a plugin.jar could be "next to the plugin.jar".<br>
> ><br>
> > Would still have the problem of overlapping jars but then at least its easier to see where the duplication is.<br>
> ><br>
> > /max<br>
> ><br>
> > ><br>
> > > Thx,<br>
> > > ~Lincoln<br>
> > ><br>
> > > On Mon, Apr 18, 2011 at 6:20 AM, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
> > ><br>
> > > > 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?<br>
> > ><br>
> > > if there is a standard location for dependencies then it should be fine - at least better than shading ;)<br>
> > ><br>
> > > /max<br>
> > ><br>
> > > ><br>
> > > > On Mon, Apr 11, 2011 at 6:51 PM, Max Andersen <<a href="mailto:manderse@redhat.com">manderse@redhat.com</a>> wrote:<br>
> > > > I was thinking Plugin jar having references to dependent jars via manifest.mf<br>
> > > ><br>
> > > > /max (sent from my phone)<br>
> > > ><br>
> > > ><br>
> > > > On 12/04/2011, at 00.39, "Lincoln Baxter, III" <<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>> wrote:<br>
> > > ><br>
> > > >> 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.<br>
> > > >><br>
> > > >> On Mon, Apr 11, 2011 at 4:11 PM, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
> > > >> well, recommending just bundling jars would be a better approach than shading IMO.<br>
> > > >><br>
> > > >> /max<br>
> > > >><br>
> > > >> On Apr 11, 2011, at 16:00, Lincoln Baxter, III wrote:<br>
> > > >><br>
> > > >> > 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.<br>
> > > >> ><br>
> > > >> > ~Lincoln<br>
> > > >> ><br>
> > > >> > On Mon, Apr 11, 2011 at 3:41 AM, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
> > > >> > Heya,<br>
> > > >> ><br>
> > > >> > Lincoln, I just saw your commits to hibernattools plugin at (<a href="https://github.com/forge/plugin-hibernate-tools/commit/8b208b4a8e79dbb8a01d10d266ee81afd2cf7106" target="_blank">https://github.com/forge/plugin-hibernate-tools/commit/8b208b4a8e79dbb8a01d10d266ee81afd2cf7106</a>)<br>
> > > >> ><br>
> > > >> > Is shading of jars really the recommended approach for plugins in Forge ?<br>
> > > >> ><br>
> > > >> > How are you going to share/avoid collisions of libraries across plugins if they need to bundle via shading ?<br>
> > > >> ><br>
> > > >> > /max<br>
> > > >> > <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
> > > >> ><br>
> > > >> ><br>
> > > >> ><br>
> > > >> ><br>
> > > >> > _______________________________________________<br>
> > > >> > forge-dev mailing list<br>
> > > >> > <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> > > >> > <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> > > >> ><br>
> > > >> ><br>
> > > >> ><br>
> > > >> > --<br>
> > > >> > Lincoln Baxter, III<br>
> > > >> > <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> > > >> > <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> > > >> > "Keep it Simple"<br>
> > > >><br>
> > > >> /max<br>
> > > >> <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >> --<br>
> > > >> Lincoln Baxter, III<br>
> > > >> <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> > > >> <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> > > >> "Keep it Simple"<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > > Lincoln Baxter, III<br>
> > > > <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> > > > <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> > > > "Keep it Simple"<br>
> > ><br>
> > > /max<br>
> > > <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Lincoln Baxter, III<br>
> > > <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> > > <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> > > "Keep it Simple"<br>
> ><br>
> > /max<br>
> > <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Lincoln Baxter, III<br>
> > <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> > <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> > "Keep it Simple"<br>
><br>
> /max<br>
> <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Lincoln Baxter, III<br>
> <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> "Keep it Simple"<br>
<br>
/max<br>
<a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>