Re: [forge-dev] shading!?

And that's why a module system is needed. If people can just add dependencies there will be duplicate (possibly multiple versions) dependencies. Each plugin should be in a separate classloader, and each dependency should be too so that a plugin never breaks other plugins or Forge itself. It would be a big limitation if plugins can't use libraries otherwise. Paul On Tue, Apr 19, 2011 at 6:14 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; wrote: That's right, but what I'm saying is that I don't want developers to be responsible for anything but *their code* -- if they have dependencies, those depenencies will be fetched for them (or somehow bundled in the JAR file itself, which is certainly possible, however not my preference.) If you could write a plugin, reference dependencies in your POM, and have everything *Just Work* don't you think that would be a friendlier experience? ~Lincoln On Mon, Apr 18, 2011 at 5:55 PM, Max Andersen <manderse(a)redhat.com&gt; wrote: But if your plugin uses multiple jars it is not one jar. /max (sent from my phone) On 18/04/2011, at 19.06, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > 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. > > ~Lincoln > > On Mon, Apr 18, 2011 at 12:59 PM, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: > > On Apr 18, 2011, at 18:57, Lincoln Baxter, III wrote: > > > 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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" > > /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" _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev