Date: Wed, 31 Aug 2005 11:16:50 +0300 From: Panagiotis Astithas <past@ebs.gr> To: Vizion <vizion@vizion.occoxmail.com> Cc: Mark Linimon <linimon@lonesome.com>, Herve Quiroz <hq@freebsd.org>, freebsd-eclipse@freebsd.org Subject: Re: How should eclipse be organized in the ports tree? Message-ID: <43156772.7070808@ebs.gr> In-Reply-To: <200508301927.31549.vizion@vizion.occoxmail.com> References: <200508251303.59453.vizion@vizion.occoxmail.com> <20050830212342.GA32240@soaustin.net> <200508301615.53251.vizion@vizion.occoxmail.com> <200508301927.31549.vizion@vizion.occoxmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Vizion wrote: > On Tuesday 30 August 2005 16:15, the author Vizion contributed to the > dialogue on- > Re: How should eclipse be organized in the ports tree?: > > >>On Tuesday 30 August 2005 14:23, the author Mark Linimon contributed to the >>dialogue on- >>Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & >>mailing list]: >>>On Tue, Aug 30, 2005 at 10:10:26AM -0700, Vizion wrote: >>> >>>>I am now faced with the question is the ports tree as inflexible as some >>>>people suggest or are some members of our meritocracy more inflexible >>>>than the freebsd assets? >>> >>>This is a complete oversimplification of the situation. >>> >>>There are some hard-coded assumptions in the ports tree -- one of which is >>>that there are two levels, categories and ports -- and these assumptions >>>are mirrored in the repositories of tens of thousands if not hundreds of >>>thousands of users, and thousands of lines of shell scripts and database >>>programs that create the binary packages and monitor the results of those >>>build processes. >>> >>>So when you suggest that the only way that Eclipse can be supported is >>>to have a multilevel ports tree -- as you are seeming to -- you are clearly >>>totally misunderestimating the amount of effort involved. >>> >>>In your most recent email I think you are finally getting a lot closer to >>>what I consider 'real' problem. IMHO the interesting problems you want to >>>solve are the 'search' and 'browse' problems. Directory names controlled >>>by CVS structures in an unbranched tree, which are then mirrored all around >>>the world, are really poor paradigms for these problems. Herve has >>>suggested some better tools for these which are better ways to think >>>about these problems and you should look at those. We certainly need more. >>> >>>The meta-plugin idea is also worth considering. >>> >>>But restructuring the entire tree, even to add a few hundred ports, is >>>simply not feasible with the level of volunteer effort we have and the >>>number of people that depend on the current structure worldwide. >>> >>>mcl >> >>Ok - building on your comments would my original suggestion, as modified >>below, and leaving aside for one moment the arguments as to whether or not >>committers might desire it,be capable of implementation without a >>restructuring of code? >> >>This proposal mean that /usr/ports/plugins/*.jar is a repository for files >>which are accessed solely via the meta-eclipsevx.xxx ports. >> >>I think this might shoehorn the necessary structure into the existing >>system. What do you think? >> >>/usr/ports/eclipse/eclipsemainv[x.xxx] Holds the main eclipse ports >>/usr/ports/eclipse/meta-eclipse[v.xxx] Holds eclipse plugins loader > > Just for sake of clarity the above are intended to be straight forward ports > > >>/usr/ports/eclipse/plugins/ Holds the *.jar files > > >>/usr/ports/eclipse/misc1 self contained eclipse > > ports > >>/usr/ports/eclipse/misc2 >>/usr/ports/eclipse/miscN >> >>/usr/ports/eclipse/plugins would, in effect, be a set of files which would >>be downloaded under control of the meta-eclipse loader >> >>If so why not use it - that would make eclipse a category which could >>enclose a number of ports for eclipse versions, a number >>of /usr/ports/eclipse/meta_eclipseplugin ports and each plugin would then >>(in effect) be a *.jar file file held within the /usr/eclipse/plugins >>directory. >>The meta_eclipse plugin could build the library of available plugins on the >>fly and use the standard system for registering the plugins on the local >>machine. In that way could the need be integrated into the existing system? >> >>Whatis your reaction? >> >>david I see various problems with your approach, let me try to identify a few. First of all, a plugin's jar file is essentially its distfile, currently downloaded by the ports system in ports/distfiles or its subdirectories. Storing it in the ports CVS repository (in ports/eclipse/plugins), as you seem to imply, would in some cases be problematic because of licensing/redistribution issues (not to mention bloat). Another thing is that many eclipse plugins have to be traditional ports since they require the ports infrastructure for their dependencies (see java/eclipseme for an example). Therefore they do not fit in the ports/eclipse/plugins case. Also, what is the point of treating plugins differently, with ports/eclipse/plugins and ports/eclipse/miscX? What do you gain by losing uniformity? Furthermore, you describe the need to create an eclipse plugin that lists the available plugins as FreeBSD ports and lets the user install one and register it as a regular system package. How is this better than eclipse's own plugin management method? I would go even further and ask why do you need FreeBSD-specific ports for most plugins? Why not simply install it via the internal GUI and be done with it? That way you get the usual Eclipse experience you see in other platforms. I am actually doing this myself and quite like it, to be honest. The tradeoff is that you get files under $PREFIX/eclipse that are not recorded in some package, but I'm OK with that. But consider this: you propose to create a new FreeBSD-specific plugin for eclipse, reorganize the ports tree, and change every existing eclipse plugin (to fit in the new scheme) in exchange for what? The registration in packages of every plugin _and_ a GUI plugin manager? When you could get either of those with the current system? Does the amount of effort needed, justify the gain? Let me state this once more, there is no eclipse-supported platform currently that provides what you propose. Therefore it cannot be considered a disadvantage for FreeBSD, either. Our forefathers said, that you should learn to walk, before running. Let's do that, shall we? Let's bring those 300+ plugins you mentioned into the ports system and see where we go from there. Let's get our system officially supported by eclipse.org so that FreeBSD gets more visibility and credibility. Let's work out the swt dependencies of various applications and be the first eclipse platform that does not contain swt libraries all over the place. What do you say? Cheers, Panagiotis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43156772.7070808>