Community
Participate
Working Groups
Currently all facets in group "modules" conflict with the same group. This proves roblematic when trying to create a new project type which inherits from two module-member facets. Below are the requirements for our specific use case. Hopefully we can abstract them out to be more useful in a wider domain. Requirements: - Be able to create a project that has both the jst.ejb and jst.web facets. - programatically only is acceptable (possible "override conflicts" api?) - Retain ability to open ArtifactEdit objects to write to / modify descriptors of all module facet types enabled in the project - Be recognized by facets which require any member facet. (JSF would require jst.web. JSF must recognize my custom project as one that has the jst.web facet) NOT REQUIREMENTS: - There will be no need for separate builder lists within this project. One project-wide builder list will be fine. - There will be no need for automatic packaging / packaging structure to be maintained for this project type. Since it is a custom type, it will be no surprise when server adapters do not know how to package it. (Or even support it at all, actually)
Well, if you put the requirements this way, this is identical to the multiple modules per project approach tried and abandoned back in 0.7 days. I doubt you will be able to convince anyone to try that again. While on the surface, you might think that the only problem is that the module facets are declared to conflict with each other, in reality that check is there to prevent a whole host of problems that happens when you try to mix multiple modules in a project.
It seemed that most of the problems reported (from what I've heard) back in 0.7 was that you were trying to keep separate lists of builders for separate parts of the same projects, perhaps on a per-package level. This, I said, would not be necessary. Keeping accurate parent / child structure, also, would not be required. I suppose I fail to see which of my requirements is so troublesome. If I re-implement the ejb facet as some other facet name, perhaps test.ejb, and make it not a member of modules, I can easily create a dynamic web project with the test.ejb facet enabled. Then I can use artifactEdit models to edit both web-specific dd's as well as ejb-specific dd's, AND the project is recognized as a jst.web project so JSF functioanlity will work. If this is the route I must take, then that's fine, because honestly I feel the ejb facet / module type really didn't provide much utility as far as I was concerned anyway, at least nothing that'd be terrible to re-implement.
Actually, classpath was the biggest problem. In fact, it turns out that most everything you configure at the project level you want to be able to configure at module level. We even considered having facets be installable into a module so that you can have separate facets for different modules. That was right before we abandoned the approach because what we were doing is re-inventing the project at WTP level and calling it a module. In any case, it sounds like the solution of not using the jst.ejb facet would work for your specific scenario, so I can think we can close this bugzilla entry.
Kosta: Maybe everything *you* want to configure at the project level, *you* want to configure at the module level. This doesn't mean the users are just like you. I find your assumption that all users subscribe to the same use-cases silly, and I still think the answer should be to *allow* such behavior but not *support* it directly. Many many users prefer flexibility to do what they want over neat little packages that work nicely but are restrictive to all hell. The obvious answer is to provide neat little packages, but then allow for such things as one faceted project with one builder list, one classpath, one everything (making no accomodations for your assumption people want to customize on the module level)., but happening to contain multiple modules.
I still find your resistance to this ridiculous. I'm not asking you to re-invent the project on the wtp level. I'm not asking you to create different builder lists. I'm not asking for different classpath lists. I'm not asking for anything like that. If I wanted separate builder lists, I'd obviously use separate projects. If I wanted separate classpath lists, I'd obviously use separate projects. Your attempt (pre switch 0.7) to allow these things is what I call "over-engineering". I'm not asking for an over-engineered solution. I'm not asking for 900 contingency plans in case the user wants to do x or y. I'm asking for the ability to force one project to accept multiple modules because there are useful things that each project has and there is NO reason to stop people from using them. Example: Make a project with both ejb and web. Enable the webdoclet builder / facet AND the ejbdoclet builder / facets. There's no conflict here. There's one builder list. There's one large classpath. The odds of the ejbdoclet builder generating code for the web-related classes is minimal. The odds of the webdoclet builder generating code for the ejb-related classes is also minimal. One builder list. One classpath. Multiple modules. You have yet to clearly define the problem with doing this.
I think it would be better to focus on the real requirement at hand, which I believe was the ability to JBoss SEAM projects. The concept of seam is to do JSF/EJB3/JPA etc seamlessly and with minimal effort. This concept primarily targets ease of development so it is natural for JBoss to want to simplify the environment in a single project. I do not believe the use of facets and modules would be a limiting factor to implement this. And if they are we have a requirement to work on. My view of this is "SEAM" is a facet type. It should be possible to define a new Module type in WTP which has the fixed SEAM facet. Since it is a new module (even if it is not described by JEE like Web/EJB/Ear etc), WTP should not restrict adopters from describing and adding such modules. It would be upto the adopter to implement behavior that translates this module into JEE counterparts for publishing to runtimes.
So let say we added a Seam facet/module and not added any of the standard modules to the project - how do we make sure that the current/existing tooling for e.g. web.xml, faces-config.xml, etc. works ? without the standard module/facets activated they ceases to exist or am I missing something ?
Closing as part of mass query to clean up old resolved bugs in untargetted milestones.
