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.
From Peter Belbin: I have a set of 10 projects. 5 of these are deployable web applications. the other 5 are jar files which the other 5 web apps rely on. so: with the 'compile on save' (but not 'build on save'), I am apparently only able to build the jar files with a clean and build. ok, lets say I do clean and build on the 5 jar projects. now, how do the projects that are depending on the freshly built jar files to know that they need to be rebuilt? they don't.
With the classic ant approach: The build of the dependent jar is performed on run/deploy/build. With DoS: EE app is redeployed on class/resource change. When the class/resource is changed in dependent project nothing happens. When run is executed the app works as expected. There is no easy way how to solve this because library jar has to be prepared for EE app. - listening for dependent projects, create jar in the code somehow from CoS classes - we can't be sure have created the "right" jar (same as ant would build), redeploy - listening for dependent projects, create jar through ant (this would perform clean too), redeploy - disable DoS for these configuration ...? First two solutions can be performance killers too.
Well, as I understand it (I am not a Web/Web support expert, so sorry if I misunderstood something): -we have to have libraries as jars, because the technology works this way -the situation with DoS enabled is actually better than with DoS disabled (changes in the Web Project itself are auto-redeployed, changes in libraries are not). If the library jar is updated (the library is manually built), is the application re-deployed? It should be possible to achieve this. So, I do not think it is good to prohibit DoS in this case (esp. if DoS enabled is no worse than DoS disabled), sorry. The default value (on/off) is a different matter, but that is a more general discussion, I think. I personally do not think that "build on save" is reasonable - the jar step alone could take a long time for medium and bigger projects.
> -we have to have libraries as jars, because the technology works this way Correct. > -the situation with DoS enabled is actually better than with DoS disabled (changes in the Web Project itself are > auto-redeployed, changes in libraries are not). If the library jar is updated (the library is manually built), > is the application re-deployed? It should be possible to achieve this. Right now it is not and you are right this should be possible. Let's consider this as another option. > So, I do not think it is good to prohibit DoS in this case (esp. if DoS enabled is no worse than DoS disabled), sorry. > The default value (on/off) is a different matter, but that is a more general discussion, I think. Yes, the question is about the default value, not about the feature itself. > I personally do not think that "build on save" is reasonable - the jar step alone could take a long time for > medium and bigger projects. Agreed this could be problematic.
Let me reiterate/clarify the proposals and give them numbers so we can refer to them by number. And add a few more proposals that we may want to think about. We may also consider a combination of several of these proposals. 1. listening for dependent projects, create jar in the code somehow from CoS classes - we can't be sure have created the "right" jar (same as ant would build), redeploy 2. listening for dependent projects, create jar through ant (this would perform clean too), redeploy 3. make DoS turned off by default for these configurations 4. listen on the jar artifact in the subordinate library projects (produced by the Clean and Build action) - after the jar file is created, deploy it to the server. This would not fix the immediate redeployment of changes in libraries, but at least Clean & Build on a library would have the desired effects. 5. change Compile on Save to better interact with the Build action, so when CoS is on, I can do Build, rather than Clean and Build. E.g. if CoS only produces class files from correct sources, would this eliminate the need for Clean before build? 6. turn off CoS for libraries used in web project. I.e. when I use "Add Project..." to add a library in the Libraries customizer of a web project, NetBeans would offer to turn off CoS on this library. 7. introduce a "pull" model for uploading changes to the server. Currently we are trying to upload all the changes to the server immediately ("push"). But we could do something like this: - When a Java file in a library is changed, CoS produces a class file. - Web project that uses this library listens on this event, and remembers that this library is "dirty" (its jar file needs to be created and deployed) - Web project pings the server and notifies it that this application is "dirty" (its artifacts need to be updated before it is accessed the next time) - When the user clicks Refresh in the browser to access the application next time, the server knows the application is dirty, and pings the IDE to request update of the application artifacts. - IDE produces the jar file for the library and copies it to WEB-INF/lib, then notifies the server - The server refreshes the app and shows an up to date version of the app This helps in the scenario when the user edits 10 files in the library and then clicks refresh in the browser - the library jar file is built once rather than 10 times.
Chosen solution is to listen for jar changes (when DoS enabled) of dependent J2SE projects. J2SE project will have Build action available without any restrictions unless it has IDE generated classes in build dir (in such case dialog appears).
Fix for web project: 29602c3d19fb.
Integrated into 'main-golden', will be available in build *200809270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/29602c3d19fb User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed
Fix for ejb project: f43815cd1fc1.
Integrated into 'main-golden', will be available in build *200809290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f43815cd1fc1 User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed
FYI: the semantics of the Build action has been tuned as described in issue #145002.
Integrated into 'main-golden', will be available in build *200809291401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/762164b895b5 User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed (code duplication)
Fixed for EAR: 822150e85a80.
Integrated into 'main-golden', will be available in build *200809300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/822150e85a80 User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed
e2846dae2474. Fixed as suggested.
Integrated into 'main-golden', will be available in build *200810010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e2846dae2474 User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed
Verified with NetBeans IDE Dev (Build 200810030201) for EJB and WEB projects.
Integrated into 'main-golden', will be available in build *200810070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5dbf9d40986c User: phejl@netbeans.org Log: #147592 EE project does not perform DoS when SE dependent SE project is changed - consistent build action with J2SE
I think we're 'nearly' there. still with the same set of projects as per the original issue, I am seeing: project A is a JAR project which web projects B and C both rely on. currently (as of build 200810070201) I am seeing that project B gets redeployed when jar A is built, but not project C. both projects B and C are configured identically as far as DoS goes. why does project C not also get redeployed? please advise.
Is the project C deployed and server running?
Reporter any comments on this?
Ok, well, I am not saying that the issue is 'fixed' by any means, but I do want you to know that after having restarted the ide a couple of times (it hung, and had to be forcibly killed), the 'build' of a lower level JAR project is now causing multiple webapps that are dependant on that JAR file to be redeployed to the app server. I believe this is 'as intended', although, I'm not entirely sure that the ordering of the redeploys are being done in the correct sequence. ie: there is a dependancy tree that's defined not only by .jar dependancies, but also by web service references, and it seems that this needs to be paid attention to, in order to be fully comprehensive. having said that, it's very cool to see all the various projects get redeployed when a lower level jar file gets updated. it's almost like having a project-group build and deploy button. Hmmmmmm....
I believe the original issue has been fixed. If you encounter a deadlock please file a separate issue with threaddump. According to webservices as the IDE is not explicitly tracking these (if I understand what you meant) it is more likely an enhancement. The build dependency is tracked by project.xml and project.properties and this is reflected by fix for this issue. Filed enhancement issue 149469.
yes, that is what I was getting at. for example: project A is a JAR. project B is dependant on project A, and exposes a web service. project C is also dependant on project A, and consumes a web service from project B. if project A was changed, and happened to be an object that is exposed via the web service in project B, project C should be rebuilt/redeployed AFTER project B, because project C will be looking at old details if it's done before project B is built and redeployed. so: .jar dependancies only tell you part of the story where web references are involved. also, if project C was not dependant on project A directly, but is only by implication due to the web references, you'd want a way of detecting that so you'd know to build/deploy instead of completely ignoring it due to not having a direct dependancy. I will add this bit to the enhancement issue you've already created.
it appears that as much as the 'build' action is now working for JAR projects, it's still not working for WAR projects. is this per your expectations? I have to admit that I was expecting 'build' to be functional on WAR (ie: Web Application) projects as well, now. please advise. if it is now working as expected, I would continue to ask why build is not enabled. after all, if 'build' does not build the WAR output, it's just doing a compile, which means that in order for me to get a WAR that I can distribute, I am still forced to use 'clean and build' which I don't want to be forced into doing if I know I don't need to. please advise.
In any recent version of the ide both types of projects have the same behavior. If there are no ide generated classes in the build dir build action is enabled. If there are ide generated classes the Clean & Build is requirement in order to create production deployable artifact. Build is not doing just compile, it is generating war as well (and jar for j2se project respectively).