Bugzilla – Full Text Bug Listing
| Summary: | Need to get rid of .deployable folder | ||
|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Vijay Bhadriraju <vbhadrir> |
| Component: | jst.j2ee | Assignee: | John Lanuti <jlanuti> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | afalduto, ahsv, andreas, carsten, david_keller_fr, deboer, gorkem.ercan, igorzep, ivphb1x02, jeffliu, john.oshea, juergen.zimmermann, jxhuang, kathy, kkatyal, matt, Michael.Valenta, neilkongca, pavery, raul.fernandez, robertdaniel, ryman, sppatel2, tadwoods, thatnitind, tvwww, tyip, werner.keil, yung-chang.chen |
| Version: | 0.7 | ||
| Target Milestone: | 1.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| See Also: | https://git.eclipse.org/r/107190 | ||
| Whiteboard: | |||
|
Description
Vijay Bhadriraju
*** Bug 97008 has been marked as a duplicate of this bug. *** *** Bug 93448 has been marked as a duplicate of this bug. *** *** Bug 90560 has been marked as a duplicate of this bug. *** *** Bug 98298 has been marked as a duplicate of this bug. *** Moved severity by mistake Changed Version field given new release numbering. *** Bug 97162 has been marked as a duplicate of this bug. *** *** Bug 100119 has been marked as a duplicate of this bug. *** *** Bug 102094 has been marked as a duplicate of this bug. *** *** Bug 101340 has been marked as a duplicate of this bug. *** Moving to M8 as Server tools will not be able to drop in time for 0.7 This does not drastically hinder the user experience in 0.7, deferring to 1.0 *** Bug 99609 has been marked as a duplicate of this bug. *** 107021 has been openned to track the changes on the server side *** Bug 107531 has been marked as a duplicate of this bug. *** *** Bug 105206 has been marked as a duplicate of this bug. *** *** Bug 105228 has been marked as a duplicate of this bug. *** *** Bug 109083 has been marked as a duplicate of this bug. *** The problem, that .deployable shows up in the team synchronizaton seems to result from every CVS folder being copied from a (versioned) web source to the appropriate module under .deployable. *** Bug 109210 has been marked as a duplicate of this bug. *** *** Bug 107611 has been marked as a duplicate of this bug. *** *** Bug 109240 has been marked as a duplicate of this bug. *** *** Bug 107113 has been marked as a duplicate of this bug. *** *** Bug 104533 has been marked as a duplicate of this bug. *** (In reply to comment #19) > The problem, that .deployable shows up in the team synchronizaton seems to > result from every CVS folder being copied from a (versioned) web source to the > appropriate module under .deployable. Seems to be a bug on the ECLIPSE (Team) IDE side. Since 3.2 M1 ignores the .deployables folder correctly if told to (via Team settings or .cvsignore) Yes, there was a bug in the CVS plugin that has been fixed in 3.2 as described in bug 107113. *** Bug 108390 has been marked as a duplicate of this bug. *** *** Bug 111129 has been marked as a duplicate of this bug. *** The discussion here seems to wander off to the subject of .deployables showing up incorrectly in CVS synchronization. Note that this particular point is discussed in more detail in bug #94602. So, what is *this* bug report really about ?? I did not really get the point from the original description. Good question!;-) If all about getting rid of .deployables was for synchronization, then this has been solved by bugfixes in other parts of Eclipse. If there are other reasons to get rid of .deployables and deploy via other folders, then THAT would be the main reason for this bug. There are quite a few defects are duplicated to this one. First I would like to say if there is not need for this directory, please remove it. It causes a lot of problem. The sync inside the workspace is always troublesome, and the builder only do incremental build, if I have old backend mapping, after I delete it and create a new mapping, old mapping is still in .deployable, it would cause deploy and runtime errors. Again if we don't need it, please remove it. Hi, Yes, this bug is being used for the complete removal of the .deployables. We will still have a Java bin folder per module, but all assembly will be done outside of the workspace. We are within days of the initial removal, at which point we expect to have a few builds with publishing issues as we work out the details in each server adapter. (In reply to comment #32) Thanks for the feedback all of you, and thanks Tim for your explanation. > Yes, this bug is being used for the complete removal of the .deployables. We > will still have a Java bin folder per module, but > all assembly will be done outside of the workspace. Hmm.. I have 2 questions here -- If the "bin" folder only contains Java classes, and 'all assembly is done outside of the worskpace', then: - where will 'all assembly' take place exactly ? - how is it an improvement over the .deployables approach ? With the current approach, at least you have all your bits in one single place. Furthermore, regardinng assembly: If you use Tomcat as the target server with the "run modules directly from workspace" option, then technically I suppose there are only two choices: - the current .deployables folder - OR, revert back to pre-M4 style and tell the server to use "ModuleName/WebContent" as the module root, which implies you have to compile Java classes to "ModuleName/WebContent/WEB-INF/classes".... Meaning, assembly *stil* takes place in the workspace. So, I fail to see an alternative scenario which would be a real improvement on theses 2 options ? Not to mention that with the current Tomcat server adapter, you still have a lot of data in the workspace anyway (in .metadata/.plugins/org.eclipse.wst.server.core), including serialized sessions and compiled JSPs in the tmpX/work/Catalina/localhost/ModuleName/ subdirectory (where 'X' is the server "order number"). Is there any documentation available that describes the new approach that is being implemented ? Or posts on wtp-dev perhaps ? > We are within days of the initial removal, at which point we expect to have a > few builds with publishing issues as we work out the details > in each server adapter. So, looks like it' s a pretty definitive plan and very close to final implementation then ! I suppose it will then definitively be in M9, as indicated by the target milestone for this bug ? OK... I'd better stop bothering you for now with questions ;-) Thanks, Laurent Please see my note to the wtp-dev mailing list. This work has been in progress for several weeks, and I've tried to explain the change and the impact to this week's I-build. (In reply to comment #34) > Please see my note to the wtp-dev mailing list. This work has been in progress > for several weeks, and I've tried to explain the change and the impact to this > week's I-build. Thanks a lot Tim, I think I found your post, here's the URL for the convenience of everyone: http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg02620.html As per your message, it does appear that the situation is quite complex, esp. regarding deploying a module to several servers, and the handfling of remote servers too. Well, I suppose it's just wait and see now, I'm looking forward to looking at the result in M9. Cheers, Laurent *** Bug 111734 has been marked as a duplicate of this bug. *** The j2ee component builders and deployables folder are now removed. They will be replaced via Tim's note, see link above. We will treat all new problems as new defects as we will not be creating a deployables folder any longer. This is fixed in the 1007 WTP M9 integration driver. *** Bug 116849 has been marked as a duplicate of this bug. *** closing verified on 11/22 S build New Gerrit change created: https://git.eclipse.org/r/107190 |