WASTransformer

2006-10-27 Thread Abe White
Does anyone mind if I move this class from the org.apache.openjpa.util package to the org.apache.openjpa.ee package? It's a very EE-specific class, and in my mind is not a general utility other parts of the system will ever use. I'd even consider removing the class altogether and just

Re: WASTransformer

2006-10-27 Thread Marc Prud'hommeaux
On Oct 27, 2006, at 9:41 AM, Abe White wrote: Does anyone mind if I move this class from the org.apache.openjpa.util package to the org.apache.openjpa.ee package? It's a very EE-specific class, and in my mind is not a general utility other parts of the system will ever use. I'd even

Re: WASTransformer

2006-10-27 Thread Michael Dick
+1 for moving to org.apache.openjpa.ee. I don't really have a strong feeling about where the class should go. As you said it's really a build utility, I just wasn't sure where the best place was to put it. +0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless

Re: WASTransformer

2006-10-27 Thread Abe White
+0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless someone objects, there's no real need for another class. I went ahead and did this. I also moved WASManagedRuntime's caching logic to its endConfiguration() callback to avoid the threading issues that

Re: WASTransformer

2006-10-27 Thread Abe White
+0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless someone objects, there's no real need for another class. I went ahead and did this. I also moved WASManagedRuntime's caching logic to its endConfiguration() callback to avoid the threading issues that

Re: WASTransformer

2006-10-27 Thread Michael Dick
On 10/27/06, Abe White [EMAIL PROTECTED] wrote: +0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless someone objects, there's no real need for another class. I went ahead and did this. I also moved WASManagedRuntime's caching logic to its