Bugzilla – Full Text Bug Listing
| Summary: | Manifest builder should keep build.properties and plugin.xml in sync or at least mark inconsistencies | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Dejan Glozic <dejan> |
| Component: | UI | Assignee: | Janek Lasocki-Biczysko <janek.lb> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | cherie.wong, curtispd, Darin_Swanson, dj.houghton, eclipse, francois, heatherf, jean-michel_lemieux, jeffmcaffer, kim.moir, markus.kell.r, marshall.culpepper, mawanli, michaelvanmeekeren, mlists, n.a.edgar, pascal, pwebster, ryanman, sonia_dimitrov, wassim.melhem |
| Version: | 2.1 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Dejan Glozic
In the mean time, I learned that it is legal to list a library that is not listed in plugin.xml (for example, Update UI component builds the web application servlet jar that is not listed in plugin.xml). Therefore, I am not sure we can do this check without 'false alarms' (typos versus genuine JARs that are not and should not be listed in plugin.xml). We can do a slightly different thing: flag the missing library entry in build.properties for each library specified in plugin.xml. *** Bug 75765 has been marked as a duplicate of this bug. *** *** Bug 85268 has been marked as a duplicate of this bug. *** From bug 75765: "the name of the code jar for a plugin appears in two places, the plugin.xml/manifest.mf and the build.properties. It would be good if there was a warning if the value in the manifest.mf does not have an entry in the build.properties. There will be cases where the jar is prebuilt so the build.propreties does not have a source.foo.jar= line. In this case there are to possibilities. Either is an over eager warning or PDE could be even more deluxe and check the expressions on the bin.includes line. Typically it either has the jar name (third copy) or *.jar. I just spent about 30 min trying to figure out why it worked fine when running self hosted but not when built and deployed (I got class not found exceptions everywhere so spent most of my time looking at plugin dependencies, resolved states, ...)" From bug 85268: "This morning's build failed due to an inconsistency between the plugin.xml and build.properties files for the new plug-in org.eclipse.core.components. The plugin.xml had: <runtime> <library name="components.jar"> <export name="*"/> </library> </runtime> but the build.properties had: source.component.jar = src/ output.component.jar = bin/ bin.includes = plugin.xml,\ component.jar,\ about.html src.includes = about.html In the build.properties, all occurrences of "component" should have been "components". It would be nice if the PDE checker produced an error marker in this case." *** Bug 87275 has been marked as a duplicate of this bug. *** *** Bug 92913 has been marked as a duplicate of this bug. *** *** Bug 96000 has been marked as a duplicate of this bug. *** *** Bug 93454 has been marked as a duplicate of this bug. *** *** Bug 108198 has been marked as a duplicate of this bug. *** Ok, I think now it is about time to fix this problem! Yesterday I and another person spent 1 hour (total 2 hours men) fixing up various build.properties bugs spread across multiple projects (the output folder was not consistent was not properly listed) Today I and a few others spent 10 min (eq 50min men) again tracking another pb where the name of the jar in the manifest was not in think with the build.properties. Overall I think this bug now deserve some attention. In fact the real requirement is not so much to have a mechanism to keep things in sync automatically, but instead to have a mechanism that flags inconsistencies between manifest.mf and build.properties. that is correct. that is why it is an enhancement. It requires an additional PDE builder for properties files that can flag markers at the correct line etc. It is a big piece of work. and a lot of people would be thanksfull if it was considered for 3.2, as the mismatch between manifest.mf and build.properties causes errors on export that are almost impossible to find if you are not from the pde team, and makes people give up the usage of pde build to export their plug-ins. +1 +1 and I'll even use one of my votes for it! Please, please, please. +1 I just used my vote for this. Overall, problems with build.properties/manifest.mf/plugin.xml has been costing us too many headaches (I wasted 3 hours with various build issues today). The main problem is that everything is fine until you export (e.g. the build process finds them). Since problems in this area will cause the build to break, I think errors are good for fundamental problems (e.g. jar listed in manifest but not in properties, or missing properties, or icons should always be included in the output). I've heard comments equivalent to JML's from several people building RCP apps. It works fine when they run under PDE, but when they export things are broken. Assigning to JLB (not to be confused with JML). Janek, please start with the parsing and matching keys/values with the correct line numbers. Once that is done, we could add the semantic validation. Added a validator for the build properties page, severity level can be controlled on the PDE compilers preferences page. When creating an EMF project, a plugin project is created which - prior to generation of model code - contains no build.properties file. After 3.2M4, I get the following error in my Error Log.
Error
2006-02-09 12:17:28.698
Resource /com.example.po/build.properties does not exist.
I turned off ALL the compiler messages under Window > Preferences > Plug-in Development > Compilers and I still get that error.
Downgrading it to Warning didn't work either - I always get an Error, regardless of the setting {Ignore, Warning, Error}.
Is this the way this preference is supposed to work? Is the absence of a build.properties file meant to throw an error, as opposed to having an invalid one?
re comment 22, what you are seeing is bug 126703 which has now been fixed. Please so not reopen this bug and file separate bug reports instead if you see other problems with the validation. |