Community
Participate
Working Groups
Created attachment 102388 [details] screenshot Ganymede RC2 Steps to reproduce: 1. Create a Java project. 2. Right-click on the Java project > Properties. 3. Go to the Project Facets property page. Only the Java facet is checked. 4. Check the Java Persistence facet. On step 4. an error message appears: "Constraints for Java Persistence 1.0 have not been met. ". When looking at the Details view instead of the constraints for the JPA facet, I see "Constraint too complex to display". The user is quite helpless in this situation. Adding Konstantin to CC in case he has comments on the issue. Screenshot is attached.
I'm confused by step 3, how do you have project facets for a Java project? The supported way for turning a Java project into a JPA project is to right click choose JPA Tools -> Convert to JPA Tools. Do you have something that is making all java projects faceted projects? The thing that is missing is the Utility Module facet, but obviously it isn't helping you very much to determine that
(In reply to comment #1) > I'm confused by step 3, how do you have project facets for a Java project? I thought this is a new feature :-) > The > supported way for turning a Java project into a JPA project is to right click > choose JPA Tools -> Convert to JPA Tools. Do you have something that is making > all java projects faceted projects? I remember there is such thing, but I couldn't find it in the context menu of the Java project. Neither in the Java EE perspective, nor in the JPA perspective > The thing that is missing is the Utility Module facet, but obviously it isn't > helping you very much to determine that I know that (even I wonder why is this dependency), but users may not.
There are two issues here: 1. Can the jpa facet constraints be simplified? Perhaps to just requiring the java facet. 2. Improving the faceted project UI so that it is capable of rendering complex constraints when they cannot be reduced to a list. At the time the existing UI was written, I was not aware of any real-world cases where this would come up. Please open a separate enhancement request to track that.
Once the project is a faceted project our menu item will not appear. Are you just using WTP RC2 and its dependencies, or do you have other plugins beyond that? I do not see this new "feature" and I am not thinking it is something WTP would want to do anyway. I would think the real goal here would be to get the facet framework pushed into the platform so that java projects can be faceted that way. I've tried hard to get myself into the situation you display in the screenshot, I have no idea how to get there. Paul is the one who could explain why we have to have the Utility facet. I am unsure why we have to display this (much less whether it is required at all). If you create a 'Dynamic Web project' you can look at the project facet options and 'Java Persistence' is an option, but 'Utility Module' is not. It seems like they are using the 'Utility Module' but just not displaying it as we are doing. Our facet works fine if you choose it in this use case. Any ideas Paul?
I believe that Kaloyan got into this situation by using the new generic "Faceted Project Wizard" that allows the user to construct a project from scratch.
(In reply to comment #4) > Once the project is a faceted project our menu item will not appear. Are you > just using WTP RC2 and its dependencies, or do you have other plugins beyond > that? I do not see this new "feature" and I am not thinking it is something > WTP would want to do anyway. I would think the real goal here would be to get > the facet framework pushed into the platform so that java projects can be > faceted that way. I've tried hard to get myself into the situation you display > in the screenshot, I have no idea how to get there. Wow, my mistake... partly... I use pure WTP RC2, but with old workspace. There I have some "pure" Java projects, but now I see that there are not so pure. They are web projects, but the web facet has mystically gone somewhere... The facets.xml descriptor is there, but only with the Java facet. I have tried creating new pure Java project and now the JPA Tools context menu is there.
Ah, thanks Konstantin, hadn't seen that option yet
(In reply to comment #5) > I believe that Kaloyan got into this situation by using the new generic > "Faceted Project Wizard" that allows the user to construct a project from > scratch. > Well, this is indeed a new feature I have not known about. Now, I can really created a faceted Java project :-)
I have entered bug 234674 against the facet framework and will leave this open so that we can investigate removing our dependency on the Utility Module.
*** Bug 242604 has been marked as a duplicate of this bug. ***
Setting to 2.1RC1 since it would be nice to do this in 2.1, only concern is the risk factor of putting this in a release candidate. If too risky, we can just set this to 2.2 instead.
retargeting to 2.2, after some more investigation this looks too risky. There is code in UtilityFacetInstallDelegate and UtilityFacetUninstallDelegate that I am unsure we want to duplicate in our own facets. removing of WTP natures being the biggest one. I have entered bug 254469 for a problem I found poking around in the New Faceted Project wizard. That wizard is much more helpful now in telling you what the prerequisite facets are.
Investigate for M7. This would be nice to do if the scope/risk of the change is manageable.
I really think this needs to be tackled earlier in a development cycle. The dependencies involved are way too hairy to be tackled as late as an M7. Suggest we assign this to M1 (so that we're sure to consider it at that point) of our next release.
OK, I agree. Put only if you promise you will work on this for M1 of the next release :-)
Yeah, we're trying to figure out how to target it to <next release> M1 without knowing what number it'll be. :)
Moving to Future bucket. Will target to next release when we figure out what the version number will be.
Investigate for M1. Lowered priority on this since the original issue has been resolved. This change could have some large implications on JPA project creation, so not committing to it yet.
I'm investigating to see what the problems are with the current requirement are and what the effects of removing that requirement would be. So far I've come up with the following: Undesired effects of requiring *a* module facet (does not have to be the utility module) for JPA projects destined for SE environments - Appearance of an EAR Libraries container. Obviously this does not apply to projects that aren't destined to be deployed with an EAR, and could lead to user confusion. But note that this exists also for web projects that aren't destined to be deployed with an EAR. This should probably be explored as a problem from the EE tools side of things. - Creation of a manifest file. I'm not sure that this is a problem at all, but possibly an annoyance. Things that would have to be addressed if we removed the requirement for a module facet - Installation of JavaEMFNature. This may not be a problem. I was able to remove this from the installation process and did not run across any problems. XML (EMF) files were created and loaded with no more problems than usual. But this *may* end up being a problem. - Installation of ModuleCoreNature. This is a much bigger problem. We use this framework for mapping deployment locations to source files, something that's necessary even in the SE case. We would need to be able to install/uninstall this nature and behave well with other facets that install/uninstall this nature. There are other functions of this nature, but this particular use is enough to require the entire nature, in my opinion. - Project wizard. Our current project wizard extends the utility project, which assumes module facet installation. This gives us runtime selection, convenient placement of common configurations, and the ability to add to an EAR. This is not that much of a problem (though I have not gotten into what trickiness the data models may present). But we would almost certainly need to have two different wizards, one for EE and one for SE. At this point I'd like to ask if there are further arguments for removing this dependency. With the improvements to the facets dependencies UI (and that is quite nice now), I'm not seeing the benefits vs. the trouble involved in removing it.
I would still suggest pursuing this. In the future it will be even easier for users to create faceted java projects and it would be really nice for the user to be able to install jpa without forcing the utility facet into the mix. The utility facet is somewhat random in contexts where it doesn't serve as project's defining characteristic as it doesn't bring much user-visible functionality. > - Installation of ModuleCoreNature. This is a much bigger problem. We use > this framework for mapping deployment locations to source files, something > that's necessary even in the SE case. I am curious. What are you looking for that isn't available with standard IJavaProject API? > - Project wizard. Our current project wizard extends the utility project, > which assumes module facet installation. This gives us runtime selection, > convenient placement of common configurations, and the ability to add to an > EAR. This is not that much of a problem (though I have not gotten into what > trickiness the data models may present). But we would almost certainly need > to have two different wizards, one for EE and one for SE. I am biased on this, obviously, but I would note that a bunch of focused wizards like that is at odds with some of the primary motivations for the faceted project framework. I would suggest that for the SE case, the project wizard is the Java Project wizard and JPA is an add-on. Now, of course, the project created by the standard Java Project wizard is not faceted. Maybe we need "Faceted Java Project". Of course, there is the generic faceted project wizard that users can utilize. In the future, it may also be easier to convert a non-faceted project to a faceted on. I guess my point here is that I wouldn't assume that it is required (or even desirable) to create an SE version of the JPA project wizard.
(In reply to comment #20) > I would still suggest pursuing this. In the future it will be even easier for > users to create faceted java projects and it would be really nice for the user > to be able to install jpa without forcing the utility facet into the mix. The > utility facet is somewhat random in contexts where it doesn't serve as > project's defining characteristic as it doesn't bring much user-visible > functionality. The thing that it does add, despite not showing much to the user, is deploy-ish behavior. Even though JPA has an SE aspect, it still retains a lot of EE behavior, including the idea of a container and dependence on deployment paths. > I am curious. What are you looking for that isn't available with standard > IJavaProject API? We use the virtual component system to help us determine source files for deployment paths. In persistence.xml, you specify a mapping file "foo/myorm.xml" by deployment path. Instead of attempting to calculate source folders and iterating in order to find the source file, we can simply determine the source file from the virtual file. Now that we don't use ArtifactEdits, this *seems* to be the only part of the ModuleCoreNature that we require. If there were a "virtual structure nature" that would probably be all we'd need. > I am biased on this, obviously, but I would note that a bunch of focused > wizards like that is at odds with some of the primary motivations for the > faceted project framework. I would suggest that for the SE case, the project > wizard is the Java Project wizard and JPA is an add-on. Now, of course, the > project created by the standard Java Project wizard is not faceted. Maybe we > need "Faceted Java Project". Of course, there is the generic faceted project > wizard that users can utilize. In the future, it may also be easier to convert > a non-faceted project to a faceted on. > > I guess my point here is that I wouldn't assume that it is required (or even > desirable) to create an SE version of the JPA project wizard. Assuming that it isn't desirable to put emphasis on the creation of a project with JPA functionality (which I wouldn't), I agree in principle.
>> I would still suggest pursuing this. In the future it will be even >> easier for users to create faceted java projects and it would be >> really nice for the user to be able to install jpa without forcing the >> utility facet into the mix. The utility facet is somewhat random in >> contexts where it doesn't serve as project's defining characteristic >> as it doesn't bring much user-visible functionality. > > The thing that it does add, despite not showing much to the user, is > deploy-ish behavior. Even though JPA has an SE aspect, it still retains > a lot of EE behavior, including the idea of a container and dependence on > deployment paths. Not arguing that it has behaviors under the covers. Just saying that from user's perspective, those are pretty invisible which makes for a poor justification in user's mind for why that facet should be installed. >> I am curious. What are you looking for that isn't available with standard >> IJavaProject API? > > We use the virtual component system to help us determine source files for > deployment paths. In persistence.xml, you specify a mapping file > "foo/myorm.xml" by deployment path. Instead of attempting to calculate source > folders and iterating in order to find the source file, we can simply determine > the source file from the virtual file. Now that we don't use ArtifactEdits, > this *seems* to be the only part of the ModuleCoreNature that we require. If > there were a "virtual structure nature" that would probably be all we'd need. Perhaps you can fall-back to checking java source directories using IJavaProject API if virtual component system is not installed. The virtual component system is a heavy-duty apparatus that is not particularly useful in the SE case.
This needs to be addressed in M1 of the next release as it is too big to deal with for Helios post M6. Upgrading priority to P2.
Just want to point out that there are at least two reasons people could be interested in this bug: * The implication (or reality) that Dali only works in the context of Java EE projects * Prereq being used b/c of a dependency on WTP's flexible project support Although both of these are worthy of resolving (Dali's cool - who wouldn't want to use it on a basic Java project?), fixing either one would start allowing Dali to be used in new contexts. As an example, I only noticed this issue because it wouldn't let me add the JPA facet to a non-JEE flexible project without adding 'Utility module' as well. Even though adding the utility facet was probably a 'technical no-op' in this case, the JEE module reference alone threw me off, and there might be a simpler solution than also changing the flexible project dependency.
Also I should point out that, although not much seems to have moved on this bug, we have had lots of conversations and thought poured in to how we'd do this. We *do* want to do this (and we do want to do this next release), but it's going to have to be part of a larger chunk of functionality involving how users develop in SE vs EE.
For anyone interested, I have opened bug 310378 with a request to have Dali switch over to the new facet grouping mechanism. This would in turn allow any project or adopter that works with Dali *and understands Dali's project requirements* to add a facet into the set that it supports. The existing set of facets is simply the set of project types that we know of in WTP level that satisfy Dali's requirements; no JEE dependence implied. This removes the first bullet from comment 24 above - if anyone has another project/facet that Dali can support, it could easily be added into the set. This bug can remain focussed on the core issue, which I beleive is the (harder to solve) dependence on flexible project API.
(In reply to comment #26) > For anyone interested, I have opened bug 310378 with a request to have Dali > switch over to the new facet grouping mechanism. This would in turn allow any > project or adopter that works with Dali *and understands Dali's project > requirements* to add a facet into the set that it supports. > > The existing set of facets is simply the set of project types that we know of > in WTP level that satisfy Dali's requirements; no JEE dependence implied. This > removes the first bullet from comment 24 above - if anyone has another > project/facet that Dali can support, it could easily be added into the set. > > This bug can remain focussed on the core issue, which I beleive is the (harder > to solve) dependence on flexible project API. Actually, the *real* solution to bullet one is to require *no* facet. We only require Java EE facets since those are the only ones that have the flexible project structure. But this would potentially allow extenders to implement other facets that add that requirement and make Dali code cleaner, hopefully just in time to be completely unnecessary by next release. :)
Agreed. I would look at it as hopefully unblocking knowledgable downstream projects or adopters who have flexible project structures this release (ok, maybe that's a small set of us, but non-zero :) ), and resolving the root problem later.
bug 317900 has been opened to track a solution that would enable this to happen
In M1 it's now possible to create a JPA project with only java and JPA facets. There are now two project wizards: JPA Project and JPA EE Project, the latter of which is the same functionality we've had before.
Great! Happy to see this enhancement. Just one question. Why do we need the JPA EE Project wizard at all? A JPA project with Utility facet makes sense if only referenced in Web or EAR project. But if you add a "non-Utility" project as a reference to Web or EAR, then the Utility facet is automatically added.
That's certainly something we could possibly remove. We kept it simply for "backwards usability" if that's such a thing? People are used to creating a utility faceted JPA project, so we thought it might be good to keep it around. Plus there's no other way to add it to an EAR directly at project creation. But again, we're certainly open to removing it if it really is superfluous.
Oh, if I understand correctly the "Add to EAR" section in the first wizard page is available only in the JPA EE Project wizard, and not in the new JPA Project wizard. Is this correct? I would say that a JPA Project wizard with "Add to EAR" section is quite important. Isn't it possible to have just one wizard and depending on the user choice (if this JPA project should be added to an EAR) the project is created with or without the Utility facet? My concern is that there is no such term as "JPA EE" and this will bring confusion to users. So does the existence of two JPA Project wizards which differs just in one technical detail.
+1 For having only one JPA project wizard. The "add to ear" is not an important enough consideration to warrant having two wizards or to confuse pojo jpa scenario with Java EE related UI. 1. You can easily add the jpa project from the EAR project's property page. The "add to ear" control on project creation is just a convenience short cut. Nice, but not essential. 2. Java EE users can always go through the utility project wizard and add jpa.
Konstantin, perhaps you are right. If I look at myself, most often I add JPA facet to Web and EJB projects. It is rare that I create a separate JPA project for Java EE scenario. But even in this case the Utility Project wizard will do the job. So, removing the JPA EE Project wizard should be just fine.
I tend to agree with Kaloyan's thoughts here. I think if there is a reasonable way to do the job with one wizard, that is probably a better outcome.
We are investigating changes here. Stay tuned.
Entered bug 323491 to address JPA EE wizard concerns.
