This issue was originally reported by Emilian Bold in 12/Oct/07 at codehaus.org - see more details at
http://jira.codehaus.org/browse/MEVENIDE-563
Environment: Java 5, OSX, NetBeans 5.5.1, latest Mevenide from the update center

===========
Description:
===========
The NetBeans form editor allows users to register their own components.
But Maven2 projects can't be used at all. Opening a JavaBean and selecting Tools->Add to Palette... gives an error that
it can't be used.
Normally the Palette Manager should be able to use either the classes from targer/ or the JARs from the local maven repo.
From the little code I've read in the Palette Manager classes, it uses the project's classloader. Perhaps this is what's
missing (or maybe it's more subtle than that...)

----------------------------------------------
Comment by Milos Kleint [ 12/Oct/07 06:29 AM ]
----------------------------------------------
the problem is the action requires the project to implement AntArtifact interface which the Maven support cannot provide.
I've filed as http://www.netbeans.org/issues/show_bug.cgi?id=118694 in netbeans issuezilla. Nothing can be done on
mevenide side. A possible workaround is to add the beans to palette directly from the repository jar.

----------------------------------------------
Comment by Emilian Bold [ 16/Oct/07 05:39 AM ]
----------------------------------------------
I'd like to add that using the palette with the JARs from the repository also doesn't work. I'm able to use the same
custom Bean in a standard J2SE project, but with a maven project (which has all the dependencies), it doesn't work.
It might be that the Palette manager also looks at the "dependencies" of the parent project for the form file and sees
if it can instantiate the bean. I assume the Maven project doesn't provide this.
For example, in a normal J2SE Project I need to add the "Library" (where the bean resides) as a dependency otherwise the
form editor doesn't work.
Thus, while the Palette manager might be able to register javabeans using the repository JARs, it still won't be able to
instantiate them if all those JARs don't show up as some dependency.
This is really annoying as I've learned to use the custombeans a lot and now I can't edit any form (I need to move the
form to another temporary project in order to edit it).
AntArtifact.getArtifactLocations() might be what I need...

----------------------------------------------
Comment by Milos Kleint [ 16/Oct/07 07:03 AM ]
----------------------------------------------
Yes, you need to have the bean on the classpath of the project.
In j2se projects it means having it as library of the project, in maven projects it means declaring a dependency on the
artifact defining the bean.
I'm not sure I follow where the problem is. I'm not using the palette myself much but I just tried to register a Panel
instance from repository jar of Project A in the palette, in project B which depends on A, I opened another panel from
project B and adde dthe panel from palette without problems.

----------------------------------------------
Comment by Emilian Bold [ 16/Oct/07 07:13 AM ]
----------------------------------------------
My setup is this:
Client [1] (nbm) which depends on Server [2] (nbm).
Server defines a Bean which inherits from Library [2] (normal JAR). Basically you can think of the Server project as a
library wrapper.
So perhaps it works in this 1:1 case you mentioned about but it doesn't work for me, maybe because my bean touches a lot
of artifacts which are dependencies of Server module.
I'll try to make a simple example with just a bean and a more complex dependency structure.
Maybe I'm doing something wrong on my side, but it does work for normal projects so I assume it's maven-related.
Plus, I just noticed, I can't even open the forms that belong to Server and use that custom bean (declared in Server
itself).
Sample graph:
Client (nbm) — (dep) – > Server (nbm)
Server (nbm) — (dep) --> Library Wrapper (nbm) – wraps --> Parent Bean Library (jar).
Server (nbm) — (dep) ---> Other JARs.
The bean basically touches most of the Server's dependencies.

----------------------------------------------
Comment by Emilian Bold [ 16/Oct/07 08:55 AM ]
----------------------------------------------
Ok, my bad. I can use the Bean if using a proper Library for the Palette Manager with all the needed JARs.
The problem was a bit more subtle. From long ago, when I first migrated to Mevenide, I had some compile problems. So
I've added as a dependency something like this: compile dependency for the nbm library wrapper and provided dependency
for the jar I was wrapping with the library wrapper.
Well, it seems that the "provided" scope overrided the "compile" scope from the wrapper (which has a dependency on it).
So, the Palette Manager won't find the JAR due to this. Interesting.
Sorry for the spam, this was most unexpected.

----------------------------------------------
Comment by Milos Kleint [ 16/Oct/07 09:19 AM ]
----------------------------------------------
that's indeed strange. AFAIK the provided scope equals compile scope, it's expected to be part of the environment at
runtime so for example war files won't include provided dependencies but only the compile ones..