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.
Sometimes user needs expand the features of the project. For example: user creates a java project and then she wants to add the javadoc nature for building javadoc. This thing is missing in the API.
Adding dependency on 34319. The user model must be clear first since the API design may be affected by the user model.
I think this issue should be P1, because if not available, it totally breaks the way how developers usually work on their projects.
The example specified java project needs to add javadoc nature could be resolved without adding the javadoc nature to a project. For example, a wizard creating a javadoc build target could be available in the java-nature (this could be registered by another module). One potential use case for projects is to keep a project small and focused on a single task. For example, creating a library jar. The output from a project could be incorporated into other projects. If an arbitrary nature is added into a project then the focus of a project may be lost. The ability to support this use case in conjunction with the potential to add arbitrary natures to projects should be provided.
Contributing to the nature provided by another module is possible, but not realy nice thing as it prevents from correct versioning. The versioning is based on detection of changes between natures used in the project and installed in IDE. IMO it can be used for simple modules which really add only one or two things like buildtarget, but modules providing more complex support should always use natures. I think this is the case of junit or javadoc modules. Also I don't think that we will loose the focus of projects. There still can be only the basic java project template which will not contain anythink else than java-nature stuff by default. But additionaly user can add support for e.g. junit testing when she really needs it.
I think in some cases adding natures to a project is fine, but I am not convinced this is true for all natures. My argument is based from an ease of development (both IDE developers and application developers). Consider the case of an EJB based project. If natures cannot be added all the java source and resources can reasonable assumed to be associated with the ejb-jar output. If other natures can be added in the future (say a web module nature could be added as well), then the following would need to occur in the simplified example: 1. Each build target would need to be able to determine which sources are approriate (some form of class closure) 2. adding a resource may require additional information for resource association.
Yes, you are right: developing projects stuff is harder when you have to deal with uncertainty caused by potential unknown objects added by foreign natures. This is the cost of extensibility. Since the extensibility is cool thing and IMO users will appreciate it I think we should support it by default. On the other hand there could be some official way how nature will say that it _must not_ be extended. Then it's completely up to you to decide whether you want to sacrify extensibility in favor of easier developement. In some situations this can be reasonable decision.
I agree.
I think that before you make the final decision about the rules for adding natures it would help a lot to have as many realistic examples as possible. I know that it is a hard homework but IMO it is worth it. For example, I think that adding a web nature into a project that already has an EJB nature is not very natural. On the other hand I have an example of when it makes sense to add another set of classes into a web module project that are not part of the web module itself. This is when you want to develop an applet that is used from the web module. You need to compile the applet classes into a different location then WEB-INF\classes, perhaps also with different settings. This could be solved by a nature 'applet-in-web-module'. Then the web module nature needs to be able to work even if there are multiple Compiled Classes targets.
The question is should the web-module with a seperate applet development effort be two projects. If this is developed as two projects then the applet code is not coupled to the web module project. I agree that we should look at usage patterns but in addition we should provide decide what the best practices are for projects.
adding another request from mailing list (written by Joe Warzecha): I have a situation where, depending on what the user selects on my project creation wizard, my nature may extend nature "a" or nature "b". How can I do this? It seems like all I've seen is how to specify which natures my nature extends in my nature.xml file and I don't want to specify that it extends both "a" and "b". Also, is there a way to change what natures my nature extends? For example, after the project is created, via a system action, I may want to change my nature so that it extends nature "b" instead of nature "a". How can I do this?
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped.
Marking issue as VERIFIED --->
---> CLOSED