[eclipse.org-architecture-council] [Bug 252239] Common Servers Views

[bugzilla-daemon@xxxxxxxxxxx]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=252239  
Product/Component: WTP ServerTools / wst.server

Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eclipse.org-architecture-
                   |                            |council@xxxxxxxxxxx




--- Comment #23 from Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx>  2008-10-29 05:05:16 -0400 ---
> Maybe org.eclipse.serversview or something like that. 

I think that it should at least be in the UI space. In Eclipse Platform, we
already have org.eclipse.ui.net which holds the common Proxy Preference page.

For me, it looks like the concept of the Servers view is much similar to the
common Proxy Preferences. Where the Project Explorer holds anything related to
the Workspace, the "Servers View" would really be about holding anything
related to the wider (remote) environment around the workspace. This can be
seen as a general concept. From that point of view, I could even see the
contents merged into the existing 
   org.eclipse.ui.net 
bundle. Other options are 
   org.eclipse.ui.serversview
   org.eclipse.ui.net.serversview
   org.eclipse.ui.remote

> All it takes to get a new namespace is a quick note to EMO with proposed
> namespace and justification.

Right, but I think it might make sense to ask the Architecture Council and/or
owners of the current org.eclipse.ui.net namespace for their opinion. The
namespace discussion is also related to the "provisional API" discussion we
recently had on the E4 mailing list.

> http://wiki.eclipse.org/Nexus_Project
> Regarding Nexus. The status of that idea is that I went through a lot of
> discussions with the Technology Project PMC regarding it.

I like the idea of Nexus, and I understand the underlying problem. Isn't this a
topic that the Architecture Council should also be working on? The new
development process should allow micro-projects with relatively small overhead
provided that they find a suitable parent project.

> none of the existing top-level projects have experience containing projects
> that do not represent significant end-user functionality

Isn't this merely a question of infrastructure and community adoption?
Microprojects should be capable of managing themselves, without posing overhead
to their containers. Web/Mailinglist/etc infrastructure should be simple enough
that maintaining a website isn't a lot of effort. I like the Sourceforge
pre-canned infrastructure in this respect, SF is a place that fosters
microprojects.

At Eclipse, the Common Builder Infrastructure is a step in the right direction,
but much seems to be missing to make an individual microproject run really well
(in terms of continuous builds, testing, integration, projectplan, ...) - for
me it looks like we need more such common infrastructure, and that's an effort
that goes beyond any individual toplevel project. It's a Community thing.

I'm adding the AC on CC to raise awareness of the cross-project architectural
nature of this discussion.


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.