Community
Participate
Working Groups
in org.eclipse.pde.internal.build.fetch.CVSFetchTaskFactory.java CVS checkout task does not set the attribute failonerror="true". Now since it defaults to false, therefore even if there is failure in exporting code from repository, the build tries to continue and then fails. Its difficult to find out at that point why it has failed. Suggestion:- by default failonerror="true". Allow optional from build.properties or maps arguments. Prince Singh Drishti Soft Solutions Pvt Ltd
Created attachment 55684 [details] Patch implementing the improvement This patch implement a generalized version of the proposed improvement. With this, users can set the property failOnFetchError to cause a build failure. The property has to be honored by all repository providers thus changing the API contract.
Andrew, could you please review.
(In reply to comment #1) Seems fine to me. Prince Singh Drishti Soft Solutions Pvt Ltd
this looks like a reasonable and simple change, thoughts Andrew?
A couple of things: In the COPYFetchTasksFactory.printCopyTask, there is already a failonerror being printed (see 2 lines up), the method takes a boolean parameter for that attribute. It will need to change to either take a string (property) or to take nothing and just print the property. As well, I think the FetchScriptGenerator should probably write out a default value for failOnFetchError at the top of the fetch script in case it isn't set in the build configuration build.properties
Agreed on printing a default value. I did not print it because it seems that ant behaves nicely when the property is left undefined.
*** Bug 157137 has been marked as a duplicate of this bug. ***
I have played with this and it turns out that the patch is far from being sufficient because there are cases where the fetch is expected to fail, therefore no build would ever be able to succeed with such a setup. The example where the fetch is expected to fail is when one used the "fragment@" tag in his map file but where the actual file in the repo is a manifest.mf. For obvious backward compatibility reason we first try to get the fragment.xml and then the manifest.mf. This attempt to dl the fragment.xml could only be avoided by correcting all the map files to use the type (i.e. "bundle@"). Andrew and I believe that the solution could consist in updating the fetch factory api to have the generateRetrieve* methods take an additional parameter saying whether or not the fetch is expected to fail. Unmarking 3.3 because this would require api changes and the impact of the solution is broader than what we want at this stage.
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.
