This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I would appreciate the build process to skip just errorenous modules and modules depending on it instead of marking whole build as failing. Failing are just some modules not the whole build.
Should be marked as "As designed", becasue there are inter module dependencies, which will not be satisfied if one module fail, so there can be snowball efect in failing modules. We would need some facility to define which module is safe to fail and which one is not (it could be fairly complex). E.g. if java module or editor module fail what would be result of such build? Hhow many or which modules are accepted to fail and so on. If you need to build just one (probably your) module, there are better ways how to do it, then this.
I changed priority to P4 and issue type to request for "ENHANCEMENT", because this is not a bug. If continuous build fails on modules which should be ready for night build, we can not skip them. If you want to make sure that your module compiles fine, just use -Dmodules=your,modules,configuration.
Target milestone -> 3.3
Petr, Is this still problem or can I resolve WONTFIX?
It is still valid enhancement. IDE is modular and build process does not reflect it.
We don't plan to implement this. If you have a way how to do that with Ant, please let us know that.
You can write a wrapper task turning non-platform module failures into warnings.
Petr, you probably know what you want so it would be nice to provide us a detail proposal of procedure plan how to do that including resolving modules dependencies, checking for failures, special switches etc.
I do not how to overcome a lack of dynamical dependency management in Ant. But while building IDE from sources I do not care that some other module (e.g. XML) failed while I am working on unrelated module (e.g. RMI).
Ant permits dynamic running of targets from within special tasks, if you bother to write them. See sources for <antcall> task and so on. It is not that hard. The trickiest part would be determining which modules require others (1) at build time (2) at run time. (1) can be determined just by all-* dependencies in the main build script. For (2), you could perhaps just merge what you wanted and rely on the IDE's module system to force you to disable modules which could not be installed. Or you could try to mimic the IDE's dependency analysis, though this could get a bit complicated.
BTW if such a feature is implemented, it should be off by default. If a module fails to build, it is by definition an exceptional case that you should be alerted to by a build failure. If you intend to skip over broken modules, you should have to ask for this. Note that with the long-awaited one-line patch to use <property file="build.properties"/> in nbbuild/build.xml, you could turn this on for your builds by default.
Resolving to remind.
Reopening to resolve.
Accepting
Created attachment 6965 [details] Patch for NbMerge.java to enable build success granularity
Jesse, would you, please, review the patch. It's the core of build process. The patch brings two new attributes "fixedmodules" and "failonerror". Also it should be backward compatible.
Ack, please use diff -u next time so the patch is readable: http://www.netbeans.org/devhome/community/contrib-patches.html You may want to fix issue #24489 at the same time since Michal never did anything with it and the patches probably overlap. log("SOME MODULES FAILED TO BUILD...") should probably use MSG_WARNING. Suggest nbbuild/build.xml set failonerror to ${stop.when.broken.modules} (for example), defaulting to true in build.properties so a user can easily override in user.build.properties. Other than that - I don't exactly understand how it works from seeing the patch, but it looks reasonable enough. I assume you tested it in various cases and it works. What happens if you do e.g. ant -Dmodules=java/api,classfile,java and there is a build error in java/api during 'compile'? Will it correctly skip running java/build.xml, and skip merging not only java/api/netbeans/ but also java/netbeans/? Now what about if there is a build error in java/api during some noncritical subtask of 'netbeans' ('javadoc', say) which is not needed by java/build.xml to complete but which java-api.jar needs at runtime (and hence java.jar needs as well) - will it then skip building and merging java too, or will it try to build it anyway (in which case java.jar will be in the build but will be disabled because java-api.jar is missing)?
Jesse I did a few more changes, so my response here is related to current development state (forgot the first patch attached to this issue). > log("SOME MODULES FAILED TO BUILD...") > > should probably use MSG_WARNING. done > What happens if you do e.g. > > ant -Dmodules=java/api,classfile,java > > and there is a build error in java/api during 'compile'? Will it > correctly skip running java/build.xml, and skip merging not only > java/api/netbeans/ but also java/netbeans/? Actualy it's not intended to skip running java/build.xml. The sourcecode/compile-time dependency between "java/api" and "java" will cause "java" to fail. So if java-api.jar will be missing then java.jar will not be built. I tried it with "ant". I renamed directory "ant" and tried to build. Module ant was tried to build and failed (exception catched). Module apisupport/ant was tried to build, but also failed. Should NbMerge look if some of modules, the current target depends on, failed and though the current target should not be run, even it would be compilable, because the module it dependens on failed in some non-critical task i.e. "javadoc"? List of successfuly built modules is used for merging. Modules which failed to build are ignored. About current development state: I added one more attribute "mergedependantmodules" which is "false" by default. It's handy for developers when they want to build just one module, and don't want to care about merging modules it depends on. say: ant -Dmodules=javacvs -Dmerge.dependant.modules=true merge will try to build javacvs and the merged directory will contain usable IDE with at least module javacvs. In this case it means merge of additional modules editor, openidex, vcscore, diff.
Created attachment 6978 [details] Current patch with merge.dependant.modules
BTW: Issues 24489 might get resolved by the patch I've just attached. There's no call to ExecuteTarget, but just execute (due compatibility with Ant 1.3). All targets before "merge" will get new unless condition which will deny their execution. Also all successfuly built targets are written to Vector and before every execute is a check whether the target wasn't already executed.
Re. continuing after errors in modules you depend on: that should be fine. I was pointing out that there are some runtime non-compiletime deps, for example one module requires an HttpServer, another provides it, but they do not compile together. In that case if the provider fails to build, the requirer will still merge, but be disabled at runtime by the module system. I guess that is no problem. merge.dependent.modules sounds good. (The spelling seems right in the patch, though not in your comment.) I assume it computes dependencies based on the compiletime deps listed in all-* targets in the master script? That is not exactly accurate, since (as just mentioned) the runtime deps may be a subset or superset of the compiletime deps, but it is an OK approximation I think.
Fixed in trunk.
Changed target milestone
Integrated into 'main-golden', will be available in build *201302222300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d31b32da0fc3 User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: temporary remove java.platform tests (NB-Core-Build #9701: Still Unstable)