Community
Participate
Working Groups
This bugzilla will act as the "container" for related activites addressing the various issues regarding the Java EE Module classpath model and Property sheet. Rob Stryker did a very good job listing the various issues, and we may choose to open up individual linked defects to capture each issue. This will also start a good discussion for not only fixing the immediate bugs, but enhancements and future direction in this area. Rob Stryker wrote: > The EE Modules page needs to be improved (IMO). I'll list some of the > problems with it first, and then ask for feedback as to how (or even > if) time needs to be spent fixing this page. For the duration of the > email, let's assume I'm speaking entirely about this page for EAR > projects. > > Possible conclusions could be any one (or more) of the following: > 1) This is simply a series of small bugs and each should have their > own bugzilla > 2) The code is a bit complex and could use a general cleanup > 3) Perhaps the page is too focussed and could be generalized while > still retaining all of its charm ;) > > One of the first things I notice about jee tools is that it's > basically a semi-thick wrapper around the Virtual Component Framework. > The virtual component framework at its raw level provides a lot of > functionality for both related / nested projects, but this property > page doesn't. It seems to be pretty limited to Java EE (and judging by > its name, with good reason). > > Let's address a few specific issues. > > 1) The very first issue is what shows up in the viewer. > a) For binary modules inside this project, they *only* show up if: > 1) they are in the EarContent folder, or > 2) they are inside the designated lib folder. > If they are anywhere else (such as EarContent/my/brother) they do > not show up. > > (Some of this logic is inside > AvailableJ2EEComponentForEarContentProvider.shouldShow(etc), where it > > > So we're showing binary inner modules, but only if they're in > EarContent, or EarContent/lib. Perhaps we should either > a) show all inner binary modules added directly via FS, or > b) show no inner binary modules added directly via FS > > > 2) On a raw XML level, org.eclipse.wst.common.component can set a > "deploy-path" for any dependent module. So you can deploy that > dependent utility jar to /foo/bar if you want. > > <dependent-module > archiveName="Util2.jar" > deploy-path="/somewhere" > handle="module:/resource/Util2/Util2"> > > The current page does not show that this utility jar will be published > in /somewhere. The current page only shows a checkbox stating whether > this deploy-path is in the designated lib folder or not. And often > times this checkbox is wrong. In the above example, despite > "/somewhere" *not* being "/lib" (and also not being the designated lib > folder in the application.xml), the checkbox is still checked. The > method at fault this time is > AddModulesToEarPropertiesPage.isInLibDir(etc) > > Basically, if the file is sitting inside EarContent, it says it's not > in the lib dir. If it's sitting anywhere else > (EarContent/my/brother/bob) it says it *is* in the lib dir. It never > checks the libDir string to compare. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=276463 > > > 3) "Add Jar" allows you to select a binary Jar that's already inside > the project, and when you press OK nothing seems to happen. Publish > and export of all other added jars works fine. This jar still suffers > from problem [2] > > 4) Selecting "Add an external jar" does modify the components xml file > when applied, and publish and export work fine. This jar still suffers > from problem [2] > > 5) You can add classpath variable entries.... however if I made a > variable that pointed directly to /home/rob/tmp/some2.jar, and apply > the change, the following gets added to the component xml file: > > <dependent-module deploy-path="/" > handle="module:/classpath/var/some2"> > <dependency-type>uses</dependency-type> > > But upon a publish this file is not included. Upon an export, this > file *is* included, but it's name is "some2" and it lacks a file > extension. > > > 6) The second checkbox that appears first appears in the left column, > then moves itself over after 2 seconds to column 3. This is kinda > jarring. > > > -- > > So aside from the publish / export issues, which I'm concerned about > in the long run but for this particular email I'm focussing on UI... > and specifically the existence of column 3, "Is in Lib Directory". I > think that because the raw component xml file allows you to set an > actual deploy path, adding this to column 3 could be a much better > choice, rather than having an often-innacurate checkbox that moves > around and doesn't convey all the information of the underlying xml file. > > I've been thinking of making a patch primarily to remove this checkbox > and replace it with a modifiable text box, but the current code is a > bit messy so I was wondering if, assuming all button-logic and > interaction with the underlying xml file remained constant, if this > would be a patch WTP would be interested in. The patch would likely be > large but touch only one or two files; the reason for it being large > is that much of the code would be re-written and cleaned up. > > Is this something WTP would be interested in, or do they genuinely > believe limiting a user to the LIB folder for the purposes of staying > within the boundaries of JEE is a better idea? My solution would be > more versatile (you could have 10 utility jars all being put in > different places in the resultant EAR) which is already supported by > the component xml, but your argument may be "why would anyone *WANT* > to do that?" > > If I were given permission for this, or told my patch would be > welcomed, I could probably fix bugs [1], [2] and [3] in the process, > however the export operation / publish operation bugs would be beyond > the scope at the moment. > > Thoughts?
One more issue related to org.eclipse.wst.common.component and source folders in java projects such as Web, EJB etc is the automatic entry in the .component file like <wb-resource deploy-path="/WEB-INF/classes" source-path="/test"/> Given that .component file creates a "deployment view" of the artifacts in a project, a user who wants to create a source folder having test code which he doesn't want to deploy on the server but does not get an option in the UI to exclude that source folder from .component.
Related bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=276463 https://bugs.eclipse.org/bugs/show_bug.cgi?id=279386
Point 5 in the writeup was also given its own bug ID https://bugs.eclipse.org/bugs/show_bug.cgi?id=279360
First off, my apologies for missing the meeting. I wanted to attend to discuss this, but my calendar is all screwed up post vacation and I missed it. So here are my comments for the record... The Java EE Module Dependencies page and interactions around it consistently get flagged as the least usable and most confusing part WTP in feedback that we get from our users. The comments focus on specific issues, but I think the fundamental issues is that this page is trying to do too much and too little at the same time. What I think would be really useful is to take a brief step back and catalog the functions that we need at the high level. I believe that it all ultimately reduces to this set: 1. Manage project's classpath. 2. Manage how resources, build artifacts, etc. are assembled into a module. The current UI tries to mash these two together. The result is both confusing and not flexible enough in either of these areas. The work that Rob Frost has done to implement classpath entry tags a few releases back was an important first step in giving back classpath management to JDT, but more work still needs to be done to rationalize the Java EE Module Dependencies page. I propose that we consider removing most of classpath management from Java EE Module Dependencies page and re-purpose this page to be a pure assembly specification. We can call it "Module Assembly" or even just "Assembly". If you think about it, the assembly UI can be remarkably simple and yet give a ton of flexibility to the user. We just need a two-column table with first column showing item's system path (or other identifier, if it is a project or a classpath entry) and the second column showing where to put that item in the assembled module. You then have buttons for adding and removing entries. Maybe buttons for re-arranging entries as well if shadowing is important. Same assembly UI for all modules. No need for two tabs for web, ejb, etc. Since all assembly items (including content directories, classes directories, etc) are shown in this table and can be manipulated, this would also solve a bunch of other enhancement requests where people have requested UI for controlling these items. No items should be locked down. They can all be removed. In terms of adding items, here is what I think we need: 1. Add files and folders. This covers a bunch of items under it, but the main thing to note that this is "resources" not "JARs" or anything else that might have classpath implications. The user should be able to map in new directories (workspace or external), new files (workspaces or external) and be able to use variables when specifying these paths. Ideally this doesn't end up as half a dozen buttons as this ends up confusing users as well. Two-level popup dialogs are also less than ideal. Perhaps we can try a multi-page wizard here instead? 2. Add project. 3. Add classpath entries. This would only be available for Java EE modules (with exception of EAR). This operation should open a wizard that first asks the user to either select an existing entry or add a new entry. If the user chooses to add a new entry, they would move to the next page in the wizard where we would ideally leverage JDT UI to let them add new entries. In either case, once the wizard completes, the classpath entries are tagged. The tagged entries will be visible in the assembly table along with everything else. I believe we should be able to do everything of the above purely in the UI without affecting the model and creating backwards compatibility issues. Thoughts? Comments? Did I miss anything? I know that this a bigger change than what you guys have been discussing, but we have gone for years making small changes to this UI while acknowledging that major re-work is necessary. Perhaps it's time for that? I would, of course, be available to help with this if people are interested in such an undertaking.
This and more was very close to what were discussed on the call. Rob Stryker will be submitting a patch (or rather a separate plugin) which is the first rework of this. Still a lot to do. There will be a follow up call next week.
The current version of my adapted plugin (using none of the feedback from the call of course) is here: http://anonsvn.jboss.org/repos/jbosstools/trunk/as/plugins/org.jboss.ide.eclipse.as.wtp.override.ui which can be checked out via svn. A lot of it is still too complicated, even with me simplifying it and abstracting it out, but there've been a lot of good ideas on the call. One of the best ideas which will clean up the code tremendously is removing the "select all" and "deselect all" and only showing what is currently present, then simply adding a "remove". I'll work on this ASAP.
Linking as related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=276825
Related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280416 (incomplete component schema) Related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280411 (overly restrictive AddComponentToEnterpriseEarApplicationOp)
(In reply to comment #4) Thanks for the detailed comments! - As Rob and Max mentioned, we did cover many of the same items you mentioned, and agree much improvement can come from simplifying the current page, and separating the function provided. We did largely focus on the archive assembly around EAR's, but also understand this can be applied to all module types requiring assembly of many types of resources. I do agree with you that "classpath" management is best done via the JDT properties, that could be extended to include deployment mapping requirements including how the MANIFEST is generated. We need to make sure these requirements are done in addition of the changes we proposed last week, and can possibly be linked from this page or a separate tab possibly. Much more discussion is needed here, including creating many enhancements on JDT to "open" their API in these scenarios. I like your proposal of merging the EAR/WEB-lib tab's into one, and "Clearly" marking the location of the resulting resources(archives), and again - sending the required MANIFEST entries provided by the EAR to the classpath management tab. General Resource(file/folder) mapping is also a requirement that would benefit users, but we may want to stage this to a later milestone, but properly planning for this level of assembly. Fortunately, the existing "modulecore" model does support most of the function mentioned, and would largely be changes to the UI only, but more rigorous testing of these scenarios must be included in the plan.
(In reply to comment #9) Now that the classpath management is removed from this page, and "Add resources..." is in, I can't help but think it should be re-used in static web projects for javascript development. It's common that ajax developers create common projects for their javascript libraries that get referenced in static web projects. Today they can use JSDT to set up javascript includepath to correctly resolve js resources in other projects, but their deployment scenario is broken since a mechanism similar to the "Module Dependency" (or "Assembly") does not exist on static web projects. So, to be completely selfish from Ajax tooling's point of view, can I propose that this framework be refactored and pushed down to wst? Or would a brand-new (and separate) implementation in wst be a better option?
There is another issue that needs to be considered here - many servers support flexible definitions for module layout on disk, but almost all have some limitation compared to what we can support in WTP. When the module has a simple layout the server can run directly out of the workspace, but when the module layout becomes too complicated, the server adapter will need to copy the module somewhere else into a supported disk format. On very small modules with short publishing update times this may make minimal difference, but as modules grow this can make a huge impact on initial publishing performance, incremental publishing time and how quick the server refreshes after a change, and of course duplicate disk usage. We clearly don't want to push this in the user's face, but we can't ignore that a user could innocently make a change here that would have a huge impact on testing usability or publishing performance.
(In reply to comment #4) The current JavaEE Module Dependencies page works as manifest editor if you take out "Web Libaries" and EAR Java EE Module Dependencies from the picture. My suggestion is to a. Rename existing JavaEE Module Dependencies as Manifest editor ( minus Web Libaries and EAR Java EE.., for these two cases the code base is separate than the Java EE Module Dependencies ) b. Create a new "Assembly" or "Module Assembly" page which lets you manage resource mappings. This also includes functionality of existing Web Libaries and EAR JavaEE Module Dependencies. -
> Now that the classpath management is removed from this page, and "Add > resources..." is in, I can't help but think it should be re-used in static web > projects for javascript development. It's common that ajax developers create > common projects for their javascript libraries that get referenced in static > web projects. Today they can use JSDT to set up javascript includepath to > correctly resolve js resources in other projects, but their deployment scenario > is broken since a mechanism similar to the "Module Dependency" (or "Assembly") > does not exist on static web projects. > > So, to be completely selfish from Ajax tooling's point of view, can I propose > that this framework be refactored and pushed down to wst? Or would a brand-new > (and separate) implementation in wst be a better option? I agree completely. The component model is already in WST, but the UI was put in JST because it was doing all this classpath stuff. With classpath stuff off-loaded, I can see the benefit of making the assembly config UI be available for static web projects as well.
> There is another issue that needs to be considered here - many servers support > flexible definitions for module layout on disk, but almost all have some > limitation compared to what we can support in WTP. When the module has a simple > layout the server can run directly out of the workspace, but when the module > layout becomes too complicated, the server adapter will need to copy the module > somewhere else into a supported disk format. > > On very small modules with short publishing update times this may make minimal > difference, but as modules grow this can make a huge impact on initial > publishing performance, incremental publishing time and how quick the server > refreshes after a change, and of course duplicate disk usage. > > We clearly don't want to push this in the user's face, but we can't ignore that > a user could innocently make a change here that would have a huge impact on > testing usability or publishing performance. This is an important issue to sort out early on. Tim and I had a lively exchange about this on another bug. We do want to tread carefully here, I wouldn't want to make all these powerful features be harder to discover for the user on the chance that for some servers and in some cases they mean slower publish perf. I propose that we consider implementing a switch "basic vs. flexible" (or some other such wording). Flexible would be default out of the box. The default would be overridable in product customization properties. It would also be possible to set this on a per project basis with switch value persisted in project metadata. In the basic mode, the assembly UI would not be displayed and classpath tags will be disabled. Classpath management would happen by physically dropping jars into WEB-INF/lib or by editing the module's manifest in source. The manifest classpath seems a little beyond basic config, but maybe that's ok. This would need something that looks similar to the current j2ee module dependencies UI from dependent jar management perspective. Per Neeraj's Comment #12, I agree that renaming this page as Manifest Editor (or even better Manifest Classpath Editor) would be good. In the flexible mode, the bin directory is <pj.root>/bin, the assembly properties page is visible, classpaths tags are enabled and manifest classpath editor property page is not visible. The last part is important. With exception of backwards compatibility for old projects (which can be done under the covers without surfacing editing UI and the case where you want compatibility for certain types of in-place deployment (handled by the basic mode), the classpath tags are superior to the handling dependencies via manifest classpath directly. Having the two methods concurrently available (the situation we have right now) has been reported as a point of confusion by our product users.
One note on comment #14 - unfortunately the publishing issues are per server adapter/type, not per workspace, project, or product. Plus, each server could have a different level of support, so one might support multiple Java bin folders but only one resource root, another might support the opposite, etc. Since each project can be deployed to multiple servers too, it's hard to predict where the 'breaking' point is unless we want to bite off a full solution.
Tim: My experience is that most server adapters don't know or care about how many "bin" folders there are... they take what they are given from the Module Factory and the members() methods they provide. So while it is "per server" in some regard, the module factory for that project also decides what it wants to expose. In the end, when a server calls members() and gets some IModuleFile and IModuleFolder objects, sure, we can get the underlying file, but nowhere in teh API does it tell us whether this is a bin directory or not. Of course the server gets the last say... it could completely decline to access the members() method at all and instead simply access the project and do publishing in its own fashion. HOWEVER... if the server does honor the module factory API, the IModuleResource API, etc, then really a lot of the responsibility of what gets published lies with the module factory.
> One note on comment #14 - unfortunately the publishing issues are per server > adapter/type, not per workspace, project, or product. Plus, each server could > have a different level of support, so one might support multiple Java bin > folders but only one resource root, another might support the opposite, etc. > Since each project can be deployed to multiple servers too, it's hard to > predict where the 'breaking' point is unless we want to bite off a full > solution. I don't think we have any hope of addressing this problem if we try to itemize features. It will be hard for us to write the code to support that and it will be confusing for the user. I would argue that it is responsibility of the server adapter to detect the case where assembly definition is beyond its abilities to deploy in some optimized fashion and to switch into a slower but full-featured mode (like the default publisher). I would further argue that any server adapter that's not able to do that is non-conformant. So I don't think of basic vs. flexible as being directly driven by needs of the server adapters, but rather as a choice that a user can make on a per-project basis. Now, as you have said, that choice possibly has an implication on publish performance. It would be a job of the server adapter vendor to convey this to the users in the appropriate fashion, either via product-level defaults, documentations, targeted runtime listeners on the project, etc. Note that the user might still elect to choose flexible over basic and sacrifice publish performance in order to gain more flexibility in setting up the app. As to what basic actually means, I would imagine we would want to keep it pretty limited and basically follow the structure of how people used to develop web apps before they had good IDE support (everything laid out exactly like it will be at runtime).
> I don't think we have any hope of addressing this problem if we try to > itemize features. It will be hard for us to write the code to support > that and it will be confusing for the user. Absolutely agreed. > I would argue that it is responsibility of the server adapter [...] and to > switch into a slower but full-featured mode (like the default publisher). > I would further argue that any server adapter that's not able to do that > is non-conformant. Agreed, and AFAIK all do. I think we agree that some servers will publish/update/respond slower when the project flexibility passes a certain threshold, and this point could be different for each server type. It's too complex and confusing to try to completely map this support out or present it to the user, and using a workspace or even project level setting incorrectly assumes the user will only ever use one server. My point was that allowing the user to arbitrarily change their project and then never telling them why their IDE is slow is bad form. Personally I think it's even bad to wait until they try to publish since then the project is already changed, but I agree we don't want to invoke server adapter code here. So I'm open to options, but to put a stake in the ground for discussion how about: a) a label on this page that warns the user that more complex structures may lead to degraded publishing performance on some runtimes. (clearly needs to be worded differently) b) some minimal new API (similar to isSingleRoot()) to allow a server adapter to easily tell what general structure a project is in. This would allow them to quickly determine whether they can use "basic" run out of the workspace, or should warn the user, or can support it, etc. without walking through the entire project structure.
> a) a label on this page that warns the user that more complex structures may > lead to degraded publishing performance on some runtimes. (clearly needs to be > worded differently) I am not sure that a warning like this is a good idea. It both unnecessarily concerns users of runtimes that aren't impacted and doesn't really do much for those that are. I don't think we would be able to sufficiently explain possible limitations in a short message. There is also the question of other points in the UI where "complex" structures might be exposed (as in quick fixes for classpath tags). The nice thing about the basic mode switch is that we would document once in WTP what functionality constitutes basic vs. full modes. Then the server vendor just has to tell the user that perf is better in basic mode for their server and the user makes an election whether to sacrifice features for perf. If they elect to do that, they flip the switch and all parts of the system can act accordingly. I think this would be a very easy concept for users to grasp and this is much easier concept to implement than a threshold where any number of operations can cross an invisible line. The other thing that an explicity switch allows us to do is to suppress manifest classpath UI in the full mode as the users should be guided to using classpath tags instead of being confused by two alternate ways of managing classpath.
A switch at what level - per project setting, workspace preference, or something else? What's the scenario/behaviour of what you're describing for a new WTP user?
> A switch at what level - per project setting, workspace preference, or > something else? At least project-level. Workspace level might also be desirable. The default value would be full/flexible unless the default is overridden by product config. > What's the scenario/behaviour of what you're describing for a new WTP user? In base WTP, the default behavior is full/flexible. User can find the switch in project/workspace preferences if they know they want that behavior, but we wouldn't push the basic mode. In adopter products that rely on server adapters that perform better in the basic mode, the adopter product definition would set the default to basic and users would interract with system at that feature-level unless they explicitly change the setting to full/flexible. There is also a possibility for individual server adapter providers to register listeners that trigger on targeted runtime change events and ensure that the project is set to the basic mode if that's the recommended practice for that server.
> In adopter products that rely on server adapters that perform better in the > basic mode [...] It sounds like you're assuming that none of the server adapters in WTP work this way. FWIW several of them do, include the server adapters for our OOBE.
> It sounds like you're assuming that none of the server adapters in WTP work > this way. FWIW several of them do, include the server adapters for our OOBE. I am not assuming none, but I am going on the assumption that most server adapters (in WTP or in the wild) are capable of dealing with flexible structure just fine, which is a true statement as far as I know. This makes "flexible" the appropriate default for out of the box WTP distribution. When adopters ship products based on WTP, they would be able to change the default. The switch could also be set on a per-project basis either by the user or by listener code contributed by a server adapter. It sounds to me like we are covering all the cases here.
Regarding general mapping of files and folders, how does this differ from the base Eclipse ability to create a linked folder? One difference is that this proposal would do the mapping at deploy time, whereas the base Eclipse approach does the linking at development time. That aside, it seems like adding general mapping to this proposal duplicates what base Eclipse already provides. Does this general mapping proposal accomplish things that linked folders cannot?
> Regarding general mapping of files and folders, how does this differ from the > base Eclipse ability to create a linked folder? One difference is that this > proposal would do the mapping at deploy time, whereas the base Eclipse approach > does the linking at development time. That aside, it seems like adding general > mapping to this proposal duplicates what base Eclipse already provides. Does > this general mapping proposal accomplish things that linked folders cannot? Two parts to the answer: 1. Eclipse linked folders facility is exceptionally limited in what it can do. It is going to be much more powerful in Eclipse 4.0 due to work that's happening in e4, but until then it just not very capable. 2. The facilities serve two different functions. The platform one brings content into a project (source view). What we are talking about is instructions for how to put together the application at export/publish time. In some cases, it might work to conflate the two usecases in one, but in most situations they are quite distinct. For instance, if a user setup two web content directories for source organization purposes, they want to see two directories when browsing through the project in Project Explorer.
What's an example where you want the assembly at deploy time but not at development time?
> What's an example where you want the assembly at deploy time but not at > development time? It's the same reason why people create multiple java source directories. Some people like to structure their source so that it looks practically identical to the deployed app. Some people like to organize their source in variety of other ways that make sense to them. The bigger the app, the more likely that the dev will want to have a custom source layout to help with organization. By definition, this custom layout is meant to be accessed as it exists while editing source.
>>Regarding general mapping of files and folders, how does this differ from the base Eclipse ability to create a linked folder? This feature has been in module core for a long time and people have been able to make use of it by editing the component.xml file directly (or via appropriate APIs). There's just never been a UI to do it.
Linking bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=282512
Linking bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=282515 Summary: vc.setReferences(vc.getReferences()) can make huge changes to the component.xml file
Linking Bug 282830 which is a similar discussion but with more specifics as to the limitations in the core, as opposed to the UI. If you feel that bug is better served as merging with this one let me know.
Created attachment 142710 [details] New plugin to take over module assembly UI (zipped) This is the newest version of the suggested plugin. I;ve externalized strings, I;ve renamed packages, and I;ve struggled to limit the dependencies to be what should belong to modulecore. I put it in the org.eclipse.wst.common.component namespace for now, however there;s one caveat. There is still a requirement on the following plugin: org.eclipse.jst.j2ee This is due specifically to one class and one class only, ProjectReferenceWizardFragment. This is the class which attempts to convert java projects into module core projects, and this makes use of JavaProjectMigrationDataModelProvider and IJavaProjectMigrationDataModelProperties directly, however indirectly it also uses several several other classes. So basically this is the only sticking point right now. Other things to note is that there is also now a dependency on server.ui, however I believe it;d be possible to simply copy the relevant two or three classes if we deemed the dependency inappropriate.
*** Bug 278917 has been marked as a duplicate of this bug. ***
Created attachment 143083 [details] new patch split up Patch includes two plugin folders (jst.common.ui, wst.common.modulecore.ui) and a patch to jst.j2ee.ui The patch to jst.j2ee.ui is still in stub format but can be worked in until we decide what exactly needs to be done.
I have been playing with the latest patch - great job Rob! I think its ready to go for the Ear project case. Not so sure about the module case though... My concerns are... With the Ear case - the difference between the vanilla "Module assembly" and the Java EE page are small (adds to the application.xml) The differences that need to be done for EJB/Web are larger... (manipulating MANIFEST - selecting location of deployed path (web-inf/lib etc....) Also - we should add some text specifying this as "experimental"... I have seen the platform do this to warn potential users After this though... I REALLY want this in M1, so I will be pushing this today if possible
I have pushed the two plugins into CVS, and did some work adding property files, build properties, MANIFEST cleanup, various bug fixes, and renamed a couple packages to be consistent with the "internal" naming scheme. (Also added EXPERIMENTAL to the title of the prop page) Carl will be investigating adding to build
Created attachment 146711 [details] Remove the j2ee plugin dependency org.eclipse.wst.common.modulecore.ui cannot prereq a JST plugin. Instead of adding the Java facet to a project, just make it a FacetedProject.
Correct me if I'm wrong: are the following bugs related to this? Bug #107039 Bug #133359
both bugs *are* related. I was going to mark them as related 2 days ago when I discovered them, but I got distracted.
Um... not quite sure what tag to use to close this bug, but I guess I'll resolve it as 'fixed'. Now that the substantial issues have been worked out and this has been in trunk for a while, any other problems should be opened separately as bugs or enhancements.
(In reply to comment #40) > Um... not quite sure what tag to use to close this bug, but I guess I'll > resolve it as 'fixed'. So do Bug #107039 and Bug #133359 in some way benefit from this fix? Is actually Bug #133359 Comment #7 about this?
(In reply to comment #41) > > So do Bug #107039 and Bug #133359 in some way benefit from this fix? Is > actually Bug #133359 Comment #7 about this? Mauro, yes, those bugs benefit from this work. (And yes, I was referring to this work in that comment.)
(In reply to comment #42) > Mauro, yes, those bugs benefit from this work. (And yes, I was referring to > this work in that comment.) Hi Carl! I just placed comments for those bugs: I think Bug #133359 is completely covered, while for Bug #107039 I provided a more deep anaylisis. However, I don't know if this is the right place to ask for what I think is a problem in the new Deployment Assembly page. When I select "Add Reference", then I choose "Project Reference" and then I select a project in my workspace, while checking "Web Library Reference", that project is added in the "Deployment Assembly" table, with deploy path /WEB-INF/lib/ProjectName.JAR (or ProjectName.WAR if the project is a Dynamic Web Project). However, if I do the exact same thing but WITHOUT selecting "Web Library Reference", a new row is inserted in the "Derived References" table instead. So, my first question is: what is "Derived references" all about? Anyway: when I hit "OK" (with or without clicking on "Apply" before) and then I re-open the properties dialog, rows in the "Deployment Assembly" table are preserved, while those in the "Derived References" are always cleared out. In other words, it seems that the settings made to the second table are not saved. Am I missing something?
*** Bug 133359 has been marked as a duplicate of this bug. ***
(In reply to comment #43) > However, if I do the > exact same thing but WITHOUT selecting "Web Library Reference", a new row is > inserted in the "Derived References" table instead. So, my first question is: > what is "Derived references" all about? Anyway: when I hit "OK" (with or > without clicking on "Apply" before) and then I re-open the properties dialog, > rows in the "Deployment Assembly" table are preserved, while those in the > "Derived References" are always cleared out. In other words, it seems that the > settings made to the second table are not saved. Am I missing something? You are not ;) The initial implementation of the "derived references" section is incomplete and will be refactored for m7. See Bug 305971 and Bug 306174 I will be working to fix these this week =]
(In reply to comment #45) > You are not ;) The initial implementation of the "derived references" section > is incomplete and will be refactored for m7. > > See Bug 305971 and Bug 306174 Thank you Rob! However, I still can't fully understand what "derived references" are about. Maybe because I'm not experienced with EJB (I usually work with plain Tomcat)... Could you at least point me in the right direction to learn about this topic? Thanks in advance. Mauro.
I hope this is the correct place to comment on the changes to the J2EE classpath interface that made it live in Helios. If not, I'd appreciate pointing to a more appropriate venue. First off, I think a whole load of documentation needs updating. For example, http://wiki.eclipse.org/ClasspathEntriesPublishExportSupport refers to a properties page that no longer exists. Secondly, am I the only one who finds this entire UI confusing? Why do I need to add a dependency to a library in two entirely different places? Why can't there simply be a checkbox on the build path dialog that says "deploy with J2EE applications" or similar (or, at worst, an extra tab there, similar to the current "order/export" tab). Yes, I understand this provides no way of deploying anything that isn't in the build path, but I imagine most people consider that an advanced option for which people will readily accept the UI being tucked away somewhere obscure; deploying libraries that are actively used in the project's code is a common requirement and should be easy to do. Third, there should be an easier way of getting to the appropriate UI than project context menu -> Properties, then select the correct page from the very long list. Perhaps there should be an entry in the "Java EE Tools" submenu?
