timboudreau commented on issue #1278: [NETBEANS-2604] Support SVG icon loading from ImageUtilities URL: https://github.com/apache/netbeans/pull/1278#issuecomment-539623163 > I'm not very familiar with the clusters system--could you explain how to > do this? Is this different from what I started with in the first version of > this PR? For that version, @JaroslavTulach > <https://github.com/JaroslavTulach> objected that new libraries were > ending up in netbeans/platform/lib, which was undesirable. That included > libraries that were previously already in the ide cluster ( > o.apache.commons.io and o.apache.commons.logging). > The cluster system actually dates back to Sun's architecture review requirements - but it is a generally good idea. The idea - driven by requirements from Solaris - was that an application should only install ONE copy of any shared libraries on a system; and Sun was building multiple products on top of NetBeans. So if there were two NetBeans-based applications on a system, there should only be one copy of, say, the platform modules or the editor modules, which both applications simply use as "clusters" of libraries. So the cluster system was invented - carve the IDE and platform into chunks of relatied (and interdependent) functionality, such that inter-cluster dependencies are unidirectional and you - a directed graph. In practice, in terms of people installing multiple copies of software on systems, I don't think that is an enormous concern these days (this was back in the era of thin-clients, so a "system" was likely big iron and the "desktop" was a remote X connection). But it forces us to think about both macro-level dependencies - what functionality is and isn't related, what is "essential" and what isn't, and what is "platform" vs. something else, and factor things accordingly. That keeps a clean definition of what is "platform" and what isn't, and keeps the IDE and platform from merging into a monolithic hairball (which it once, circa 1999, was). So it's a good thing to keep. Now, re SVG icons, that seems to me to be something which obviously belongs in the platform. Display resolution is not going to go *down* and we are past the point where raster formats for this sort of thing are inadequate; mobile platforms typically have you create raster icons in multiple resolutions, which is annoying and goes out of date with the next model; and on the desktop, we're not dealing with standardized screen sizes and resolutions, so the only sane way to deal that is a resolution-independent graphics format. So, this belongs in the platform, period. If the objection is that the IDE itself is not yet using SVG icons, so it will result in library dependencies getting packaged which nothing uses, *that's a build-system problem, not an architecture problem.* Fix the build system so the application-building phase detects that there are libraries which are not referenced in the manifest of any module or other library, and deletes those. That's as simple as building a graph of inter-JAR dependencies and then seeing if what you actually get is *more than one distinct graph*, and deleting everything that is not in the largest graph which is the actual application. -Tim
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
