This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
From a discussion with Jano & Pavel: On 3 May 2006, at 20:44, Rochelle Raccah wrote: > Right now the warning about no PU in the Entity from DB wizard is: > There is no persistence unit in the project yet. You need a persistence unit to persist entity classes. > > My proposal is to add a sentence there: > If you do not create a persistence unit, you must manually add a persistence library to your project for compilation. Jano's response: We can do something like that. It would make the text rather long, which might cause users won't read it. And maybe we can specifically mention Toplink Essentials as they might not know be able to choose from the list of libraries the persistence one. If you do not create a persistence unit, you must manually add a persistence library (e.g. Toplink Essentials) to your project for compilation.
Just to get this right, should the warning be updated to: "There is no persistence unit in the project yet. You need a persistence unit to persist entity classes. If you do not create a persistence unit, you must manually add a persistence library (e.g. Toplink Essentials) to your project for compilation." ? That seems a bit long in my opinion too.
Lets look at this problem again and pretend we only have a basic warning in the wizard: "There is no persistence unit in the project yet. You need a persistence unit to persist entity classes." Possible scenarios the user can do in this wizard: 1. The user notices the warning and creates a PU. Everything works fine. 2. The user notices the warning and doesn't create a PU because he knows he doesn't need it in his module that only contains entity classes and no entity manager code. In this case I think this user is knowledgeable enough about persistence and he knows he has to fix the classpath. 3. The user notices the warning but doesn't create PU because he doesn't know what it is and whether he needs it. He most likely needs a PU because he's probably just playing with persistence yet. In this case the user needs to find out he needs to create PU anyway. The updated warning would not help him IMO. 4. The user doesn't notice the warning. In this case the updated warning would not help. Looking at this I feel like updating the warning doesn't really help a lot and maybe the updated warning also complicates things for those who need PU, which probably is the majority of users. I suggest to not update the warning for now and wait for user feedback.
How about a slightly different solution, then? How about incorporating this into the editor suggestions? There will be lots of red error annotations about not knowing javax.persistence. Maybe one of the suggestions with the lightbulb can be to add the persistence library.
I think that would be the right solution. We saw somewhat related problem in the usability study. See issue #74690 and issue #75426.
Reassigning to j2ee/editor since the latest proposal concerns that area.
There is editor warning and hint for creating PU already (when editing entity classes). It does not work if imports are not resolved, but I don't think we would expect it to do so. Closing the issue after consulting Petr Pisl. If you disagree please file a new issue explaining expected behavior in detail.
This was not yet solved and we saw that it was indeed a problem (even for Craig M). Reopening and assigning to Jano to figure out what should happen.
Okay, if we add the persistence library automatically to classpath (the API JAR), what would be the unwanted consequences and complications? I tend to say we should add it automatically, but I need to know what can break.
I don't think anything will break if it's added automatically. Pavel, what do you think? Even if implementation jars have the APIs in them as well, the APIs should be the same. We should keep this jar ahead of those in the classpath, though.
Okay, so lets try to do it, but somebody should check all the scenarios, to make sure it works. Namely when user creates entity class without PU and then does any of those: - creates another entity class without PU - adds a PU with Toplink - adds a PU with e.g. Hibernate Who should I reassign this issue to?
Hmm, maybe Martin ;-).
*** Issue 79863 has been marked as a duplicate of this issue. ***
*** Issue 80312 has been marked as a duplicate of this issue. ***
*** Issue 82871 has been marked as a duplicate of this issue. ***
I still do not see a clear conclusion. I do not like the solution with automatically adding persistence API and then toplink and hibernate as well. Having the classes on classpath twice is asking for trouble. What if toplink or hibernate makes JPA 1.1 (even a preview) available before we release next version of NB and users install it in NB? Then you will have different API classes on cp before the ones from runtime. I think we should use classes from runtime when using one. I would be OK with using just API classes if the user does not want any runtime (e.g. for a library project). That means adding JPA library if you choose not to create a PU. But: We would need to create a separate library for JPA. Then maybe some users would have problem understanding when to use JPA library vs TopLink library or both. I think this would be an acceptable solution. Personally, I still think it would not hurt too much if we just use the whole runtime (i.e. toplink, hibernate, etc.) library. There is an added benefit that the user will see additional APIs available in that runtime if that is what they want to choose (e.g. in Hibernate). We can just add it automatically when creating an entity if the user chooses not to create PU and if javax.persistence.* is not on classpath. Ideally we would ask the user to select one of the available runtimes (search the registered libraries for javax.pers.*) but if not (we do not want to change UI for 5.5, I assume) we can just add the first one that is in library manager or just add toplink which we bundle. Users can replace with another one if they want. That is a simple and cheap solution for 5.5.
Adding the whole Toplink JAR (API + runtime) looks good to me.
*** Issue 130858 has been marked as a duplicate of this issue. ***
A single duplicate filed by an user (not QE) in two years. Not a P3 I think.
low priority
NetBeans.org Migration: changing resolution from LATER to WONTFIX