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.
The size is 9MB, as it includes the toplink.essentials library (twice!). Instead of bundling the library, could the sample depend on a *known* existing module, as outlined here by Jesse? https://netbeans.org/bugzilla/show_bug.cgi?id=178735#c2 Next, toplink.essentials is not the best library to choose - it's quite dated. It would be better to use the newer EclipseLink library (j2ee.eclipselink module).
1) No, the libraries are there only once in application zip, the second copy is a result of building on client's side, thus only this (2nd) copy is part of running application. Clean target deletes it again. 2) TopLink has to be here as a standalone project because depends on derbyclient in runtime in this sample. No way to find an another generic solution. 3) TopLink vs. EclipseLink, it was my random choice. I can change it later if needed - it should be tracked as independent issue. I'll file it.
> 1) No, the libraries are there only once in application zip Well, I am talking about the samples module itself, i.e. org-netbeans-modules-apisupport-crudsample.jar. It contains: org/netbeans/modules/apisupport/crudsample/external/* org/netbeans/modules/apisupport/crudsample/external/SampleCRUDAppProject.zip!/external/* > 2) TopLink has to be here as a standalone project because depends on > derbyclient in runtime in this sample. Why should TopLink depend on derbyclient? Isn't it enough if the suite as such depends on derbyclient? > 3) TopLink vs. EclipseLink...should be tracked as independent issue. I see you filed enhancement 180333.
>> 2) TopLink has to be here as a standalone project because depends on >> derbyclient in runtime in this sample. > > Why should TopLink depend on derbyclient? Isn't it enough if the suite as such > depends on derbyclient? No, it isn't enough. It caused issue 180059. The only way which I found to separate TopLink Wrapper and add particularly dependency on derbyclient. Stop by my desk and we can look on it together.
Looking at bug 180059 and the code of the sample app, it sounds weird to me to execute a database query at the time of TopComponent initialization. Shouldn't a TopComponent be a very lightweight UI element that exists independently of the data it displays? A db query can be a time consuming operation - is it right to block TopComponent initialization by this? Shouldn't the TopComponent just display itself and show a "Fetching data..." message or similar? Also, if the connection fails, what will happen and how will the user be notified about this? To me it sounds a more robust approach would be to fetch the data *after* the component is opened.
Reopening. The two occurence of library JARs (one in external/ of the module and one inside sample zip in the module) cannot stay there.
core-main/rev/7bd9fa4f88c0
Integrated into 'main-golden', will be available in build *201003030200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7bd9fa4f88c0 User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #180324: CustomerDB CRUD sample is too big; #180333: Use EclipseLink instead of TopLink