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.
This is possibly by design, but I can't update the libraries in a library wrapper module project. I currently have a library, which has dependent libraries. I'd like to add an additional jar to the base library. As it stands, I need to delete the library project and re-create it.
There is no GUI for it; none planned. You can use the Files tab to upgrade libraries. Name changes (or JAR additions) will also require minor changes in project.properties and project.xml. BTW it is generally a poor decision to add JARs to the project just because it has dependencies. Make separate lib wrapper modules for the deps and add them as module deps in the Libraries panel of the main wrapper module.
OK, but I'd like for you to consider this again, here's the use case: Take, for example, the eBay SDK, which is comprised of 5 jar files. I really just want one library wrapper module to represent the eBay SDK, however, to keep my distribution as small as possible, I only select 2 of the jar files that I need for my application. As I get into development, I realize I need another one of the eBay SDK jar files, so it would be nice just to be able to add it. My current work around is to delete the library wrapper module and create it again. To look at a more extreme example, look at Apache Axis, which is comprised of 29 jar files. /Brian
Jesse, creating a library wrapper module for each jar separately and making them dependencies is very likely to break over time. from my experience with shiping maven: i've factored out commons-logging as it's already used in the IDE and it's not a being developed anymore and is stable. then I pack ant jars together, but could not reuse the netbeans ones, because maven 1.0 works just with ant 1.5.3. The rest of maven libraries I just put in one bulk (cca 10+ jars) splitting into individual libraries is fine when you have everything under your control. like when you have an inhouse platform based app. But mostly you don't. And it's very likely that someone else will figure that the correct codenamebase for commons-http is org.apache.commons.http just like you did. BUT 2.x are not compatible with 3.x. (which seems to be the rule for a lot of libraries, hell jdom was incompatible between 1.0-beta9 and 1.0-beta10.) So it can easily happen that after installing a 3rd party plugin, everything breaks on your side because of unwanted upgrades of libraries. IMHO the only real protection there is to pack in relatively big chunks and to come up with creative codenamebase entries for your modules.
You can encode version numbers in code name bases to handle incompatible changes in libs. Anyway, keep it on the mailing list please.
i just ran into this one yesterday. as i understand it, and i could be wrong, one has to basically rebuild a library module from scratch whenever one wishes to add/remove a jar constituent. if the assertion is correct, this feels rather non-intuitive to practical day-to-day lib mod construction activities.
Reopening - sorry, I can't think of reason 1 why we should not fix this. It's perfectly doable from the implementation side (just add/remove entries from project.xml and adjust public-packages). And there is a perfectly legitimate use-case - where you're packaging some project that, on its own, consists of a huge number of jars, and that set of jars changes over time. There's no reason to make handling that situation excruciating for people, and Milos is right that the multiple-version problem is a real one.
Still do not agree with the approach of dumping unrelated JARs into one big wrapper. We may however want in the future to have the setup wizard prompt you to suffix the code name base with a version identifier, according to compatibility expectations, since in the pre-JSR-277 world there is no way the IDE can know whether a given portion of a JAR version number refers to a big API change or to a mere patch. Anyway, that is not very relevant here, since if you just want to upgrade foo-1.0.jar to a fully compatible foo-1.1.jar you need to rename the JAR file (unless you are willing to bundle it as foo.jar), and generalizing that to adding/removing other JARs doesn't make it much harder to deal with. Certainly possible but not trivial to make a GUI for this. Needs to - add, remove, and/or modify release/modules/ext/*.jar files according to user instructions - modify project.xml <class-path-extension> sections according to additions or removals of JARs - update list of public packages, by removing any now-missing packages, and perhaps prompting about newly available packages Would require either a new wizard, or a new panel in project properties (possibly displayed only if there are already <class-path-extension>s), with buttons to Add, Remove, and Update, and some confirmation dialogs. Needs to handle a variety of special cases, such as existing extensions in unexpected places (not release/modules/ext/) or with <binary-origin>s. Probably a week's work for somebody, given a UI spec, and then a bunch of QA to iron the bugs out. That is why we did not try it for 5.0. The file formats are documented in harness/README and you can make whatever changes you like by hand for now.
*** Issue 72186 has been marked as a duplicate of this issue. ***
Yes, I agree this would make things much easier. I have also been thinking as Jesse wrote about the need for the IDE to append or prepend a version number to a library or modules code name base. I have been doing this by hand for things. Anyways, would make development that much faster for those wanting to use it as a feature. Not everyone will be creating modules to use as plug-ins to the IDE or other applications, but they will use different methods for creating different types of applications at varying levels of complexity. If the application is real simple and only has a module then this makes pretty good sense as they just want to create it fast and quick and yet get the benefits of the platform.
Technically it doesn't even have to support dumping these things into one wrapper module or module. The UI and project infrastructure could provide a path to make it easy to add many jars very fast and wrap them all. It could even provide a path for the user to select multiple J2SE projects at one time and then generate library wrapper modules and make these as separate projects which will build their dependent dependencies...just as a J2SE project would build it's dependent J2SE projects. Then a library wrapper could be built, and if the jar is already built and the sources are up to date and compiled then it would not be built again when the wrapper is built...just like the J2SE project builds work. Thus, getting around all best practice issues yet support more RAD in the IDE by allowing the developers to work more quickly. I think the need to work faster is the reason we see talk of this often. I just commented on a thread on dev@openide about this a few minutes ago.
*** Issue 150582 has been marked as a duplicate of this issue. ***
*** Issue 161423 has been marked as a duplicate of this issue. ***
Done, UI is placed in Properties -> Libraries, which is modelled after UI in J2SE projects as follows: 1) Module Dependencies and Required Tokens are put on separate tabs, new tab Wrapped JARs is added: _____________________ _________________ ______________ / Module Dependencies \/ Required Tokens \/ Wrapped JARs \_____ | ... | 2) Wrapped JARs tab contains list of <class-path-extension>-s and couple of buttons to manipulate them: +-----------------------------------------------+ | Wrapped JAR Files: | | +-------------------------------+ +---------+ | | | release/modules/ext/Lib1.jar | | Add JAR | | | | release/modules/ext/Lib2.jar | +---------+ | | | | +---------+ | | | | | Edit | | | | | +---------+ | | | | +---------+ | | | | | Remove | | | | | +---------+ | | | | +---------+ | | | | | Export | | | | | +---------+ | | +-------------------------------+ | +-----------------------------------------------+ * Add JAR: lets user browse for JAR file and *copies* it to release/modules/ext dir in project root (unless the JAR already is in release/modules/ext). * Edit: lets user specify optional source and javadoc for the JAR, the same dialog as in J2SE projects is used. Note: source & javadoc queries in IDE (Show Javadoc, Go To Source, ...) don't work yet, tracked as separate issue #66275, which will be added shortly. * Remove: removes selected JARs from <class-path-extension>-s, also removes respective exported packages from project.xml. * Export: Exports all packages from selected JARs as public or friend packages in project.xml. Further customization can be performed on API Versioning tab. Anyone, feel free to comment on UI usability or file issues. core-main #14198c139d1b and core-main #8f221e9db4df
Integrated into 'main-golden', will be available in build *200908260201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/14198c139d1b User: Richard Michalsky <rmichalsky@netbeans.org> Log: #66188: partially working, doesn't handle public packages correctly yet
src & javadoc now working as well, see issue #66275.