Community
Participate
Working Groups
Build 20021022 After committing changes to a couple ant scripts to CVS, a dialog appeared: Title: "Problems encountered performing commit" Message: "Could not find one of more classes: "org.apache.tools.ant.input.DefaultInputHandler". Please check Ant classpath. The files I was checking in were just XML files and had nothing to do with the DefaultInputHandler. I don't understand how this problem was "encountered performing commit" of unrelated files.
Created attachment 2269 [details] commit.png - The dialog in question
In some cases we wrap Core and other exceptions while performing our operations. This sounds like one of those. Can you check the .log to see what's in there? The problem is almost certainly not Team (we're just the ones who told you about the error), but more info would tell us who to forward the bug to.
The "problem" from my perspective is the fact that a build error is being reported to me as a CVS error. The error dialog says, "Problems encountered during commit". This makes me think that my file was not checked into the repository correctly, but it seems that there was just a problem building my project after the commit (yes/no?). If it is just a build error, it shouldn't be reported as a problem committing.
I agree that committing resources should not cause a build. Here's an explanation of what's going on: 1) You performed a commit which modified the CVS sync files 2) The Ant builder was informed of the file changes and performed a build even though the changes did not contain any resources the ant build cared about (and generated an exception during this build which is most likely a bug) 3) We reported the build error as a commit failure There are two issues to be addressed here: - The ant builder should not perform the build in step 2 since no files it cares about are changed. - The commit action should check the error to see if it was a build error (there is a code on IResourceStatus for this) and report it differently (i.e. the action succeeded but a builder failed). I have opened bug 25344 against platform vcm for the second point and am forwarding this report to ANt for the first point
There is no way to determine the scope of what set of files an external tools builder is interested in...maybe the external tools builds does want to know about changes to the CVS files? We are dealing with much more than ant here.
Perhaps what is required is the ability to configure what type of deltas the external builder is interested in. I suspect most builders would not be interested in changes to team-private resources so a preference to indicate this may be useful. On a broader note, builders that do not traverse the deltas should probably not be set to perform incremental builds. Is there a preference to control this (I know there is a global preference but I may want delta-smart builders to be incremental and external builders to be on-demand or triggered by some other condition)?
*** Bug 25823 has been marked as a duplicate of this bug. ***
Needs investigation
You can configure what kind of builds a builder will run for (full, incremental, auto) on a per-configuration basis. External tools doesn't know about CVS, so we can't provide that option directly. To satisfy your case, we'd either need to define an extension point to allow others to provide exclusion filter preferences or a way for the user to manually mark which parts of the filesystem they're interested in. Then, when a build occurs, the builder could check if files in the areas of interest have changed (is there API for this?) to decide if the builder should be run. We definitely won't be doing either of things for 2.1, but the question is whether we want to do them ever? (LATER or WONTFIX?)
We will decide after 2.1
Reopening...
Very likely to marked as a duplicate of bug 31510.
We've talked about and prototyped allowing the user to limit a builder to a specific working set, but I think this approach has unresolvable problems. The working set framework doesn't provide a mechanism for sharing working sets. Just persisting the name of a working set isn't useful because every person who checks out a project (potentially 100's of people?) has to know to create a working set with the correct name and the correct contents. So we'd have to persist and share the contents of the working set ourselves. Sharing them ourselves is awkward because working sets are globally scoped and stored in the metadata, but we want their contents to be shared with a project (project scope) in the repository (data, not metadata). Having them stored in the .launch (shared) *and* stored in the metadata introduces a nasty synchronization problem. I propose replacing the working set component in the Builder tab with a checkbox tree viewer displaying the contents of the workspace. The launch config can then store the selected resources as a flat list of workspace-relative paths. When a build is run, we check if the delta matches the list and only run the build if it does. This approach is simple to implement (none of the synchronization problems of working sets) and easy to understand for the user.
I assume that a builder will generally be interested in resources in the project for which the builder is associated. However, we have to be careful to handle the cases (and present in the UI), where the list of resources (paths) do not exist in the workspace.
*** Bug 31510 has been marked as a duplicate of this bug. ***
We are also thinking about the concept of a "private" working set. This would be a working set that is only editable via a defined entry point (the external tool builder Build Options tab). This working set could be shared via the .launch file of the builder. It would be really nice to make use of the existing working set support framework.
In tomorrows integration build, we provide support for the user to specify a working set of resources. If these resources change as a result of the build, the external tool builder is run. Specifying the working set is done on the Build Options tab for the External tool builder. We made use of the existing working set API to edit and persist the working set in the .launch file for the external tool builder (note bug 37506). As the working set is included in the .launch file, the users can share the working set.
Jared, please verify this implemention.
Verified.
