[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Re: eclipse-dev digest, Vol 1 #1308 - 1 msg
|
Re: 1)
Actually, formatting will affect binaries, since it will likely change the
layout of the code, and thus impact generated line number attributes. If we
did not regenerated them, debugging this code would expose inconsistencies.
Note that the Java builder is able to realize that source changes were
inocuitous, and thus avoid recompiling all further dependents (unlike some
timestamp based make facilities).
Re: 2)
You may try to only build working sets (excluding the offending project),
so you would not be paying for rebuilding the offending project until it
effectively changes (after refreshing from repository). Also, why do you
need to clean/rebuild things that often ? Isn't incremental build all you
need (and then again our Java builder is going to be taking care of
avoiding unnecessary recompilations).
Entered bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=78067 to record
this.
Please annotate the bug with further comments to avoid them being lost.
"JavaYves"
<javayves@hotmail
.com> To
Sent by: <eclipse-dev@xxxxxxxxxxx>
eclipse-dev-admin cc
@eclipse.org
Subject
[eclipse-dev] Re: eclipse-dev
11/07/2004 07:24 digest, Vol 1 #1308 - 1 msg
PM
Please respond to
eclipse-dev
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 "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.
</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? 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. 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
_______________________________________________
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
