The EE Modules page needs to be improved (IMO). I'm gonna list some of the problems here with it, and then ask for feedback as to how (or even if) I should spend time on this patch. I've spent a bit of time today familiarizing myself with the code. Some details: 1) Every EAR project has a designated "lib" folder. This is stored in the application.xml (if one exists) or just defaults to "lib". 2) On a raw xml file level, each child project (utility projects, web projects) can designate it's deploy directory inside the EAR by using the "deploy-path" attribute in the components xml file. The current page doesn't show this. a) In fact, the current page only has is a checkbox as to whether it's in the designated lib folder or not... and this checkbox is often wrong b) And the checkbox uses really weird logic to initialize itself (ugly code) and there's a delay before it appears, and when it does appear it appears on the left, and then 2 seconds later moves itself over to column 3. Really odd. 3) Binary child modules are treated... oddly. a) If the binary module is in the EarContent folder, it's listed in the viewer (but cannot be relocated in this prop. page). b) If the binary module is in the lib folder (EarContent/lib or whatever application.xml says is right), it's listed in the viewer (but cannot be relocated in this prop page) c) If the binary module is... anywhere else in the project, it's not even listed, even if it should be. I've traced through. It gets filtered out. Odd. 4) When on this property page, if I select "Add Jar", It lets me browse the workspace for jars (in any project) that I want to be in this project (I think? Not sure if it's just for classpath or not)... however if I select a jar that's already in the ear project, nothing happens. a) Adding jars from other projects does add a line to the components xml file, but not quite sure it's behaviour yet (bundle or just CP entry) 5) Adding an external jar seems to work fine. The only difference between adding a workspace jar and external jar seems to be absolute or relative path. 6) You can add classpath variable entries. Still have not yet investigated how exactly they work. 7) You can change the Library directory in the application xml. Any reference that has the current lib directory as its deploy path will be re-assigned the newly-typed value as the new one. Now, I can clearly use whatever logic they need done on performFinish and clean up the UI at the same time if I need to. My question is, is this worth pushing, and considering the breadth of problems, is it better if I just try to clean up the entire class and send them a new one for their consideration rather than try to isolate specific complaints and have to bicker over all of them? Also: I believe I know why their UI is so limited. They're trying specifically to limit the possibilities to that which is supported by JEE. For example, having all sorts of random utility projects / jars being deployed to whatever folder you want clearly isn't EE supported, but I believe it's more humane. WTP wants to reduce this choice to only a "lib folder" or "root" choice, (or if you place the file directly in the project, then it lands "wherever you put it"). If I were to recode it and keep all the functionality while actually making it work, which jars in the project SHOULD show up? Currently it's only root / lib folder jars. All others are ignored. Should they be ignored on this page or not? Would a text box work better than a checkbox? Obviously it'd be more configurable, but perhaps their usecase of limiting complexity is good? Thoughts / comments please. thanks. _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev