Bugzilla – Full Text Bug Listing
| Summary: | Support to have the generated scripts not called build.xml | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Ivailo Abadjiev <ivo.abadjiev> |
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | aniefer, eclipse-bugs, hallorant, mschrag, remy.suen, s.schnabl, tfmorris, zqian |
| Version: | 3.1.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Ivailo Abadjiev
In a plug-in project the build.xml file is reserved for pde and it is a intermitent file unless specified otherwise. If the build.xml you are writing must be used to build the project then I recommend you to use the new support for customSteps in the build script, or otherwise to change name. "build script" – where can be found? Did you mean Ant build script? And if yes, Is this the same build.xml that is deleted after export? And if yes, What should I do so those modified by me build script does not get deleted? RESOLUTION: In plug-in project user should be able to specify where PDE those intermitent files are placed or how they are named. What you are asking is not supported and will unlikely be unless we receive an external contribution. Lowering the priority too. *** Bug 240986 has been marked as a duplicate of this bug. *** (In reply to comment #3) > What you are asking is not supported and will unlikely be unless we receive an > external contribution. > Lowering the priority too. > Working on the patch... Can someone point me to the plug-in where this code (mostly) is? Thanks!!! Looking at this and noting https://bugs.eclipse.org/bugs/show_bug.cgi?id=240986#c5 I think the best solution is leave the UI alone and change the PDE/Build as follows: 1) if custom=true is in the build.properties file then the project is assumed to include a "build.xml" file (at its root) with the required targets. 2) if custom=true is NOT in the build.properties file then a temporary file is generated (per bundle) and that file is used for the build. This has the advantage of not "stomping" over a user generated file, but would be a transparent (and thus backwards compatible) change for all users not running into this problem. I'm working the code to submit a patch along the lines of the above design. (In reply to comment #7) > 1) if custom=true is in the build.properties file then the project is assumed > to include a "build.xml" file (at its root) with the required targets. > 2) if custom=true is NOT in the build.properties file then a temporary file is > generated (per bundle) and that file is used for the build. > We can not change the default in this manner. The name of the build.xml should be considered API and changing it like this will break many existing automated build systems. Note that the major usecase for PDE/Build is not building/exporting in the UI. It is automated headless scripted builds. This bug represents a small corner case and any fix should not impact existing build setups. The main changes for this bug will not be in the java code, but rather the ant scripts. See org.eclipse.pde.build/scripts/genericTargets.xml as well as the generated assemble.*.xml, package.*.xml, and the generated build.xml for features and in some cases plugins. Note that many of the ant targets in the scripts (especially genericTargets) should also be considered as API. Not deleting a user file is an "enhancement"? I was convinced that the problem was someplace in my build because it never occurred to me that Eclipse would willfully delete my file without so much as a "by your leave." Thank goodness for SVN. I especially love the IBM attitude in comments #1 & #3. Basically "We don't care and you can't make us care." Special. My project has used Ant for far longer than Eclipse has been around. Back in the Eclipse 3.0 days I started championing the use of Eclipse and created Eclipse project definitions to wrap around the existing Ant based projects. More recently those same Eclipse projects have been converted to Eclipse PDE projects. Now all of a sudden the PDE team has declared that they "own" that file name? Sorry, that doesn't really work for me. How much less impact would it have had to fix this bug back in 2005? (In reply to comment #9) > I especially love the IBM attitude in comments #1 & #3. Basically "We don't > care and you can't make us care." Special. This particular comment represents a misunderstanding of how Eclipse projects work. IBM does not own Eclipse or any of its projects. Certain people employed by IBM (and many other companies) are committers on various Eclipse projects, but that does not imply any kind of IBM management of those projects. Eclipse projects are driven by a combination of the committers and the community that is served by the project. In the cases where a request, such as this one, is made, the committers must prioritize; because the project teams are generally under-staffed, they must often point out that particular requests can't be served unless someone from the community steps up and contributes a patch. That is just the reality of open-source projects; those who are giving their time to work on the projects get to decide on the priorities. They do take into account the needs of the community, but most of the time there is simply too much to do with the limited people and time that are available. No conspiracy or even laziness, just the reality of open-source projects. The bottom line is, if you want more of a guarantee that something will be implemented you have to step up and help get the work done (unless you can convince a committer or other community member that it is important enough for them to spend their time contributing). > My project has used Ant for far longer than Eclipse has been around. Back in > the Eclipse 3.0 days I started championing the use of Eclipse and created > Eclipse project definitions to wrap around the existing Ant based projects. > More recently those same Eclipse projects have been converted to Eclipse PDE > projects. Now all of a sudden the PDE team has declared that they "own" that > file name? Sorry, that doesn't really work for me. PDE has not only newly started using the file name; from my understanding it has been doing so for quite a while. Yes, the conflict with your own build script is unfortunate. But the attitude reflected in the above comment seems to indicate that you have not read or really understood Andrew's explanation of why it can't change at this time (in comment 8). API compatibility is considered of utmost importance in most Eclipse projects; not only for the Eclipse projects themselves but also to serve the adopters and member companies that rely on consistent API in order to build and maintain their own products that are based on Eclipse. Sometimes I, too, disagree with a decision that is driven by this API compatibility philosophy, but I at least understand why it exists and that enables me to occasionally argue against it or at least circumvent it with alternative solutions. By the way, this discussion, if you wish to continue it, would be better on the newsgroups (eclipse.platform.pde) or one of the dev mailing lists; Bugzilla is not really the appropriate place unless the discussion is focused on a particular problem. Mass change for PDE Build bugs tagged with "helpwanted". PDE build is not actively enhanced, hence I close these bugs as wontfix. Please reopen if you want to contribute a patch. |