You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jonathan Gallimore <jo...@gmail.com> on 2008/08/06 14:54:49 UTC
OpenEJB Eclipse Plugin update
Hi All,
Just wanted to give you an update on the Eclipse plugin.
In response to a couple of bugs logged in Jira (OPENEJB-869 and
OPENEJB-876) I've made a couple of changes around the server runtime.
Specifically, I've changed how deployment works - previously a deploy
simply built a jar file based on the output paths of a project and
copied it to the apps folder of the standalone server. This worked ok,
but caused problems with file locking on un-deploying and republishing.
Now we hold a cache of which projects have been deployed, and then once
the server has started, we use the WTP export feature to build the jar,
and then use the Deployer bean openejb-core to do the actual deployment.
I also corrected a bug where multiple server monitor threads were being
created when restarting the server. The server icon is now the pepper
instead of just a red square.
I've published my latest update site on my people page:
http://people.apache.org/~jgallimore/update-site
The feedback on these changes (via Jira) has been very positive. Many
thanks to Kaloyan Raev for taking the time to test and re-test the
plugin, and for logging the issues.
In terms of extending the plugin further, I was going to look at doing
the following:
* see if I can replace any usages of finder and create methods on Entity
beans with EJB 3 style EntityManager code
* add support for using websphere/weblogic descriptors instead of
openejb-jar.xml for generating annotations
* Karan suggested a drag-n-drop dependency injection idea, which I was
going to look at too.
Does anybody have any other thoughts or suggestions?
I was also thinking it might perhaps be a good idea to either close
OPENEJB-674 and open new issues for these tasks or to add subtasks to
OPENEJB-674 - anyone got any thoughts on this?
Cheers
Jon
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Karan Malhi wrote:
>> I think OPENEJB-516 (https://issues.apache.org/jira/browse/OPENEJB-516)
>> can be closed, as the plugin will now add the javaee-api and openejb-client
>> JARs to the classpath of projects associated with its runtime - does anyone
>> have any thoughts on this?
>>
>> I also think OPENEJB-525 (
>> https://issues.apache.org/jira/browse/OPENEJB-525) can be closed as the
>> plugin is now built with Maven.
>>
>>
>
> Yes, these issues should be closed.
>
Done. I also closed OPENEJB-687 as its really a duplicate of OPENEJB-674.
> Also, I think David just implemented the DependsOn functionality. What do
> you think about generating a dependency graph in eclipse? i.e the plugin
> could scrape through the EJB's / descriptors and generate this graph (which
> could possibly also be modified).
>
I think this is cool idea - its certainly possible to detect which
classes have the @Singleton annotation and analyze their usages. As Dain
has pointed out, it would definitely be tricky if the singleton is
referred to in a method that is called by the Pre/PostConstruct method.
We could search for all usages of singletons and traverse the call
hierarchy and see if we end up at a Pre/Post construct method, although
I could imagine this being a pretty intensive operation. Do you have any
thoughts on how this would be invoked? I guess it wouldn't be via the
wizard we have for annotation generation from ejb-jar.xml we have at the
moment. I was thinking perhaps adding a builder which spots references
being added, and showing a warning with a code completion would be
pretty cool - don't know how much work would be involved though.
Jon
Re: OpenEJB Eclipse Plugin update
Posted by "Daniel S. Haischt" <da...@googlemail.com>.
yes an all-in-one package
On Thu, Sep 25, 2008 at 12:45 PM, Jonathan Gallimore
<jo...@gmail.com> wrote:
> You mean like an 'all-in-one' package? I like the idea. I think it might be
> a lot of work to create it for shapshots, but its something I think is
> worthwhile doing when we release, or put up some betas :)
>
> Jon
>
>
> Daniel S. Haischt wrote:
>>
>> crazy idea probably but I post it anyway...
>>
>> Was remembering the guy who was asking recently how to setup Eclipse
>> to develop EJBs etc. ...
>>
>> Do you think it would make sense to create an Eclipse product
>> configuration that contains the WTP
>> and any other required plugin/feature required to develop OpenEJB
>> based apps including our OpenEJB
>> plugin stuff which then can be downloaded as a zipped product?
>>
>> The product would be of course just a re-branded Eclipse SDK.
>>
>> On Wed, Sep 24, 2008 at 7:47 PM, Jonathan Gallimore
>> <jo...@gmail.com> wrote:
>>
>>>
>>> I've just committed this and updated the update site. There's a tick box
>>> to
>>> include the dependency when creating / editing the runtime.
>>>
>>> Jon
>>>
>>> David Blevins wrote:
>>>
>>>>
>>>> On Sep 9, 2008, at 4:47 AM, Jonathan Gallimore wrote:
>>>>
>>>>
>>>>>
>>>>> I also forgot to mention - I think it would be useful to have an option
>>>>> to include the 3.1 experimental jars on a project. I don't think
>>>>> Eclipse WTP
>>>>> has any 3.1 support yet, but we could just add it as an option on our
>>>>> runtime configuration panel. Does anyone have any objections or other
>>>>> thoughts?
>>>>>
>>>>
>>>> No objections here. I think it will be good to give people the option
>>>> to
>>>> pull in that dep easily.
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>
>
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
You mean like an 'all-in-one' package? I like the idea. I think it might
be a lot of work to create it for shapshots, but its something I think
is worthwhile doing when we release, or put up some betas :)
Jon
Daniel S. Haischt wrote:
> crazy idea probably but I post it anyway...
>
> Was remembering the guy who was asking recently how to setup Eclipse
> to develop EJBs etc. ...
>
> Do you think it would make sense to create an Eclipse product
> configuration that contains the WTP
> and any other required plugin/feature required to develop OpenEJB
> based apps including our OpenEJB
> plugin stuff which then can be downloaded as a zipped product?
>
> The product would be of course just a re-branded Eclipse SDK.
>
> On Wed, Sep 24, 2008 at 7:47 PM, Jonathan Gallimore
> <jo...@gmail.com> wrote:
>
>> I've just committed this and updated the update site. There's a tick box to
>> include the dependency when creating / editing the runtime.
>>
>> Jon
>>
>> David Blevins wrote:
>>
>>> On Sep 9, 2008, at 4:47 AM, Jonathan Gallimore wrote:
>>>
>>>
>>>> I also forgot to mention - I think it would be useful to have an option
>>>> to include the 3.1 experimental jars on a project. I don't think Eclipse WTP
>>>> has any 3.1 support yet, but we could just add it as an option on our
>>>> runtime configuration panel. Does anyone have any objections or other
>>>> thoughts?
>>>>
>>> No objections here. I think it will be good to give people the option to
>>> pull in that dep easily.
>>>
>>> -David
>>>
>>>
>>
Re: OpenEJB Eclipse Plugin update
Posted by "Daniel S. Haischt" <da...@googlemail.com>.
crazy idea probably but I post it anyway...
Was remembering the guy who was asking recently how to setup Eclipse
to develop EJBs etc. ...
Do you think it would make sense to create an Eclipse product
configuration that contains the WTP
and any other required plugin/feature required to develop OpenEJB
based apps including our OpenEJB
plugin stuff which then can be downloaded as a zipped product?
The product would be of course just a re-branded Eclipse SDK.
On Wed, Sep 24, 2008 at 7:47 PM, Jonathan Gallimore
<jo...@gmail.com> wrote:
> I've just committed this and updated the update site. There's a tick box to
> include the dependency when creating / editing the runtime.
>
> Jon
>
> David Blevins wrote:
>>
>> On Sep 9, 2008, at 4:47 AM, Jonathan Gallimore wrote:
>>
>>> I also forgot to mention - I think it would be useful to have an option
>>> to include the 3.1 experimental jars on a project. I don't think Eclipse WTP
>>> has any 3.1 support yet, but we could just add it as an option on our
>>> runtime configuration panel. Does anyone have any objections or other
>>> thoughts?
>>
>> No objections here. I think it will be good to give people the option to
>> pull in that dep easily.
>>
>> -David
>>
>
>
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
I've just committed this and updated the update site. There's a tick box
to include the dependency when creating / editing the runtime.
Jon
David Blevins wrote:
>
> On Sep 9, 2008, at 4:47 AM, Jonathan Gallimore wrote:
>
>> I also forgot to mention - I think it would be useful to have an
>> option to include the 3.1 experimental jars on a project. I don't
>> think Eclipse WTP has any 3.1 support yet, but we could just add it
>> as an option on our runtime configuration panel. Does anyone have any
>> objections or other thoughts?
>
> No objections here. I think it will be good to give people the option
> to pull in that dep easily.
>
> -David
>
Re: OpenEJB Eclipse Plugin update
Posted by David Blevins <da...@visi.com>.
On Sep 9, 2008, at 4:47 AM, Jonathan Gallimore wrote:
> I also forgot to mention - I think it would be useful to have an
> option to include the 3.1 experimental jars on a project. I don't
> think Eclipse WTP has any 3.1 support yet, but we could just add it
> as an option on our runtime configuration panel. Does anyone have
> any objections or other thoughts?
No objections here. I think it will be good to give people the option
to pull in that dep easily.
-David
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
I also forgot to mention - I think it would be useful to have an option
to include the 3.1 experimental jars on a project. I don't think Eclipse
WTP has any 3.1 support yet, but we could just add it as an option on
our runtime configuration panel. Does anyone have any objections or
other thoughts?
Jon
Jonathan Gallimore wrote:
> I've managed to hack something up around this - basically it uses JDT
> to parse the necessary Singletons, and then walks through the
> PreDestroy and PostContruct methods looking for method invocations.
> Its pretty basic at the moment, it does a complete search on every
> build, rather than building incrementally. It does work recursively,
> and will visit other classes (if you make a call like new
> MyOtherClass().someMethod() in the PreDestroy/PostConstruct method for
> example), so its potentially a long running operation. It will mark
> incorrect / missing uses of @DependsOn as errors.
>
> I've checked it in, but left it to be switched off by default. I'm
> planning to add quick fix and incremental build support soon too.
>
> Any comments are welcome. I'm also happy to have a go at providing
> this in IntelliJ if that would be useful to anyone.
>
> Jon
>
>
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Thanks David. I'll get some info up on the Wiki about this. I could
probably make an inspection for IntelliJ that does this as well, if
anyone would find that helpful.
Jon
David Blevins wrote:
>
> On Sep 8, 2008, at 1:50 PM, Jonathan Gallimore wrote:
>
>> I've managed to hack something up around this - basically it uses JDT
>> to parse the necessary Singletons, and then walks through the
>> PreDestroy and PostContruct methods looking for method invocations.
>> Its pretty basic at the moment, it does a complete search on every
>> build, rather than building incrementally. It does work recursively,
>> and will visit other classes (if you make a call like new
>> MyOtherClass().someMethod() in the PreDestroy/PostConstruct method
>> for example), so its potentially a long running operation. It will
>> mark incorrect / missing uses of @DependsOn as errors.
>>
>> I've checked it in, but left it to be switched off by default. I'm
>> planning to add quick fix and incremental build support soon too.
>
> This is completely awesome!
>
> -David
>
Re: OpenEJB Eclipse Plugin update
Posted by David Blevins <da...@visi.com>.
On Sep 8, 2008, at 1:50 PM, Jonathan Gallimore wrote:
> I've managed to hack something up around this - basically it uses
> JDT to parse the necessary Singletons, and then walks through the
> PreDestroy and PostContruct methods looking for method invocations.
> Its pretty basic at the moment, it does a complete search on every
> build, rather than building incrementally. It does work recursively,
> and will visit other classes (if you make a call like new
> MyOtherClass().someMethod() in the PreDestroy/PostConstruct method
> for example), so its potentially a long running operation. It will
> mark incorrect / missing uses of @DependsOn as errors.
>
> I've checked it in, but left it to be switched off by default. I'm
> planning to add quick fix and incremental build support soon too.
This is completely awesome!
-David
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
I've managed to hack something up around this - basically it uses JDT to
parse the necessary Singletons, and then walks through the PreDestroy
and PostContruct methods looking for method invocations. Its pretty
basic at the moment, it does a complete search on every build, rather
than building incrementally. It does work recursively, and will visit
other classes (if you make a call like new MyOtherClass().someMethod()
in the PreDestroy/PostConstruct method for example), so its potentially
a long running operation. It will mark incorrect / missing uses of
@DependsOn as errors.
I've checked it in, but left it to be switched off by default. I'm
planning to add quick fix and incremental build support soon too.
Any comments are welcome. I'm also happy to have a go at providing this
in IntelliJ if that would be useful to anyone.
Jon
David Blevins wrote:
>
> On Aug 7, 2008, at 9:11 AM, Karan Malhi wrote:
>
>>>
>>> I think OPENEJB-516 (https://issues.apache.org/jira/browse/OPENEJB-516)
>>> can be closed, as the plugin will now add the javaee-api and
>>> openejb-client
>>> JARs to the classpath of projects associated with its runtime - does
>>> anyone
>>> have any thoughts on this?
>>>
>>> I also think OPENEJB-525 (
>>> https://issues.apache.org/jira/browse/OPENEJB-525) can be closed as the
>>> plugin is now built with Maven.
>>>
>>
>> Yes, these issues should be closed.
>> Also, I think David just implemented the DependsOn functionality.
>> What do
>> you think about generating a dependency graph in eclipse? i.e the plugin
>> could scrape through the EJB's / descriptors and generate this graph
>> (which
>> could possibly also be modified).
>
> Along those lines what would be really cool is if the tool could add
> the @DependsOn automatically for a user.
>
> A singleton needs a @DependsOn declaration only when referring to
> (invoking) another singleton in either its @PostConstruct or
> @PreDestroy method. I don't know if it's possible, but if there was
> some way spot that and add the @DependsOn for them, that'd be really
> cool.
>
> As an example, the bean has this:
>
> @Singleton
> @Startup
> public class RedBean {
>
> @EJB(beanName="BlueBean")
> private BlueLocal blue
>
> @PostConstruct
> public void startup() {
>
> }
> }
>
> and all is fine, but when they add this to the @PostConstruct method...
>
> @PostConstruct
> public void startup() {
> blue.doSomeWork();
> }
>
> At that point you need to add the @DependsOn like so:
>
> @Singleton
> @Startup
> @DependsOn("BlueBean")
> public class RedBean {
> ...
> }
>
> Don't know if that's possible, but would be cool.
>
> -David
>
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Hi All,
I've made a couple of changes to the plugin:
- Allowed the OpenEJB runtime to be used on EJB 1.1 ane EJB 2.0 projects
(OPENEJB-868)
- Added configuration for all the OpenEJB ports the standalone server
uses (and made the server actually use the ports specified). Also the
launch configuration in Eclipse for the standalone server didn't include
the Java agent, I've fixed this as well. (OPENEJB-887)
As usual, I've updated the update site on my page on people.apache.org.
Enjoy!
Jon
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Hi All,
I've just added support for deploying EAR files to a standalone server
to the Eclipse plugin (OPENEJB-882). I've also updated the update site
that is on my Apache page: http://people.apache.org/~jgallimore/update-site
Cheers
Jon
Re: OpenEJB Eclipse Plugin update
Posted by David Blevins <da...@visi.com>.
Another idea is that every time they add do @DependsOn, we could check
for circular references and tell the user they've just created a
circular reference. Being able to determine where circular references
start is impossible unless you were there when it was created, but we
are there and can say with precision "that's the one that did it."
-David
On Aug 7, 2008, at 3:09 PM, Jonathan Gallimore wrote:
> I think you're right, it could be pretty hairy. We could traverse
> the call hierarchy as I've mentioned in a reply to Karan's mail.
> Incidentally, the false-positive case you mention with the if
> statement - would it be a problem adding the @DependsOn annotation
> in this case? Although that code would never get executed,
> technically we are referring to the other singleton.
>
> I'll have a play about with some JDT code over the next few days and
> try and get a better idea of what's involved.
>
> Jon
>
>
> Dain Sundstrom wrote:
>> It's not that hard to write some ASM code to detect that simple
>> kind of usage, but more complex usage would be difficult to
>> impossible. For example:
>>
>> @PostConstruct
>> public void startup() {
>> initBlue();
>> }
>>
>> private void initBlue() {
>> blue.doSomeWork();
>> }
>>
>> Now imagine how complex you can make that code and you quickly come
>> to the conclusion that it is almost impossible to detect reliably.
>> Of course if you are only interested somewhat accurate results, you
>> could use a simple detect algorithm, but you will miss some usages
>> and get some false positives (for example if (false)
>> blue.doSomeWork()).
>>
>> -dain
>>
>> On Aug 7, 2008, at 12:57 PM, David Blevins wrote:
>>
>>> Along those lines what would be really cool is if the tool could
>>> add the @DependsOn automatically for a user.
>>>
>>> A singleton needs a @DependsOn declaration only when referring to
>>> (invoking) another singleton in either its @PostConstruct or
>>> @PreDestroy method. I don't know if it's possible, but if there
>>> was some way spot that and add the @DependsOn for them, that'd be
>>> really cool.
>>>
>>> As an example, the bean has this:
>>>
>>> @Singleton
>>> @Startup
>>> public class RedBean {
>>>
>>> @EJB(beanName="BlueBean")
>>> private BlueLocal blue
>>>
>>> @PostConstruct
>>> public void startup() {
>>>
>>> }
>>> }
>>>
>>> and all is fine, but when they add this to the @PostConstruct
>>> method...
>>>
>>> @PostConstruct
>>> public void startup() {
>>> blue.doSomeWork();
>>> }
>>>
>>> At that point you need to add the @DependsOn like so:
>>>
>>> @Singleton
>>> @Startup
>>> @DependsOn("BlueBean")
>>> public class RedBean {
>>> ...
>>> }
>>>
>>> Don't know if that's possible, but would be cool.
>>>
>>> -David
>>>
>>
>
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
I think you're right, it could be pretty hairy. We could traverse the
call hierarchy as I've mentioned in a reply to Karan's mail.
Incidentally, the false-positive case you mention with the if statement
- would it be a problem adding the @DependsOn annotation in this case?
Although that code would never get executed, technically we are
referring to the other singleton.
I'll have a play about with some JDT code over the next few days and try
and get a better idea of what's involved.
Jon
Dain Sundstrom wrote:
> It's not that hard to write some ASM code to detect that simple kind
> of usage, but more complex usage would be difficult to impossible.
> For example:
>
> @PostConstruct
> public void startup() {
> initBlue();
> }
>
> private void initBlue() {
> blue.doSomeWork();
> }
>
> Now imagine how complex you can make that code and you quickly come to
> the conclusion that it is almost impossible to detect reliably. Of
> course if you are only interested somewhat accurate results, you could
> use a simple detect algorithm, but you will miss some usages and get
> some false positives (for example if (false) blue.doSomeWork()).
>
> -dain
>
> On Aug 7, 2008, at 12:57 PM, David Blevins wrote:
>
>> Along those lines what would be really cool is if the tool could add
>> the @DependsOn automatically for a user.
>>
>> A singleton needs a @DependsOn declaration only when referring to
>> (invoking) another singleton in either its @PostConstruct or
>> @PreDestroy method. I don't know if it's possible, but if there was
>> some way spot that and add the @DependsOn for them, that'd be really
>> cool.
>>
>> As an example, the bean has this:
>>
>> @Singleton
>> @Startup
>> public class RedBean {
>>
>> @EJB(beanName="BlueBean")
>> private BlueLocal blue
>>
>> @PostConstruct
>> public void startup() {
>>
>> }
>> }
>>
>> and all is fine, but when they add this to the @PostConstruct method...
>>
>> @PostConstruct
>> public void startup() {
>> blue.doSomeWork();
>> }
>>
>> At that point you need to add the @DependsOn like so:
>>
>> @Singleton
>> @Startup
>> @DependsOn("BlueBean")
>> public class RedBean {
>> ...
>> }
>>
>> Don't know if that's possible, but would be cool.
>>
>> -David
>>
>
Re: OpenEJB Eclipse Plugin update
Posted by Dain Sundstrom <da...@iq80.com>.
It's not that hard to write some ASM code to detect that simple kind
of usage, but more complex usage would be difficult to impossible.
For example:
@PostConstruct
public void startup() {
initBlue();
}
private void initBlue() {
blue.doSomeWork();
}
Now imagine how complex you can make that code and you quickly come to
the conclusion that it is almost impossible to detect reliably. Of
course if you are only interested somewhat accurate results, you could
use a simple detect algorithm, but you will miss some usages and get
some false positives (for example if (false) blue.doSomeWork()).
-dain
On Aug 7, 2008, at 12:57 PM, David Blevins wrote:
> Along those lines what would be really cool is if the tool could add
> the @DependsOn automatically for a user.
>
> A singleton needs a @DependsOn declaration only when referring to
> (invoking) another singleton in either its @PostConstruct or
> @PreDestroy method. I don't know if it's possible, but if there was
> some way spot that and add the @DependsOn for them, that'd be really
> cool.
>
> As an example, the bean has this:
>
> @Singleton
> @Startup
> public class RedBean {
>
> @EJB(beanName="BlueBean")
> private BlueLocal blue
>
> @PostConstruct
> public void startup() {
>
> }
> }
>
> and all is fine, but when they add this to the @PostConstruct
> method...
>
> @PostConstruct
> public void startup() {
> blue.doSomeWork();
> }
>
> At that point you need to add the @DependsOn like so:
>
> @Singleton
> @Startup
> @DependsOn("BlueBean")
> public class RedBean {
> ...
> }
>
> Don't know if that's possible, but would be cool.
>
> -David
>
Re: OpenEJB Eclipse Plugin update
Posted by David Blevins <da...@visi.com>.
On Aug 7, 2008, at 9:11 AM, Karan Malhi wrote:
>>
>> I think OPENEJB-516 (https://issues.apache.org/jira/browse/OPENEJB-516
>> )
>> can be closed, as the plugin will now add the javaee-api and
>> openejb-client
>> JARs to the classpath of projects associated with its runtime -
>> does anyone
>> have any thoughts on this?
>>
>> I also think OPENEJB-525 (
>> https://issues.apache.org/jira/browse/OPENEJB-525) can be closed as
>> the
>> plugin is now built with Maven.
>>
>
> Yes, these issues should be closed.
> Also, I think David just implemented the DependsOn functionality.
> What do
> you think about generating a dependency graph in eclipse? i.e the
> plugin
> could scrape through the EJB's / descriptors and generate this graph
> (which
> could possibly also be modified).
Along those lines what would be really cool is if the tool could add
the @DependsOn automatically for a user.
A singleton needs a @DependsOn declaration only when referring to
(invoking) another singleton in either its @PostConstruct or
@PreDestroy method. I don't know if it's possible, but if there was
some way spot that and add the @DependsOn for them, that'd be really
cool.
As an example, the bean has this:
@Singleton
@Startup
public class RedBean {
@EJB(beanName="BlueBean")
private BlueLocal blue
@PostConstruct
public void startup() {
}
}
and all is fine, but when they add this to the @PostConstruct method...
@PostConstruct
public void startup() {
blue.doSomeWork();
}
At that point you need to add the @DependsOn like so:
@Singleton
@Startup
@DependsOn("BlueBean")
public class RedBean {
...
}
Don't know if that's possible, but would be cool.
-David
Re: OpenEJB Eclipse Plugin update
Posted by Karan Malhi <ka...@gmail.com>.
>
> I think OPENEJB-516 (https://issues.apache.org/jira/browse/OPENEJB-516)
> can be closed, as the plugin will now add the javaee-api and openejb-client
> JARs to the classpath of projects associated with its runtime - does anyone
> have any thoughts on this?
>
> I also think OPENEJB-525 (
> https://issues.apache.org/jira/browse/OPENEJB-525) can be closed as the
> plugin is now built with Maven.
>
Yes, these issues should be closed.
Also, I think David just implemented the DependsOn functionality. What do
you think about generating a dependency graph in eclipse? i.e the plugin
could scrape through the EJB's / descriptors and generate this graph (which
could possibly also be modified).
--
Karan Singh Malhi
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Thanks guys. I've added the following issues:
OPENEJB-882 - Support deployment of EAR projects
OPENEJB-883 - Support generation of EJB 3 Entity Manager code
OPENEJB-884 - Drag - and - drop dependency injection
OPENEJB-885 - support weblogic/websphere deployment descriptors for
generating annotations
OPENEJB-886 - Graphical view for editing openejb-jar.xml
OPENEJB-887 - (BUG) EJB port selection makes no difference
I'll close the original issue (OPENEJB-674).
I think OPENEJB-516 (https://issues.apache.org/jira/browse/OPENEJB-516)
can be closed, as the plugin will now add the javaee-api and
openejb-client JARs to the classpath of projects associated with its
runtime - does anyone have any thoughts on this?
I also think OPENEJB-525
(https://issues.apache.org/jira/browse/OPENEJB-525) can be closed as the
plugin is now built with Maven.
Jon
David Blevins wrote:
>
> On Aug 6, 2008, at 7:10 AM, Karan Malhi wrote:
>
>>>
>>> Personally I feel more inclined to close OPENEJB-674 and open new
>>> issues
>>> for the new features.
>>>
>> Funny, when I was drafting the previous email, I had written almost
>> the same
>> sentence as above. Here is what I had written:-
>>
>> Personally I would prefer to close OPENEJB-674 and open new issues
>> for the
>> new features
>>
>> I would definitely prefer the above as this would also help us during a
>> release.
>
> I agree with you both. Time to start creating new the issues.
>
> -David
>
Re: OpenEJB Eclipse Plugin update
Posted by David Blevins <da...@visi.com>.
On Aug 6, 2008, at 7:10 AM, Karan Malhi wrote:
>>
>> Personally I feel more inclined to close OPENEJB-674 and open new
>> issues
>> for the new features.
>>
> Funny, when I was drafting the previous email, I had written almost
> the same
> sentence as above. Here is what I had written:-
>
> Personally I would prefer to close OPENEJB-674 and open new issues
> for the
> new features
>
> I would definitely prefer the above as this would also help us
> during a
> release.
I agree with you both. Time to start creating new the issues.
-David
Re: OpenEJB Eclipse Plugin update
Posted by Karan Malhi <ka...@gmail.com>.
>
> Personally I feel more inclined to close OPENEJB-674 and open new issues
> for the new features.
>
Funny, when I was drafting the previous email, I had written almost the same
sentence as above. Here is what I had written:-
Personally I would prefer to close OPENEJB-674 and open new issues for the
new features
I would definitely prefer the above as this would also help us during a
release.
--
Karan Singh Malhi
Re: OpenEJB Eclipse Plugin update
Posted by Jonathan Gallimore <jo...@gmail.com>.
Karan Malhi wrote:
> Jonathan,
>
> This is really impressive.
>
Thanks :)
>> I was also thinking it might perhaps be a good idea to either close
>> OPENEJB-674 and open new issues for these tasks or to add subtasks to
>> OPENEJB-674 - anyone got any thoughts on this?
>>
>>
> I agree
>
>
Do you have any preference on which way to go? Personally I feel more
inclined to close OPENEJB-674 and open new issues for the new features.
Cheers
Jon
Re: OpenEJB Eclipse Plugin update
Posted by Karan Malhi <ka...@gmail.com>.
Jonathan,
This is really impressive.
>
>
> I was also thinking it might perhaps be a good idea to either close
> OPENEJB-674 and open new issues for these tasks or to add subtasks to
> OPENEJB-674 - anyone got any thoughts on this?
>
I agree
--
Karan Singh Malhi