Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Re: eclipse-dev digest, Vol 1 #1308 - 1 msg

We have workspaces that contain more than 100 plugin java projects.

I can give some suggestions to make the development more efficient :

1) Iif you change anything of a java source, the autobuild recompiles everything that depends on it. Some changes don't have any impact on the binaries, e.g. reformat the sources, or changing comments; unfortunately this forces an unnecessary autobuild.
The autobuild should be more intelligent in such cases.

2) Although we need all projects in the workspace, each person actually only works on some of these projects. There should be a possibility to indicate projects that should not be rebuilt, even when using "clean all projects". Maybe a "use this project as if it is a binary project" is an option. Only when we refresh from the repository, a rebuild and
recreation of a binary project should be performed.

What we do now as a (quite manual) "bypass", is create binary projects or a couple of "special" plugin projects that only contain the jars with the compiled versions of the projects we need. This way, there is no rebuild for these projects. Big disadvantage is that we have dependencies to that "big" jar-project instead of only the really needed projects.

As you can see, the biggest concern we have is the builds. The more projects the workspace
contains, the slower its responsiveness.

Hope this can help you.

Yves

----- Original Message ----- From: <eclipse-dev-request@xxxxxxxxxxx>
To: <eclipse-dev@xxxxxxxxxxx>
Sent: Saturday, November 06, 2004 6:00 PM
Subject: eclipse-dev digest, Vol 1 #1308 - 1 msg


Send eclipse-dev mailing list submissions to
eclipse-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
or, via email, send a message with subject or body 'help' to
eclipse-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
eclipse-dev-admin@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of eclipse-dev digest..."


Today's Topics:

  1. Issues with large-scale development (John Arthorne)

--__--__--

Message: 1
To: eclipse-dev@xxxxxxxxxxx
Cc: platform-core-dev@xxxxxxxxxxx
From: John Arthorne <John_Arthorne@xxxxxxxxxx>
Date: Fri, 5 Nov 2004 13:21:40 -0500
Subject: [eclipse-dev] Issues with large-scale development
Reply-To: eclipse-dev@xxxxxxxxxxx

This is a multipart message in MIME format.
--=_alternative 0064DB7785256F43_=
Content-Type: text/plain; charset="US-ASCII"

One of the major development themes for Eclipse 3.1 is to improve support
for "Large-scale development" in Eclipse. This includes improving
collaboration for large, distributed teams, but it also encompasses
support for large workspaces. The Eclipse committers form a large,
distributed group, so we have no problems gathering requirements for the
first aspect of the problem. However, we don't tend to work on very large
projects or have very large workspaces (Eclipse is broken up into many
small projects and each committer tends to only work with a handful of
them).  This makes it difficult for us to see the most pressing and
important problems for those working in such environments.  Bug reports
have helped us identify some areas with room for improvement, such as
project creation (bug 74392), recursive deletion (bug 10628), and building
(bug 60803). We are making progress on these fronts, but want to make sure
we are not missing other problem areas for users with very large
workspaces and/or locally mounted remote file systems.

This is a general call for those using Eclipse for large-scale development
to let us know what the major problem areas are. What operations are very
slow? Could the UI be improved or made more responsive during long
operations?  We are particularly interested in applications of Eclipse
beyond the Java IDE realm, such as in CDT and web tools. Don't hesitate to
also remind us about old bugs that have already been reported that are
still important to you, as they sometimes get lost in bugzilla.

Please respond with issues and suggestions on the platform-core-dev
mailing list.  We don't promise to address all of the problems that people
may raise, although help with identifying problems and implementing and
testing solutions can greatly improve a bug's chances of being fixed.
Clearly there is a lot of potential work in this area, so we want to
ensure that we are focused on the areas with the largest potential gain
for the Eclipse community.

--=_alternative 0064DB7785256F43_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">One of the major development themes
for Eclipse 3.1 is to improve support for &quot;Large-scale development&quot;
in Eclipse. This includes improving collaboration for large, distributed
teams, but it also encompasses support for large workspaces. The Eclipse
committers form a large, distributed group, so we have no problems gathering
requirements for the first aspect of the problem. However, we don't tend
to work on very large projects or have very large workspaces (Eclipse is
broken up into many small projects and each committer tends to only work
with a handful of them). &nbsp;This makes it difficult for us to see the
most pressing and important problems for those working in such environments. &nbsp;Bug reports have helped us identify some areas with room for improvement,
such as project creation (bug 74392), recursive deletion (bug 10628), and
building (bug 60803). We are making progress on these fronts, but want
to make sure we are not missing other problem areas for users with very
large workspaces and/or locally mounted remote file systems. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">This is a general call for those using
Eclipse for large-scale development to let us know what the major problem
areas are. What operations are very slow? Could the UI be improved or made
more responsive during long operations? &nbsp;We are particularly interested
in applications of Eclipse beyond the Java IDE realm, such as in CDT and
web tools. Don't hesitate to also remind us about old bugs that have already
been reported that are still important to you, as they sometimes get lost
in bugzilla.</font>
<br>
<br><font size=2 face="sans-serif">Please respond with issues and suggestions
on the platform-core-dev mailing list. &nbsp;We don't promise to address
all of the problems that people may raise, although help with identifying
problems and implementing and testing solutions can greatly improve a bug's
chances of being fixed. Clearly there is a lot of potential work in this
area, so we want to ensure that we are focused on the areas with the largest
potential gain for the Eclipse community.</font>
<br>
--=_alternative 0064DB7785256F43_=--


--__--__--

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev


End of eclipse-dev Digest



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 1/11/2004

Back to the top