For the record, this did work, when I properly installed it in a fresh, new, pristine eclipse tree.It also worked when I lanched it in debug mode.What I had been doing was rebuild plugin, and extract it to my eclipse directory, on top of the old/existing code.(Perhaps this will work, if I use a completely new workspace?)I had then deleted my old projects, then created new ones, and this discouragedAccess rule was not working.Now, I installed my eclipse to a tst\base dir.To test, I xcopy that toe tst\e, then extract the plugin to tst\e, and run, with new workspace.
On 3/1/06, Ted Kirby <firstname.lastname@example.org> wrote:I now have:<extension point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess"><restriction id="org.apache.geronimo.generic.runtime.10">
<path value="/lib/cglib- nodep-2.1_3.jar"/>
<path value="/lib/commons- i18n-1.0-G1M5.jar"/>
<path value="/lib/commons-logging-1.0.4.jar "/>
<path value="/lib/geronimo- deploy-jsr88-1.0.jar"/>
<path value="/lib/geronimo-deploy-tool-1.0.jar "/>
<path value="/lib/geronimo-j2ee-deployment_1.1_spec- 1.0.jar"/>
<path value="/lib/geronimo- kernel-1.0.jar"/>
<path value="/lib/geronimo- system-1.0.jar"/>
<path value="/lib/geronimo- util-1.0.jar"/>
I thought it worked once, but I have not been able to get it work again.Anything else I should check?I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well?Thanks,Ted
On 2/28/06, Sachin Patel <email@example.com > wrote:Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified.FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation.
Even though this is an acceptable and you have my recommendation on this solution we can go even further.
Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ.
On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote:
Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml.I got not .log errors, but I also did not get any access rules added to the selected jars in my build path,and my use of classes from a restricted jar was not flagged.Does path accept a .jar file, or directory only?Here is my extension element:<extension point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess">
<path value="/lib/commons-cli-1.0.jar "/>
<path value="/lib/geronimo-qname_1.1_spec-1.0.jar "/>
<path value="/lib/mx4j- 3.0.1.jar"/>
Thanks.On 2/28/06, Sachin Patel <firstname.lastname@example.org > wrote:I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same.
Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception.
On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote:
I want to use this new support.I put
<extensionpoint="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" ><path value="/lib" />
in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got:
org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91)
Where should I put the <extension> element?