Pete

extensions.xml You will see the line <import name=... Thanks! Exactly, what I was missing! Only a minimal amount of classes in /build, small .jar and renderers appear in a reasonable order in the dialog. Perfect.

How about making an improvement to the plugin registering process: Read all the plugin file names to a list. Run the list through registering and remove the successfully registered ones. Repeat as long the list gets shorter. Notify user & System.out about the remaining ones and their problems. A work around (I have not tried this) might be not to go super() in the plugin but then I'd have to write a wrapper to every method of the model plugin. Not very good from coding point of view.

How about making an improvement to the plugin registering process: Read all the plugin file names to a list. Run the list through registering and remove the successfully registered ones. Repeat as long the list gets shorter. Notify user & System.out about the remaining ones and their problems. A work around (I have not tried this) might be not to go super() in the plugin but then I'd have to write a wrapper to every method of the model plugin. Not very good from coding point of view.

Hi. I had a look at an old idea that would extend an existing plugin into a different variant of it. A renderer to be exact. It's an Ant build. What should I have in the build.xml? I can do it by adding <unjar src="${superjar}" dest="${build}" /> where "superjar" is the present Renderers.jar but I don't think this is optimal. It would seem better to just refer to the Renderers.jar that is existing, pretty much like ArtOfIllusion.jar or Buoy.jar but I seem to be missing something. In the <javac...>I...

Hi. I had a look at an old idea that would extend an existing plugin into a different variant of it. A renderer to be exact. It's an Ant build. What should I have in the build.xml? I can do it by adding <unjar src="${superjar}" dest="${build}" /> where "superjar" is the present Renderers.jar but I don't think this is optimal. It would seem better to just refer to the Renderers.jar that is existing, pretty much like ArtOfIllusion.jar or Buoy.jar but I seem to be missing something. In the <javac...>I...

Hi. I had a look at an old idea that would extend an existing plugin into a different variant of it. A renderer to be exact. It's an Ant build. What should I have in the build.xml? I can do it by adding <unjar src="${superjar}" dest="${build}" /> where "superjar" is the present Renderers.jar but I don't think this is optimal. It would seem better to just refer to the Renderers.jar that is existing, pretty much like ArtOfIllusion.jar or Buoy.jar but I seem to be missing something. In the <javac...>I...

Hi. I had a look at an old idea that would extend an existing plugin into a different variant of it. A renderer to be exact. It's an Ant build. What should I have in the build.xml? I can do it by adding <unjar src="${superjar}" dest="${build}" /> where "superjar" is the present Renderers.jar but I don't think this is optimal. It would seem better to just refer to the Renderers.jar that is existing, pretty much like ArtOfIllusion.jar or Buoy.jar but I seem to be missing something. In the <javac...>I...

Hi. I had a look at an old idea that would extend an existing plugin into a different variant of it. A renderer to be exact. It's an Ant build. What should I have in the build.xml? I can do it by adding <unjar src="${superjar}" dest="${build}" /> where "superjar" is the present Renderers.jar but I don't think this is optimal. It would seem better to just refer to the Renderers.jar that is existing, pretty much like ArtOfIllusion.jar or Buoy.jar but I seem to be missing something. In the <javac...>I...