Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & mailing list]

[Greg Lewis]

On Fri, Aug 26, 2005 at 11:00:47AM -0700, Vizion wrote:
> I am inclined to agree that eclipse does not "belong" in ports/java. Neither 
> does iit belong in "devel" or "languages".

I think you mean "lang" for the latter category, correct?  It certainly
doesn't belong there since its not a programming language.  It does seem
to very much belong in devel though, at least based on the Eclipse web
site.

Here is the first sentence I read on http://www.eclipse.org:

"Eclipse is an open source community whose projects are focused on
 providing an extensible development platform and application frameworks
 for building software."

Sounds like a perfect fit for the devel category.  Whether each individual
plugin should be in devel is a separate discussion.  For example,
phpeclipse probably does belong there, eclipse-viplugin probably belongs
in editors.

> In view of the huge number of eclipse plugins and, nore importantly, the 
> mushrooming significance of eclipse, to everyone including the freebsd 
> community,  I would like to suggest we have /ports/eclipse. Here are my basic 
> reasons:
> 
> 1. The huge range of significant plugins (392 last count) which are dependent 
> upon the the eclipse IDE. In my view, and for the good of the platform, we 
> need to make these available to freebsd users in a form that fits into the 
> freebsd ports collection. 

I'm not sure how thats an argument for creating a non-virtual eclipse
category.  Would you care to explain?

> If that means changes to the ports collection schema I see no objection. The 
> long term interest of the platform is much more significant thn the current 
> ports collection schema. 

I think you'll see multiple objections actually :)

> Here are the major categories and the number of plugins within each category:
[snip]

Ok, so there are a significant minority of plugins that may not go into
devel, how is this a problem?

> 2. That in line with current development and application thinking the 
> implications and practice of the eclipse EDI framework cuts right across the 
> current heirarchical divisions of the freebsd port tree which was itself 
> created when  the application and development environment was founded on an 
> entirely different set of system  and application constraints.

Your initial point here would suggest that creating a virtual "eclipse"
category should be considered.  This is something that has been done
before, so it wouldn't be outside of the status quo.

> 3. We are living in a different era and the traditional divisions  do not 
> apply to the eclipse framework. Can we not, as a platform, welcome that 
> change by making appropriate changes to our ports schema?

See my previous comment.  This is what virtual categories are for.

> 4. As you can see by examining Eclipse and by careful study of eclipse and 
> eclipse related websites it is not just an EDI it is also a multi application 
> framework so it does not "belong" in anything other than its own place in the 
> ports tree.

I don't quite follow the logic I'm sorry.  Development environments belong
in the "devel" category.  Multi-application frameworks belong in the
"devel" category.  How does something which is both not belong there?

> 5. I can see great potential for a number of freebsd specific eclipse plugins 
> (including a combined freebsd system management and help tool providing  an 
> integrated and automated sysadmin functionalities).

Vapourware is never a good argument for anything.

> 6. If we do not grasp the opportunity we now have to make the changes needed 
> to accomodate eclipse and any similar generic combined Application/EDI 
> frameworks then freebsd will suffer. It will certainly not be harmed by 
> taking the steps necessary to incorporate into its ports collection.

I disagree.  We need no changes to accomodate eclipse -- its currently
accomodated, albeit in a suboptimal fashion.  I have suggested it be moved
to a more appropriate category and conceded there _may_ (I'm not yet
convinced) be a case for creating a virtual category for it.  I believe
that course of action would be more than sufficient.

> 7. There are substantial advantages when managing an eclipse development 
> environment on the freebsd platform to having the plugins installed from the 
> ports tree rather than via individual user accounts which could lead to 
> individual team members loading different versions of plugins into their own 
> user workspace. We need to have the plugins organized in the ports tree. That 
> means 392 plugins - There can be no doubt that eclipse needs its own place in 
> the freebsd ports hierarchy as well as its own mailing list for the good of 
> the freebsd community. The combination of these two initiatives may attract 
> new devotees to freebsd and cannot do us any harm. I do not believe we will 
> act responsibly by leaving things as they are or failing to grasp the new 
> opportunities.

Here is the problem.  The figure of 392 plugins and the unspecified harm
that will befall FreeBSD if we don't do something for eclipse is being
used to propose a reorganisation of the ports tree.  The reality is that
we're talking about eclipse and about 20 plugin ports, out of a total of
13,000+ ports.  I'm sorry, but the reality of the level of interest in
eclipse amongst the FreeBSD community doesn't seem to match with the
magnitude of the change you are suggesting.  Please, by all means, build
up that level of interest.  Get some people together like the Gnome and
KDE groups.  Get some more plugins submitted as PRs and get them committed.
Then when you've got some runs on the board start proposing eclipse as a
virtual category.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org