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