[jbosstools-dev] Re-thinking the EE Modules Page

[Max Rydahl Andersen]

Yes, their page/approach is very weird.

I think you should collect the usecases where it breaks and report it in 
bugzilla and then post to wtp-dev with a highlevel summary and
see how they react. The same summary/bugreports we need to go forward 
anyway and if that includes adding a "Working EE Modules Page by JBoss" 
prefpage
then that is what we should do.

I would really like to understand how IBM and BEA's eclipse based tools 
handle this - do they have fixes that is not in WTP or do they live with 
the same problems ?

-max

Rob Stryker wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev