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.
Using new userdir, the first time i create a persistence unit in a Maven project takes a very long time, ie 10 minutes, but there is no indication that something is happening, and it is not possible to cancel or close the persistence unit wizard. 1. Create Maven Project > Maven Quickstart Archetype 2. Right-click project node and choose New > Persistence > Persistence Unit 3. Select sample DB Connection in wizard. Eventually the IDE created it. Subsequently, the PU wizard behaved normally
the situation only occurs if no other maven repository-related action has taken place and the repository indexing is either running on background or is triggered by this action. This will typically happen for testers only. There isn't any nice solution to the problem. We either recognize a running indexing/missing index and skip the step (eventually ending up with wrong dependencies) or we ignore the bug or we automatically start indexing on ide first start. I'm slightly inclined towards the first 2 options, the last one smells like war with the perf team.
*** Issue 173601 has been marked as a duplicate of this issue. ***
Created attachment 88925 [details] patch of Persistence unit wizard
I attached the patch which fixes this issue on the side of persistence unit wizard, thanks mkleint for pointer. The patch changes wizard to instantiate its result outside of EQ thread and also shows progress bar so that user is properly notified. Justification of progress bar - for ant projects, creation of PU can take several seconds also, so progress is useful here as well. For maven projects, 99% of usages takes comparable time as ant projects, but remaining 1% (edge case mentioned above) can take several minutes or even half an hour, depending on inet connection speed - that's why progress is crucial here, moreover user can see downloading of maven repository index in global progress area. Please consider integration of my patch into PU module, as it's important for maven support, thanks.
not sure it's time to have ui changes in 6.8
I think we still didn't reach UI freeze...(but I'm not 100% sure either)
ok, one more point, it's good to fix all cases of pu creation: with new persistence unit wizard, with entity classes from database wizard, with new session bean from entities and new jsf for entities wizards.
Tried suggested patch except monor chang(show "loading" only if library is added and use more general "Processing libraries" instead of "Loading libraries" but it can be changed also). What I see - It's better to show something but it still take a lot of time, so not sure it's perfect solution. also it takes about 10 minutes to download 5Mb eclipselink libraries(if it really download these libraries) already bundled with nb (should take about 30 seconds on my connection), 99% percent of users will never see the problem if maven will be able to use bundled libraries, it may be a better way (if it's possible). There are number of similar issues in different places, part fix may have no sense,for example, create pu, then in pu editor, add new pu with add button but select toplink, see effect. I'm not sure yet if it's more maven or more persistence support issue.
just for reference, in use-case above I got no dialogs and there was progress bar with "loading toplink.." but it stops on 35% and I got entire system freeze forabout 5 minutes (not just nb freeze).
sergeyp: have you integrated the patch or not? re: "also it takes about 10 minutes to download 5Mb eclipselink libraries(if it really download these libraries) already bundled with nb (should take about 30 seconds on my connection), 99% percent of users will never see the problem if maven will be able to use bundled libraries, it may be a better way (if it's possible)." it's downloading the maven repository index from which we try to guess the maven dependency coordinates. So it's downloading like 40 meg from 3+ servers, then unzipping the indexes and then searching for the eclipselink coordinates based on the SHA1 checksum of the binary. The bundled libraries are useless if not accompanied with maven pom/coordinate information and without an equivalent binary in maven repository. if you know such coordinates you can encode them in the library's maven-pom volume. Then you would bypass the repository index step. However users can change the PU binaries, can have different bit etc.. so the repo index step is generally useful. if your entire system freezes, it's useful to create a thread dump if possible. Anyway I don't see a reason why the indexing should freeze the system. it's downloading stuff and unzipping stuff.. fairly common..
So guys what is the conclusion? I'm a bit confused. On Maven side, we simply have to download indexes. Bundling indexes with NB was refused by upper body AFAIK and has its own issues as well. And we can't download at startup because of performance. So what remains is downloading on demand, which is exactly what we do now on Maven side. I don't see what we could do more... to sergeyp: I still think that my patch would more or less fix this issue. User will see this 10 min process only for the very first time and in edge case. Can very first PU be created without using the wizard? If no, then submitted patch is enough IMO. I tried adding next PUs and didn't see any problem when maven repository indexes were already downloaded. So what's wrong?
From my side, I can integrate suggested patch today/tomorrow. I just want to notice it's not complete fix. As I said pu can be created from different places and also after first pu creation user may choose to create pu with different provider and it may cause long downloading again. have you tried another provider? Regarding system freeze may be it's my local problem, may be antivirus scanning for index etc I can try later again. Another places for first pu creation are entity classes from db wizard, session bean from entity wizard, jpa controller from entity wizard, jsf pages from entity wizard.
http://hg.netbeans.org/web-main/rev/8a8cac05b497
I agree with Sergey that fixing only one of the places where this problem happens is pointless. If we decide to go with ProgressInstantiatingIterator then we should use it in all place which I do not like either - implementation detail from one area of IDE should not be "leaking" in other areas. It makes sense to me to start indexing on background after first Maven "thing" was used/created/opened. I mean if user opened a Maven project they are basically saying they are going to use Maven and so we should start on background any necessary indexing. That's basically what Java indexing does, no? So following that precedence it should be justifying to performance team. Another option (I'm not sure how doable) would be for Maven itself to show modal blocking progress dialog while index is being created (I mean in case when accessed too early by some 3rd party code). That way *all* UI cases would be covered with appropriate UI without polluting independent IDE areas like PU wizard. The idea may sounds awful but if only 1% of users is impacted as you are saying then I would say the solution is acceptable.
starting at project create/open will not help entirely and we still face an AWT freeze. Given that the repository scanning takes up to 20 minutes (depending on local network and central repository workload). punishing everyone by a modal dialog is not acceptable. Especially when this issue only affects a crude minority of users. I'd rather have a few users with frozen IDE than all with unusable IDE. And yes, you should fix in all places, I've done some in the past, dafe did this one but we cannot do everything as we don't know what everything is, at the very least.. As I mentioned earlier, another fix on your side is to figure where the library jars are in any maven repository and use it in library definition. If we are to apply a crude hack to this problem I reiterate my suggestion that we just skip recognizing the jars by SHA1 and put dummy coordinates into the pom. QA will be happy that everything is fast and the few unlucky real users will have to rewrite the pom manually.
to sergeyp: thanks for patch integration to dkonecny: - can you provide a list of other places where we have similar problem? I'm not aware of any, thanks. - we could move index transferring and indexing to opening of Maven project, but as Milos said, it won't help much and in some cases, it may bite. Shortly said Indexes are not needed unless you start to modify the pom of the project. I remember users complaining that they just opened some foreign Maven projects, just to look at the sources and they were disgusted by index transfer. - modal blocking dialog...well that's a power! :-) No, seriously, I don't know how we could recognize the "case when accessed too early by some 3rd party code". I agree with Milos here, let's break it for the few unlucky real users then applying such hacks. Library jars locations you could see in pom.xml of sample project into which all three PU units were added: <repositories> <repository> <id>unknown-jars-temp-repo</id> <name>A temporary repository created by NetBeans for libraries and jars it could not identify. Please replace the dependencies in this repository with correct ones and delete this repository.</name> <url>file:${project.basedir}/lib</url> </repository> <repository> <url>http://download.java.net/maven/2</url> <id>hibernate-persistence</id> <layout>default</layout> <name>Repository for library Library[hibernate-persistence]</name> </repository> <repository> <url>http://download.java.net/maven/1</url> <id>toplink</id> <layout>legacy</layout> <name>Repository for library Library[toplink]</name> </repository> </repositories> <dependencies> <dependency> <groupId>unknown.binary</groupId> <artifactId>eclipselink-2.0.0</artifactId> <version>SNAPSHOT</version> </dependency> <dependency> <groupId>unknown.binary</groupId> <artifactId>eclipselink-javax.persistence-2.0</artifactId> <version>SNAPSHOT</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.2.5.ga</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>ejb3-persistence</artifactId> <version>1.0.1.GA</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-entitymanager</artifactId> <version>3.3.2.GA</version> </dependency> <dependency> <groupId>javax.sql</groupId> <artifactId>jdbc-stdext</artifactId> <version>2.0</version> </dependency> <dependency> <groupId>javax.transaction</groupId> <artifactId>jta</artifactId> <version>1.0.1B</version> </dependency> <dependency> <groupId>toplink.essentials</groupId> <artifactId>toplink-essentials-agent</artifactId> <version>2.0-36</version> </dependency> <dependency> <groupId>toplink.essentials</groupId> <artifactId>toplink-essentials</artifactId> <version>2.0-36</version> </dependency> </dependencies> As you can see, EclipseLink was not found in any common repository, which means that lib will be copied into project directly, which is not correct in Maven philosophy. So for EclipseLink, it would be really good to add its Maven coordinates into library definition. See http://wiki.eclipse.org/EclipseLink/Maven for coordinates and http://www.netbeans.org/issues/show_bug.cgi?id=170990 as howto.
Just FYI, I filed EclipseLink problem as new issue 174714. As sergeyp integrated my original patch, root of this issue is fixed (IDE not freezing anymore, shows progress). Can I close as fixed? I'm waiting for your opinions as topic seems to be controversial and there is probably some discussion left before closing.
Integrated into 'main-golden', will be available in build *200910160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8a8cac05b497 User: sergeyp@netbeans.org Log: fix #172930 - added progress bar to pu creation wizard, mostlyt useful in projects where addition of new libraries may take a lot of time (maven).
I don't have anything to add. If it is *only a few users* impacted then I would go for a hack (that is for example Milos' suggest). It seems to me better then spreading code (ie. progress wizard) which in reality is rarely needed. Btw. Sergey already enumerated some other places where PU can be created.
re to dkonecny: "Btw. Sergey already enumerated some other places where PU can be created." Yes, but these other places don't suffer from our problem AFAIK. Problem appears only for the very first creation of PU, not for successive ones. And AFAIK "New PU" is the only way how to create very first PU, am I right? So no polluting...and moreover, wizard that creates and saves files should never do that in EQ thread anyway and run its instantiate(...) asynchronously, so I'm convinced this was right change. info for kganfield: If 174714 will get fixed, "New PU" wizard will go smoothly when EclipseLink is chosen. As a fallback, you can recommend repo index initialization step for users that didn't use Maven before and/or have empty userdir. Initialization is easy: just open Maven repository browser window and press "Update indexes" icon and go for lunch/coffee :-)
see above "Another places for first pu creation are entity classes from db wizard, session bean from entity wizard, jpa controller from entity wizard, jsf pages from entity wizard."
re the above comment. initial pu creation is not limited to the dedicated new pu wizard, but can happen when using the other wizards [eg new entity class from db] but they should just be opening the same new pu wizard, just from within another wizard. the time required for pu creation should also be tested when other persistence providers are chosen, eg hibernate
I see. Thanks for explanation, I'm not familiar with Nb EE support, sorry. Now I understand your comments better. But if you EE guys don't want to "pollute" your wizards with asynchronous creation with progress bar or don't want to add maven volume to library definitions, than I'm out of ideas. I am against mkleint's suggested hack, I can't *knowingly* corrupt maven project for users, albeit a few ones, don't ask me for that. So I guess I would close as wontfix?
dsimonek can you help with "add maven volume to library definitions"?
Yes I replied there a minute ago...
Guys, At Maven meeting, we decided to split the issue to reach desired state. Desired state is that mentioned wizards will go fast in general, while progress bar will be shown in some edge cases where we have no other choice but download/index Maven repos. To reach this state, we need: - Add Maven volume to all bundled Persistence Providers (I created separate issue http://www.netbeans.org/issues/show_bug.cgi?id=175682 for that) - Change this issue summary to "PU creation wizard should not freeze IDE, but show progress" and verify that all paths to PU creation show progress bar correctly - then this issue can be marked as fixed.
I checked that all known paths to creating PU shows progress instead of froze the IDE. Well currently you'll see no progress either, because with all supported persistence providers wizard will go fast thanks to 175682 completed. However, for custom persistence providers, progress will be shown as desired, so finally closing as completely fixed.