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.
Implementation-wise, having a UML project be separate from the Java project it represents is a very good choice. But UI-wise, it's fairly non-intuitive - if I want a UML diagram of some classes or a package, I'll probably look on the context menu. The least likely place to look is in the New Project wizard. Conceptually it is very non-intuitive. I'd encourage you to make issue 72441 a hard requirement, as it provides the solution to this problem (a secondary project can decorate a primary project by contributing Nodes to the project's tree) - so UML support could be implemented as a secondary project (and you can still have standalone UML projects if useful), but the fact that it is a separate project is totally transparent to the user - the Java project just is decorated in the UI by the UML project. This seems like one of the biggest things that could be done to improve mainstream usability of the UML modules.
Issue 72441 does not solve the problem. 72441 would only allow us to to put an UML node under the Java project, it would not allow us to weave our UML information with the rest of the Java project information. For example, the user would be able to create an Use Case under any Java package. We would also want to reuse the existing Java nodes. When you select a Java class, you would be able to see the UML properties as well as the Java properties in the property editor. As you can see, there would be a lot more APIs that would be needed before we can move in this direction. Now lets consider a user that first designs an application then generates a Java project. In this case the UML information is already in a UML project. Should we move our UML information to he Java project and close (or delete) the UML project? What happens if an architect wants to continue to use the UML project, but does not care about the Java information? With the current implementation we at least have a consistent look and feel.
> Issue 72441 does not solve the problem. 72441 would only allow us to to put an > UML node under the Java project, it would not allow us to weave our UML > information with the rest of the Java project information. But that's exactly the point - design-wise, these things should be separate - and the UML project should remain openable separately; but the user experience shouldn't be having to work in a separate hierarchy to do it. Think of it as a way to do composition rather than inheritance to add new decorations to projects - a lot of folks get hung up on the idea that what they really need is some way of extending Java projects - and for most cases that's not the case if you can do something like this. > When you select a Java class, you would be able to see the UML properties as > well as the Java properties in the property editor. There's a very good reason that we've moved away from property-sheet-centric UIs - repeated usability studies showed that they had quite poor usability. I can easily imagine having a TopComponent that has behavior similar to the Palette in recent builds - it appears when the current selection has a particular type of object in its Lookup. Exactly the same thing could be done for some nice, user-friendly UI for the relevant UML properties - you can actually create a better user experience *without* resorting to inserting anything in the properties of Nodes. It's just a question of thinking out of the box a bit. > In this case the UML information is already in a UML project. Should > we move our UML information to he Java project and close (or delete) the UML > project? Nonononono...the whole point is that the UML data ought to be kept separately - nothing should need to be moved under the Java project except perhaps pointers in the project properties to where the UML projects live. Seriously, think composition rather than inheritance here and a whole new world of possibilities open up. Java project types shouldn't need to be extended to provide hooks for every new kind of decorating data someone conceives of - the system will be much more stable and useful long-term through this approach, and it does not have to compromise usability. Not to mention far easier for any kind of decorating module, be it UML, JNLP or other, to automagically work with future Java project types and not need changes as Java projects change across releases, because the surface area of the dependency is minimized. > As you can see, there > would be a lot more APIs that would be needed before we can move in this > direction. In terms of Java nodes, I believe there already exist hooks for contributing Nodes under a Java file's Node - this is how the Bean Patterns node is provided by the Beans module; there are also hooks for adding actions by mime type (and you can use this to provide an action that is only visible on files where appropriate). I've added Rochelle to cc, as I know the long-defunct JDO modules did some similar things; some of the APIs for decorating Java nodes may be deprecated, but should all still exist and work; all of these are things we should make sure are expressed as major requirements for retouche. Seriously, you can do everything you need to do here while injecting only a small amount of metadata into any Java project (that metadata could even simply be a UML project detected under the root of the java project). This is really the way it ought to be done long-term if we want the maintenance burden to be relatively light and both the java project and the UML code stable and separable. You keep the flexibility to change what you want, and so does the Java module, yet they keep working together regardless. Seriously, take a look at all the things you would want a UML-enabled Java project to do, and ask yourself what you would need to do it by composing a secondary project into the source project (well, neither is really secondary - the relationship should be bidirectional, w/ Java sources appearing in a node under a UML project). If there are any holes, we should plug those now or make sure they are addressed in the next release.
I do not agree that having a seperate top level node is the best approach. If we are going to embed the information into the Java Project, I think it should be weaved with with the rest of the Java objects. >There's a very good reason that we've moved away from property-sheet-centric UIs > - repeated usability studies showed that they had quite poor usability. I do not understand this comment. I have not seen any components moving away from a project sheet properties. UML, form editor and I believe the BPEL editor uses property sheets. Matter a fact this is the reason why UML moved to the property sheet when we changed our property editor. I believe that we should make it easier to create diagram using Java objects, however I do not know if issue 72441 solves any problem for us. > In terms of Java nodes, I believe there already exist hooks for contributing > Nodes under a Java file's Node - this is how the Bean Patterns node is > provided by the Beans module; there are also hooks for adding actions by mime > type (and you can use this to provide an action that is only visible on files > where appropriate). We are currently embedding some information under the class node. The problem is that we can not put informaiton under any other node in the Java project. > Seriously, take a look at all the things you would want a UML-enabled Java > project to do, and ask yourself what you would need to do it by composing a > secondary project into the source project (well, neither is really secondary - > the relationship should be bidirectional, w/ Java sources appearing in a node > under a UML project). If there are any holes, we should plug those now or > make sure they are addressed in the next release. Trust me this is not the way I want to support the Java project. I really want to see that we can weave our data into the Java project nodes. I do not think that suppling a top level node under the Java project is the correct answer. But keep in mind that we have to support both the Java developer as well as the pure architect. The UML project may be used by both of the Java user as well as the architect. So, we have a thin line to walk here.
Thanks for adding me, Tim. Some comments: 1) Are looks officially dead forever? 2) What about the project natures that Petr implemented? 3) The way the JDO (and I think bean pattern modules) did things were to use subclasses of java module classes. That was never recommended, only necessary. It was a combination of those subclasses and deprecated NodeFactory composition.
> I do not understand this comment. I have not seen any components moving away > from a project sheet properties. UML, form editor and I believe the BPEL editor > uses property sheets. Fire up NetBeans 3.5 sometime. The entire UI was property-sheet centric, the property sheet was always open by default, and the way to access all kinds of functionality was through the property sheet. It was a very conscious decision to not have the property sheet open by default anymore, not have it be the primary way you access functionality in the IDE. Talk to Jano Rojcek or Dusan Pavlica, who were both around for this. You'll notice that none of the new functionality in 4.0 and later shows a property sheet to access things - project customizers could easily have been done this way, and in an earlier era, probably would have been. I know that the Prague team is very keenly aware that you don't use a property sheet in your UI unless you're *really* in a situation where you have foreign objects injected into the UI (as in the form editor) and no idea what they'll want to show. And even the form editor will very likely soon move to customizers instead of the property sheet as the default UI, ala Interface Builder. It appears that the ethic of no-new property-sheet-centric UIs never made it out of Prague - for that lack of communication I'm genuinely sorry. > I really want to see that we can weave our data into the Java project nodes. I am not saying that you should not do that; I'm suggesting you do both. I.e. for things that make sense (diagrams?), have that stuff under a project sub-node. For the java node stuff, and for decorating packages, you probably do need some hooks from the java project. The point is that we'll solve a major usability problem once we can get rid of the user model where you create a UML project that's magically synchronized with the Java project. What I'm saying here is that the right engineering approach to do this sustainably is to keep the separate project infrastructure, and do it by decorating a Java project, rather than extending it. And that a good start at doing that can be had through issue 72441. As long as the user model is right, how it happens under the hood is an implementation detail, but if the approach is extending Java projects, that's not going to be sustainable long-term, while the composition approach is. And more importantly, with issue 72441 + project sensitive actions, which we already have, you can do a substantial amount to move toward a much more user friendly model right now. Even if the ideal is to have the UML stuff mixed in with the Java files, exposing this as a node under the project would make a substantial improvement in usability for the UML modules right now, and that beats the pants off waiting for perfection.
*** Issue 102165 has been marked as a duplicate of this issue. ***
An UML node should appear in the explorer of the Java (Web) project, that shows an associated UML project (like the Web Service node in web projects). Example: Project Properties -> Imported UML projects (or fortunately UML profiles) to associate the diagram with a project + a (context) node in the package explorer for the selected element type