Community
Participate
Working Groups
Build Identifier: I20110512-2000 It appears that when attempting to use jpa plugins with velocity 1.7.1 classloader exceptions occur. java.lang.Exception: The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. at org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:589) at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241) at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:534) at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:144) at org.eclipse.jpt.jpa.gen.internal.PackageGenerator.generateClass(PackageGenerator.java:230) at org.eclipse.jpt.jpa.gen.internal.PackageGenerator.generateInternal(PackageGenerator.java:112) at org.eclipse.jpt.jpa.gen.internal.PackageGenerator.doGenerate(PackageGenerator.java:90) at org.eclipse.jpt.jpa.gen.internal.PackageGenerator.generate(PackageGenerator.java:67) at org.eclipse.jpt.jpa.ui.internal.wizards.gen.GenerateEntitiesFromSchemaWizard$GenerateEntitiesJob.runInWorkspace(GenerateEntitiesFromSchemaWizard.java:248) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Always Steps to Reproduce: 1. Basically create an additional plugin that exports velocity 1.7.1 packages. 2. Create a project that takes includes both jpa and velocity 1.7.1. 3. Generate JPA entities from tables.
Moving JPA specific bugs to new JPA component in bugzilla.
Finally taking a look at this for maintenance. I'm wondering if in this scenario the cause of Velocity not functioning properly is a result of its dependencies? Are you sure that all dependent jars are at the right version levels to support Velocity 1.7.1 in this environment. Such as: org.apache.commons.collections org.apache.commons.lang org.jdom
I'm pretty sure we had everything aligned properly, the velocity 1.7.1 implementation did work independently of JPA inclusion. It was when the two plugins were active that the problem presented itself.
I'll package up a repro plugin, that may work better for analysis and if there are dependency problems hopefully they are presented there.
Danny, Do you know of anything in our Velocity usage that would be subject to breakage on new minor version updates? It seems odd to me that our code would not work with Velocity 1.7.x unless new dependencies were added, or if we were using internal or provision API's. Let me know if you have any insight on this. I thought our usage was pretty straight-forward.
(In reply to comment #4) > I'll package up a repro plugin, that may work better for analysis and if there > are dependency problems hopefully they are presented there. Thanks!
>> Do you know of anything in our Velocity usage that would >> be subject to breakage on new minor version updates? Don't think so. But some testing is needed to make sure that is the case.
Created attachment 201352 [details] The 1.7.1 velocity plugin The 1.7.1 Velocity plugin. Use to repro the problem.
In the repro plugin, it is named org.eclipse.velocity and exporting versioned packages. Where locally I am using a plugin named org.apache.velocity, it seems be properly filtered from the jpa plugin classpath and not causing the exception. I'm still testing this.
Created attachment 201358 [details] The Command Menu Plugin That Uses Velocity 1.7.1 This is a sample handler, just displays output from invoking the Velocity engine. Repro: 1. Import as existing plugins 2. Run-As Launch Eclipse 3. Configure a JPA project 3. Select from the main menu the command Sample Menu->Sample Command 4. Generate Entities from tables
Was just taking another look at this. So I don't think the problem is that Dali requires a certain version of Velocity, but rather this issue is presenting as a result of multiple (different) versions of Velocity being available in the same class space. Narrowing our version range isn't appropriate in this case since I fully expect Dali to work with Velocity 1.7.1. That said, we probably should have a range defined, probably up to 2.0.0. You mentioned that it works when your velocity plugin is named "org.apache.velocity". When named the same as our Velocity dependency, Equinox is probably using the higher versioned Velocity bundle for all dependent bundles that can handle that version, including Dali. In this case there is only 1 version of Velocity available in the jpt.jpa.gen class space. When using the "org.eclipse.velocity" bundle name two versions of Velocity become available (since Dali is using Requires-Bundle and not Import-Package for the Velocity dependency). This combination would likely work if we were using Import-Package as it would simply pick up the exported packages from org.eclipse.velocity if they are already available. I think this is the ultimate solution to this problem, have Dali move to Import-Package for its Velocity dependency. This usage isn't very common in the Eclipse IDE for a variety of reasons, but makes sense when dealing with 3rd party libraries. The workaround to this issue is to ensure that any 3rd party Velocity bundles are named consistently with what is found in Eclipse Orbit. What development stream is this fix important for, or is your bundle naming flexible, and as a result this is not an urgent issue?
Thanks Neil for your detailed response to this problem. I think we can be flexible in our velocity implementation such that we should not impose an urgent fix on your side. I agree with your synopsis on 3rd party libraries as they can be exposed in a variety of ways, thus it seems the import-package is a good way to fix this.
Sounds good. I will target this for our next major release then. Let me know if anything changes.
Fixed in Head for Juno.
Hello , I have the same problem. This is my description: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394616 If some one fix this problem,please!
