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.
Peter Belbin originaly wrote comment to the issue 147592: 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.
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.
Couple of thoughts/questions: if C does not depend on A it should still notice that it is not up to date because a web service descriptor from project B (WSDL, or whatever technology you are using) has changed (an object from A must be described in Web service descriptor, right?) I mean if a change in A affects web service interface then both C and B needs to be rebuild and this should work now, no? Actually what would you expect to happen? If you do a change in A and pressed Save do you expect B and C be automatically redeployed? Deploy on Save question: if I change something in Java Library project XX does Web Project ZZ gets redeployed automatically (assuming ZZ depends on XX and has already been deployed)?
> Deploy on Save question: if I change something in Java Library project XX does Web Project ZZ gets redeployed > automatically (assuming ZZ depends on XX and has already been deployed)? It is (re)deployed on Build/Clean & Build of that library, not on save of the file (this would require jar to be prepared on save, turning the semantic to build on save and introducing performance issues).
a) to clarify things, I think that DoS should be renamed DoB (Deploy on Build) since that's what it is now doing, at least for JAR and WEB projects...? b) I think we're talking about the same things. the idea is that: if there is a direct project dependancy, the dependant project should build and deploy if the underlying project is built due to an update (ie: user hits the 'build' action). also: if there is a web reference between projects, and one of those projects is updated, the dependant projects should also be updated, particularly if something that's being exposed by the server has changed (ie: added/removed/altered). if such a web reference dependancy exists, the server must be updated first, then the clients of the web service. it would be great if the system were smart enough to differentiate between a case where project A had a change which affected the exposed objects by project B's web service or not. here is where this 'knowledge' would prove useful (I'm using numerics to keep separate from my alpha example): project 1 is a JAR project 2 is a web app that exposes a web service project 3 is a web app that depends on project 1 JAR and consumes project 2 web service. project 1 jar is built due to code change. project 3 would then be built also. note: no change to project 2 is needed since it does not rely on project 1 jar and is a server of the web service. note also: if project 2 is built, project 3 should be built too (after project 2) due to web service reference dependancy - ideally, only if the exposed objects signature changed. if the signature of the exposed objects do not change, there really is no need to rebuild project 3.
I think we are converging on language/understanding of the issue. Thanks for your comments. Calling it "Deploy on Build" is be more appropriate in scenario of inter-project dependencies. In case of editing single web application it is still "Deploy on Save". re. "project 1 jar is built due to code change" - which triggers redeploy of project 3 as expected, right? re. "note: no change to project 2 is needed since it does not rely on project 1 jar and is a server of the web service" - which is correct and as expected, right? re. "if project 2 is built, project 3 should be built too (after project 2) due to web service reference dependancy - ideally, only if the exposed objects signature changed." - yes but this depends on how you set up your projects. My knowledge in WS domain is limited but example I have in mind is this: project 2 defines a MyService.WSDL file defining a web service signature and implements the service. Now two scenarios: Scenario S1: project 3 references the MyService.WSDL file directly from project 2. In this scenario changing the web service definition (that is MyService.WSDL) and saving it should cause both project 2 and project 3 be redeployed. Scenario S2: project 3 has its own copy of the web service definition LocalCopyOf-MyService.WSDL because it is desired to keep projects decoupled (e.g. you can enhance service and deploy it and test that old clients are still running; or web service client is developed by different team; or ...). In this scenario user's software development process must ensure synchronicity of deployments and IDE cannot help much IMO. Would you agree? What does not work now?
yes, I would agree with what you're saying. where ide-aware defined interdepenancies between projects have been defined (ie: web service client uses wsdl identified as being from another project that's open in the ide) should allow automatic re-build when a change of a dependant is observed/detected. if however, the cross-project dependancy is not established, as would be the case with static wsdl files contained within the same project as the client of the web service, then it's up to the developer to ensure builds are done as needed. whether an established dependancy is against the web service itself or a static wsdl *in another project*, change to either in the 'server' side should still trigger the re-build/deploy of the dependant 'client' project.
RE. "change [..] in the 'server' side should still trigger the re-build/deploy of the dependant 'client' project" - and that's what I think is happening already, no? If you change a file in a project which has been deployed then project is automatically redeployed; if you build a project then any projects which depend on it and which has been deployed will get redeployed.
that is true. however, in the original project A, B and C case, for example, netbeans re-(build & deploy)-ed project A then project C then project B. project B is the server for project C, and should have been dealt with before project C. same thing goes for the other examples, and that's what this issue is about: the use of web service references to further refine the dependancy tree so that it has awareness about these inter-dependancies that it appears not to have currently, but, which it needs. IF there were a 'project group make' or 'project group dependancies' or just 'project build order' type of dialog thing to capture the order the builds should be done in (possibly having a 'auto scan' type button to do it via known dependancy types), the desired order could be auto-populated but still be able to be modified by hand (and this could have benefit way beyond just web service dependancies).
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss