Re: Fw: [platform-core-dev] Issues with large-scale development

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I should add that some of the issues
you mention already have corresponding bug reports.  Feel free to
CC yourself on these to keep up to date on any progress.

Project templates:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=36960

Scripting/automation:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=37680

John.

Peter Kriens <Peter.Kriens@xxxxxxxx>

11/26/2004 07:53 AM

Please respond to
pkriens

To	Jeff McAffer/Ottawa/IBM@IBMCA
cc
Subject	Fwd: Re: [platform-core-dev] Issues with large-scale development

Wishes. A couple of weeks ago there was a question on the developer
list about ideas/wishes for large scale developments. I compiled such
a list but it bounced because I do not seem to be accepted by the
moderator. Maybe you can find some use for it ...

Kind regards,

          Peter Kriens

From: Peter Kriens <Peter.Kriens@xxxxxxxx>
To: platform-core-dev@xxxxxxxxxxx
Date: Tuesday, November 9, 2004, 8:16:20 AM
Subject: [platform-core-dev] Issues with large-scale development

You asked for it, you got it :-)

A list of wishes:

- Support dynamic project templates. It would be very nice if a
 project could dynamically inherit from a template project, and only
 override the changed files (dynamically, not copy/paste).
 Redundancy is the root of all evil, and I think this will save some
 redundancy. It is amazing how many boilerplates are necessary
 nowadays for projects that are in a family of projects.

- Support filter expressions in the Working set. This will allow
 project names to be used in such a way that they dynamically become
 part of a set. I notice now that I spent a lot of time adding
 projects to the appropriate sets. Additionally, a small script
 language could be used to define the membership.

- Make working sets hierarchical. This should allow for operations on
 working sets.

- Support a command line shell (with completion!) which allows you to
 switch between projects. I.e. typing "cd ../org.osgi.impl.service.cm"
 and "ed Configuration.java" is a lot faster than clicking the
mouse.
 Would be nice to have lots of commands there to minimize the need for
 the mouse. Scripting should of course also be supported. It would be
 really nice if the syntax could also be used in normal text panes so
 you can type anywhere, select and execute it. It should be a real
 good scripting language combined with shell features like output
 redirection and piping, but also easy to use.

- Develop an alternative to ant. Ant is ridiculous complex and ill
 suited for its task. It would be great to have a (small?) command
 line tool that can run without GUI but that has scripting and
 build facilities. Would be nice if this was could use on a real
 scripting language like groovy or netbeans, though the syntax should
 be optimized for readability. It should also support a model where
 projects are instances of a build class so you can easily and
 centrally control the build rules. Obviously ant tasks should
 somehow be supported, but it should clearly support the cool
 features of a shell like output redirection, piping, powerful
 manipulation of symbols, dependency checking, etc.

- Publish the XML interface of .classpath, .project and wherever
 Eclipse keeps its VARIABLES. This is necessary for tools to
 parse these files to do their job.

- Support the strong modularization of OSGi in the compiler. I.e. obey
 the visibility rules. Also, provide GUI support to look at the jar
 files in this light.

Minor wishes/issues:
- A last visited file list
- Detect changes on the file system, making refresh unnecessary
- When a project is created, it should automatically be added to the
 current working set.
- It should be easier to send a project to someone else. I.e. there
 needs to be a function to wrap a project in a zip file and send it
 someone else who then creates a project out of it. Currently this is
 too cumbersome (or I have missed something).
- Allow JAR files to be inspected, even if they are not on the
 classpath.
- A JAR file that is added to the classpath should stil showup as a
 normal file in the directory and not be replaced with the JAR icon.
 Sometimes this file needs to be selected for another task, or copied
 and this becomes impossible.