Home » Language IDEs » ServerTools (WTP) » the xdoclet integration needs serious re-factoring or at least enhancement
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184614 is a reply to message #184598] |
Wed, 13 December 2006 17:16   |
Eclipse User |
|
|
|
Originally posted by: sharper3.austin.dot.rr.dot.com
Ulf,
Have you looked in to JBoss's "JBossIDE-Core" package? The way I read it, you
can download that package separately and add it to a WTP installation. The
Core package says it contains the JBoss XDoclet, Packaging, and J2EE Wizards.
I agree about the JBoss XDoclet package, it is very nice. And I have used the
Packaging as well.
You can find the download here:
http://labs.jboss.com/portal/jbosside/download/index.html
I dug around through some of the forums and found a little further discussion,
but not a whole lot.
I'd be interested to hear if other people have done this successfully.
scott
In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
<ulf.gohde@banctec.co.uk> wrote:
>There are several flaws with the current xdoclet integration
>
>1. there is no way to define the memory settings for ant. The xdoclet
>generation is invoked from within eclipse in separate jvm, so giving eclipse
>more memory does not help. For the amount of beans we have in our product we
>are always running out of memory when running xdoclet with the the standard
>memory. ANT_OPTS seems to be completely ignored.
>
>2. I always thought the way the JBoss plugin works is very good. The
>possibility to configure any xdoclet aspect is very nice and the fact that
>you end up with an xdoclet ant script per project is a clean approach. And
>it also enables me get around the memory issue. I just need to configure my
>own ant task with a separate jvm and a -Xmx setting.
>WTP is also generating an xdoclet build file but not per project. It is in
><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo clet\
>tempAnt.xml
>and includes a property file that contains project specific paths. That
>indicates that these files are re-generated every time I run xdoclet -
>unless you can have only one ejbmodule per workspace which I doubt. What was
>the reasoning behind that?
>
>3. the generated xdoclet build script contains xdoclet.force=true which
>means everything gets regenerated ignoring timestamps. That might be ok for
>small projects, but we have dozens of EJBs. I am not complaining about build
>times, because we are not constantly changing DD relevant things, but it is
>a complete nightmare from a CVS point-of-view. If I change one interface and
>run xdoclet, CVS is flagging several hundred files as changed instead of
>just 3-5. Changing the property to false is obviously an option, but the
>fact that the build file seems to be a temporary one makes it very nasty. I
>would expect this as an option in the xdoclet configuration.
>
>I guess my main criticism is why everyone is trying to invent the wheel
>again and again instead of at least looking into existing solutions (in this
>case it is the WTP team, but there are lots of other examples not only
>within eclipse for it).
>The server and publish part of WTP is nice. I like that. But the xdoclet
>part is far worse than the solution provided by the jboss plugin.
>
>Of course just my opinion... But it definitely is a nightmare for us and is
>preventing us to go with WTP.
>
>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184658 is a reply to message #184614] |
Thu, 14 December 2006 09:34 |
 Ulf Gohde
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
I am running the JBoss plugin (the newest beta2) together with WTP.
The issues I found so far:
1. The jboss 3.2 server adapter that comes with the JBoss plugin seems to
have re-publish problems with WTP ear projects. I haven't tried 4.0, but
most of our customers are still on 3.2.7.
2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to work
properly with jboss 3.2.7
Until now we basically used the JBoss plugin and have our own ant scripts to
do all the packaging and deployment. Seems we have to stick with that for a
while....
"Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
news:elpch5$gmt$2@utils.eclipse.org...
> Ulf,
>
> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read it,
> you
> can download that package separately and add it to a WTP installation.
> The
> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
> Wizards.
> I agree about the JBoss XDoclet package, it is very nice. And I have used
> the
> Packaging as well.
>
> You can find the download here:
> http://labs.jboss.com/portal/jbosside/download/index.html
>
> I dug around through some of the forums and found a little further
> discussion,
> but not a whole lot.
>
> I'd be interested to hear if other people have done this successfully.
>
>
> scott
>
> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
> <ulf.gohde@banctec.co.uk> wrote:
>>There are several flaws with the current xdoclet integration
>>
>>1. there is no way to define the memory settings for ant. The xdoclet
>>generation is invoked from within eclipse in separate jvm, so giving
>>eclipse
>>more memory does not help. For the amount of beans we have in our product
>>we
>>are always running out of memory when running xdoclet with the the
>>standard
>>memory. ANT_OPTS seems to be completely ignored.
>>
>>2. I always thought the way the JBoss plugin works is very good. The
>>possibility to configure any xdoclet aspect is very nice and the fact that
>>you end up with an xdoclet ant script per project is a clean approach. And
>>it also enables me get around the memory issue. I just need to configure
>>my
>>own ant task with a separate jvm and a -Xmx setting.
>>WTP is also generating an xdoclet build file but not per project. It is in
>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo clet\
>>tempAnt.xml
>>and includes a property file that contains project specific paths. That
>>indicates that these files are re-generated every time I run xdoclet -
>>unless you can have only one ejbmodule per workspace which I doubt. What
>>was
>>the reasoning behind that?
>>
>>3. the generated xdoclet build script contains xdoclet.force=true which
>>means everything gets regenerated ignoring timestamps. That might be ok
>>for
>>small projects, but we have dozens of EJBs. I am not complaining about
>>build
>>times, because we are not constantly changing DD relevant things, but it
>>is
>>a complete nightmare from a CVS point-of-view. If I change one interface
>>and
>>run xdoclet, CVS is flagging several hundred files as changed instead of
>>just 3-5. Changing the property to false is obviously an option, but the
>>fact that the build file seems to be a temporary one makes it very nasty.
>>I
>>would expect this as an option in the xdoclet configuration.
>>
>>I guess my main criticism is why everyone is trying to invent the wheel
>>again and again instead of at least looking into existing solutions (in
>>this
>>case it is the WTP team, but there are lots of other examples not only
>>within eclipse for it).
>>The server and publish part of WTP is nice. I like that. But the xdoclet
>>part is far worse than the solution provided by the jboss plugin.
>>
>>Of course just my opinion... But it definitely is a nightmare for us and
>>is
>>preventing us to go with WTP.
>>
>>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184665 is a reply to message #184658] |
Thu, 14 December 2006 10:20 |
Ulf Gohde
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Scott,
so, to answer your question using the jboss plugin in combination WTP seems
to be ok apart from the plugin being beta and therefore probably not
completely bug free.
But instead of mixing two J2EE development plugins it would be nice to use
one instead. Especially because our product runs against several AppServer
(JBoss, Weblogic, Websphere) and what I have seen so far in WTP is nice. The
only thing that is a mess is the xdoclet part.
"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
news:elr5lb$7pv$1@utils.eclipse.org...
>I am running the JBoss plugin (the newest beta2) together with WTP.
>
> The issues I found so far:
>
> 1. The jboss 3.2 server adapter that comes with the JBoss plugin seems to
> have re-publish problems with WTP ear projects. I haven't tried 4.0, but
> most of our customers are still on 3.2.7.
> 2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to work
> properly with jboss 3.2.7
>
> Until now we basically used the JBoss plugin and have our own ant scripts
> to do all the packaging and deployment. Seems we have to stick with that
> for a while....
>
>
>
> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
> news:elpch5$gmt$2@utils.eclipse.org...
>> Ulf,
>>
>> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read
>> it, you
>> can download that package separately and add it to a WTP installation.
>> The
>> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
>> Wizards.
>> I agree about the JBoss XDoclet package, it is very nice. And I have
>> used the
>> Packaging as well.
>>
>> You can find the download here:
>> http://labs.jboss.com/portal/jbosside/download/index.html
>>
>> I dug around through some of the forums and found a little further
>> discussion,
>> but not a whole lot.
>>
>> I'd be interested to hear if other people have done this successfully.
>>
>>
>> scott
>>
>> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
>> <ulf.gohde@banctec.co.uk> wrote:
>>>There are several flaws with the current xdoclet integration
>>>
>>>1. there is no way to define the memory settings for ant. The xdoclet
>>>generation is invoked from within eclipse in separate jvm, so giving
>>>eclipse
>>>more memory does not help. For the amount of beans we have in our product
>>>we
>>>are always running out of memory when running xdoclet with the the
>>>standard
>>>memory. ANT_OPTS seems to be completely ignored.
>>>
>>>2. I always thought the way the JBoss plugin works is very good. The
>>>possibility to configure any xdoclet aspect is very nice and the fact
>>>that
>>>you end up with an xdoclet ant script per project is a clean approach.
>>>And
>>>it also enables me get around the memory issue. I just need to configure
>>>my
>>>own ant task with a separate jvm and a -Xmx setting.
>>>WTP is also generating an xdoclet build file but not per project. It is
>>>in
>>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo clet\
>>>tempAnt.xml
>>>and includes a property file that contains project specific paths. That
>>>indicates that these files are re-generated every time I run xdoclet -
>>>unless you can have only one ejbmodule per workspace which I doubt. What
>>>was
>>>the reasoning behind that?
>>>
>>>3. the generated xdoclet build script contains xdoclet.force=true which
>>>means everything gets regenerated ignoring timestamps. That might be ok
>>>for
>>>small projects, but we have dozens of EJBs. I am not complaining about
>>>build
>>>times, because we are not constantly changing DD relevant things, but it
>>>is
>>>a complete nightmare from a CVS point-of-view. If I change one interface
>>>and
>>>run xdoclet, CVS is flagging several hundred files as changed instead of
>>>just 3-5. Changing the property to false is obviously an option, but the
>>>fact that the build file seems to be a temporary one makes it very nasty.
>>>I
>>>would expect this as an option in the xdoclet configuration.
>>>
>>>I guess my main criticism is why everyone is trying to invent the wheel
>>>again and again instead of at least looking into existing solutions (in
>>>this
>>>case it is the WTP team, but there are lots of other examples not only
>>>within eclipse for it).
>>>The server and publish part of WTP is nice. I like that. But the xdoclet
>>>part is far worse than the solution provided by the jboss plugin.
>>>
>>>Of course just my opinion... But it definitely is a nightmare for us and
>>>is
>>>preventing us to go with WTP.
>>>
>>>
>
>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184783 is a reply to message #184665] |
Thu, 14 December 2006 16:05 |
| Eclipse User |
|
|
|
Originally posted by: sharper3.austin.dot.rr.dot.com
Well, *for the time being* we are focused on Tomcat. I think WTP does
everything we need, except for the xdoclet part.
As an aside, my install of the all-in-one WTP package (1.5.2) gives me an
error that the xdoclet-1.2.1.jar library can't be found. Do you know anything
about that? So basically, as is, I can't do *any* xdoclet from WTP until I
get worked around that. It was suggested in a different thread that I just
download that jar from sourceforge and put it out in my environment somewhere,
but that just doesn't seem like the clean way to do it.
So I have been considering the JBoss plugin, mainly for the xdoclet stuff. I
agree that the packaging and all can be handled pretty nicely from ant.
Can you install just the xdoclet part of the JBoss plugin? Or do you get it
all?
Of course, the "for the time being" caveat above is admittedly short-sighted.
So I agree with you that a single integrated tool would be best.
In article <elr8b4$tar$1@utils.eclipse.org>, "Ulf Gohde"
<ulf.gohde@banctec.co.uk> wrote:
>Scott,
>
>so, to answer your question using the jboss plugin in combination WTP seems
>to be ok apart from the plugin being beta and therefore probably not
>completely bug free.
>
>But instead of mixing two J2EE development plugins it would be nice to use
>one instead. Especially because our product runs against several AppServer
>(JBoss, Weblogic, Websphere) and what I have seen so far in WTP is nice. The
>only thing that is a mess is the xdoclet part.
>
>
>"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
>news:elr5lb$7pv$1@utils.eclipse.org...
>>I am running the JBoss plugin (the newest beta2) together with WTP.
>>
>> The issues I found so far:
>>
>> 1. The jboss 3.2 server adapter that comes with the JBoss plugin seems to
>> have re-publish problems with WTP ear projects. I haven't tried 4.0, but
>> most of our customers are still on 3.2.7.
>> 2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to work
>> properly with jboss 3.2.7
>>
>> Until now we basically used the JBoss plugin and have our own ant scripts
>> to do all the packaging and deployment. Seems we have to stick with that
>> for a while....
>>
>>
>>
>> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
>> news:elpch5$gmt$2@utils.eclipse.org...
>>> Ulf,
>>>
>>> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read
>>> it, you
>>> can download that package separately and add it to a WTP installation.
>>> The
>>> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
>>> Wizards.
>>> I agree about the JBoss XDoclet package, it is very nice. And I have
>>> used the
>>> Packaging as well.
>>>
>>> You can find the download here:
>>> http://labs.jboss.com/portal/jbosside/download/index.html
>>>
>>> I dug around through some of the forums and found a little further
>>> discussion,
>>> but not a whole lot.
>>>
>>> I'd be interested to hear if other people have done this successfully.
>>>
>>>
>>> scott
>>>
>>> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
>>> <ulf.gohde@banctec.co.uk> wrote:
>>>>There are several flaws with the current xdoclet integration
>>>>
>>>>1. there is no way to define the memory settings for ant. The xdoclet
>>>>generation is invoked from within eclipse in separate jvm, so giving
>>>>eclipse
>>>>more memory does not help. For the amount of beans we have in our product
>>>>we
>>>>are always running out of memory when running xdoclet with the the
>>>>standard
>>>>memory. ANT_OPTS seems to be completely ignored.
>>>>
>>>>2. I always thought the way the JBoss plugin works is very good. The
>>>>possibility to configure any xdoclet aspect is very nice and the fact
>>>>that
>>>>you end up with an xdoclet ant script per project is a clean approach.
>>>>And
>>>>it also enables me get around the memory issue. I just need to configure
>>>>my
>>>>own ant task with a separate jvm and a -Xmx setting.
>>>>WTP is also generating an xdoclet build file but not per project. It is
>>>>in
>>>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo cl
>et\
>>>>tempAnt.xml
>>>>and includes a property file that contains project specific paths. That
>>>>indicates that these files are re-generated every time I run xdoclet -
>>>>unless you can have only one ejbmodule per workspace which I doubt. What
>>>>was
>>>>the reasoning behind that?
>>>>
>>>>3. the generated xdoclet build script contains xdoclet.force=true which
>>>>means everything gets regenerated ignoring timestamps. That might be ok
>>>>for
>>>>small projects, but we have dozens of EJBs. I am not complaining about
>>>>build
>>>>times, because we are not constantly changing DD relevant things, but it
>>>>is
>>>>a complete nightmare from a CVS point-of-view. If I change one interface
>>>>and
>>>>run xdoclet, CVS is flagging several hundred files as changed instead of
>>>>just 3-5. Changing the property to false is obviously an option, but the
>>>>fact that the build file seems to be a temporary one makes it very nasty.
>>>>I
>>>>would expect this as an option in the xdoclet configuration.
>>>>
>>>>I guess my main criticism is why everyone is trying to invent the wheel
>>>>again and again instead of at least looking into existing solutions (in
>>>>this
>>>>case it is the WTP team, but there are lots of other examples not only
>>>>within eclipse for it).
>>>>The server and publish part of WTP is nice. I like that. But the xdoclet
>>>>part is far worse than the solution provided by the jboss plugin.
>>>>
>>>>Of course just my opinion... But it definitely is a nightmare for us and
>>>>is
>>>>preventing us to go with WTP.
>>>>
>>>>
>>
>>
>
>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184933 is a reply to message #184783] |
Fri, 15 December 2006 11:40 |
Ulf Gohde
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
I don't think you can just download the xdoclet part. But that shouldn't be
a problem. Just don't use all the other stuff.
I used the eclipse update mechanism to download (download site:
http://download.jboss.org/jbosside/updates/development)
JBoss Eclipse IDE 2.0.0.Beta2
JBossIDE JBossAS Adapter Feature 1.0.0.Beta2
org.jboss.ide.eclipse.ejb3.feature 1.0.0.Beta2 (I don't think that that is
necessary though)
one of these (I think the last one) requirese JBoss AOP
JBoss AOP Tools 1.2.0.Beta2
"Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
news:elrsp2$e26$1@utils.eclipse.org...
> Well, *for the time being* we are focused on Tomcat. I think WTP does
> everything we need, except for the xdoclet part.
>
> As an aside, my install of the all-in-one WTP package (1.5.2) gives me an
> error that the xdoclet-1.2.1.jar library can't be found. Do you know
> anything
> about that? So basically, as is, I can't do *any* xdoclet from WTP until
> I
> get worked around that. It was suggested in a different thread that I
> just
> download that jar from sourceforge and put it out in my environment
> somewhere,
> but that just doesn't seem like the clean way to do it.
>
> So I have been considering the JBoss plugin, mainly for the xdoclet stuff.
> I
> agree that the packaging and all can be handled pretty nicely from ant.
>
> Can you install just the xdoclet part of the JBoss plugin? Or do you get
> it
> all?
>
> Of course, the "for the time being" caveat above is admittedly
> short-sighted.
> So I agree with you that a single integrated tool would be best.
>
>
> In article <elr8b4$tar$1@utils.eclipse.org>, "Ulf Gohde"
> <ulf.gohde@banctec.co.uk> wrote:
>>Scott,
>>
>>so, to answer your question using the jboss plugin in combination WTP
>>seems
>>to be ok apart from the plugin being beta and therefore probably not
>>completely bug free.
>>
>>But instead of mixing two J2EE development plugins it would be nice to use
>>one instead. Especially because our product runs against several AppServer
>>(JBoss, Weblogic, Websphere) and what I have seen so far in WTP is nice.
>>The
>>only thing that is a mess is the xdoclet part.
>>
>>
>>"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
>>news:elr5lb$7pv$1@utils.eclipse.org...
>>>I am running the JBoss plugin (the newest beta2) together with WTP.
>>>
>>> The issues I found so far:
>>>
>>> 1. The jboss 3.2 server adapter that comes with the JBoss plugin seems
>>> to
>>> have re-publish problems with WTP ear projects. I haven't tried 4.0, but
>>> most of our customers are still on 3.2.7.
>>> 2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to
>>> work
>>> properly with jboss 3.2.7
>>>
>>> Until now we basically used the JBoss plugin and have our own ant
>>> scripts
>>> to do all the packaging and deployment. Seems we have to stick with that
>>> for a while....
>>>
>>>
>>>
>>> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
>>> news:elpch5$gmt$2@utils.eclipse.org...
>>>> Ulf,
>>>>
>>>> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read
>>>> it, you
>>>> can download that package separately and add it to a WTP installation.
>>>> The
>>>> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
>>>> Wizards.
>>>> I agree about the JBoss XDoclet package, it is very nice. And I have
>>>> used the
>>>> Packaging as well.
>>>>
>>>> You can find the download here:
>>>> http://labs.jboss.com/portal/jbosside/download/index.html
>>>>
>>>> I dug around through some of the forums and found a little further
>>>> discussion,
>>>> but not a whole lot.
>>>>
>>>> I'd be interested to hear if other people have done this successfully.
>>>>
>>>>
>>>> scott
>>>>
>>>> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
>>>> <ulf.gohde@banctec.co.uk> wrote:
>>>>>There are several flaws with the current xdoclet integration
>>>>>
>>>>>1. there is no way to define the memory settings for ant. The xdoclet
>>>>>generation is invoked from within eclipse in separate jvm, so giving
>>>>>eclipse
>>>>>more memory does not help. For the amount of beans we have in our
>>>>>product
>>>>>we
>>>>>are always running out of memory when running xdoclet with the the
>>>>>standard
>>>>>memory. ANT_OPTS seems to be completely ignored.
>>>>>
>>>>>2. I always thought the way the JBoss plugin works is very good. The
>>>>>possibility to configure any xdoclet aspect is very nice and the fact
>>>>>that
>>>>>you end up with an xdoclet ant script per project is a clean approach.
>>>>>And
>>>>>it also enables me get around the memory issue. I just need to
>>>>>configure
>>>>>my
>>>>>own ant task with a separate jvm and a -Xmx setting.
>>>>>WTP is also generating an xdoclet build file but not per project. It is
>>>>>in
>>>>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo cl
>>et\
>>>>>tempAnt.xml
>>>>>and includes a property file that contains project specific paths. That
>>>>>indicates that these files are re-generated every time I run xdoclet -
>>>>>unless you can have only one ejbmodule per workspace which I doubt.
>>>>>What
>>>>>was
>>>>>the reasoning behind that?
>>>>>
>>>>>3. the generated xdoclet build script contains xdoclet.force=true which
>>>>>means everything gets regenerated ignoring timestamps. That might be ok
>>>>>for
>>>>>small projects, but we have dozens of EJBs. I am not complaining about
>>>>>build
>>>>>times, because we are not constantly changing DD relevant things, but
>>>>>it
>>>>>is
>>>>>a complete nightmare from a CVS point-of-view. If I change one
>>>>>interface
>>>>>and
>>>>>run xdoclet, CVS is flagging several hundred files as changed instead
>>>>>of
>>>>>just 3-5. Changing the property to false is obviously an option, but
>>>>>the
>>>>>fact that the build file seems to be a temporary one makes it very
>>>>>nasty.
>>>>>I
>>>>>would expect this as an option in the xdoclet configuration.
>>>>>
>>>>>I guess my main criticism is why everyone is trying to invent the wheel
>>>>>again and again instead of at least looking into existing solutions (in
>>>>>this
>>>>>case it is the WTP team, but there are lots of other examples not only
>>>>>within eclipse for it).
>>>>>The server and publish part of WTP is nice. I like that. But the
>>>>>xdoclet
>>>>>part is far worse than the solution provided by the jboss plugin.
>>>>>
>>>>>Of course just my opinion... But it definitely is a nightmare for us
>>>>>and
>>>>>is
>>>>>preventing us to go with WTP.
>>>>>
>>>>>
>>>
>>>
>>
>>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184942 is a reply to message #184783] |
Fri, 15 December 2006 11:46 |
Ulf Gohde
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
to answer your other question: No, I don't know anything about
xdoclet-1.2.1.jar missing.
WST without JBoss plugin worked for me (from Callisto). But I was alwasy
using xdoclet-1.2.3.
"Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
news:elrsp2$e26$1@utils.eclipse.org...
> Well, *for the time being* we are focused on Tomcat. I think WTP does
> everything we need, except for the xdoclet part.
>
> As an aside, my install of the all-in-one WTP package (1.5.2) gives me an
> error that the xdoclet-1.2.1.jar library can't be found. Do you know
> anything
> about that? So basically, as is, I can't do *any* xdoclet from WTP until
> I
> get worked around that. It was suggested in a different thread that I
> just
> download that jar from sourceforge and put it out in my environment
> somewhere,
> but that just doesn't seem like the clean way to do it.
>
> So I have been considering the JBoss plugin, mainly for the xdoclet stuff.
> I
> agree that the packaging and all can be handled pretty nicely from ant.
>
> Can you install just the xdoclet part of the JBoss plugin? Or do you get
> it
> all?
>
> Of course, the "for the time being" caveat above is admittedly
> short-sighted.
> So I agree with you that a single integrated tool would be best.
>
>
> In article <elr8b4$tar$1@utils.eclipse.org>, "Ulf Gohde"
> <ulf.gohde@banctec.co.uk> wrote:
>>Scott,
>>
>>so, to answer your question using the jboss plugin in combination WTP
>>seems
>>to be ok apart from the plugin being beta and therefore probably not
>>completely bug free.
>>
>>But instead of mixing two J2EE development plugins it would be nice to use
>>one instead. Especially because our product runs against several AppServer
>>(JBoss, Weblogic, Websphere) and what I have seen so far in WTP is nice.
>>The
>>only thing that is a mess is the xdoclet part.
>>
>>
>>"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
>>news:elr5lb$7pv$1@utils.eclipse.org...
>>>I am running the JBoss plugin (the newest beta2) together with WTP.
>>>
>>> The issues I found so far:
>>>
>>> 1. The jboss 3.2 server adapter that comes with the JBoss plugin seems
>>> to
>>> have re-publish problems with WTP ear projects. I haven't tried 4.0, but
>>> most of our customers are still on 3.2.7.
>>> 2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to
>>> work
>>> properly with jboss 3.2.7
>>>
>>> Until now we basically used the JBoss plugin and have our own ant
>>> scripts
>>> to do all the packaging and deployment. Seems we have to stick with that
>>> for a while....
>>>
>>>
>>>
>>> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
>>> news:elpch5$gmt$2@utils.eclipse.org...
>>>> Ulf,
>>>>
>>>> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read
>>>> it, you
>>>> can download that package separately and add it to a WTP installation.
>>>> The
>>>> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
>>>> Wizards.
>>>> I agree about the JBoss XDoclet package, it is very nice. And I have
>>>> used the
>>>> Packaging as well.
>>>>
>>>> You can find the download here:
>>>> http://labs.jboss.com/portal/jbosside/download/index.html
>>>>
>>>> I dug around through some of the forums and found a little further
>>>> discussion,
>>>> but not a whole lot.
>>>>
>>>> I'd be interested to hear if other people have done this successfully.
>>>>
>>>>
>>>> scott
>>>>
>>>> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
>>>> <ulf.gohde@banctec.co.uk> wrote:
>>>>>There are several flaws with the current xdoclet integration
>>>>>
>>>>>1. there is no way to define the memory settings for ant. The xdoclet
>>>>>generation is invoked from within eclipse in separate jvm, so giving
>>>>>eclipse
>>>>>more memory does not help. For the amount of beans we have in our
>>>>>product
>>>>>we
>>>>>are always running out of memory when running xdoclet with the the
>>>>>standard
>>>>>memory. ANT_OPTS seems to be completely ignored.
>>>>>
>>>>>2. I always thought the way the JBoss plugin works is very good. The
>>>>>possibility to configure any xdoclet aspect is very nice and the fact
>>>>>that
>>>>>you end up with an xdoclet ant script per project is a clean approach.
>>>>>And
>>>>>it also enables me get around the memory issue. I just need to
>>>>>configure
>>>>>my
>>>>>own ant task with a separate jvm and a -Xmx setting.
>>>>>WTP is also generating an xdoclet build file but not per project. It is
>>>>>in
>>>>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo cl
>>et\
>>>>>tempAnt.xml
>>>>>and includes a property file that contains project specific paths. That
>>>>>indicates that these files are re-generated every time I run xdoclet -
>>>>>unless you can have only one ejbmodule per workspace which I doubt.
>>>>>What
>>>>>was
>>>>>the reasoning behind that?
>>>>>
>>>>>3. the generated xdoclet build script contains xdoclet.force=true which
>>>>>means everything gets regenerated ignoring timestamps. That might be ok
>>>>>for
>>>>>small projects, but we have dozens of EJBs. I am not complaining about
>>>>>build
>>>>>times, because we are not constantly changing DD relevant things, but
>>>>>it
>>>>>is
>>>>>a complete nightmare from a CVS point-of-view. If I change one
>>>>>interface
>>>>>and
>>>>>run xdoclet, CVS is flagging several hundred files as changed instead
>>>>>of
>>>>>just 3-5. Changing the property to false is obviously an option, but
>>>>>the
>>>>>fact that the build file seems to be a temporary one makes it very
>>>>>nasty.
>>>>>I
>>>>>would expect this as an option in the xdoclet configuration.
>>>>>
>>>>>I guess my main criticism is why everyone is trying to invent the wheel
>>>>>again and again instead of at least looking into existing solutions (in
>>>>>this
>>>>>case it is the WTP team, but there are lots of other examples not only
>>>>>within eclipse for it).
>>>>>The server and publish part of WTP is nice. I like that. But the
>>>>>xdoclet
>>>>>part is far worse than the solution provided by the jboss plugin.
>>>>>
>>>>>Of course just my opinion... But it definitely is a nightmare for us
>>>>>and
>>>>>is
>>>>>preventing us to go with WTP.
>>>>>
>>>>>
>>>
>>>
>>
>>
|
|
|
| Re: the xdoclet integration needs serious re-factoring or at least enhancement [message #184998 is a reply to message #184942] |
Fri, 15 December 2006 14:50 |
Ulf Gohde
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
err... WTP of course, not WST
"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
news:elu1o9$5rk$1@utils.eclipse.org...
> to answer your other question: No, I don't know anything about
> xdoclet-1.2.1.jar missing.
>
> WST without JBoss plugin worked for me (from Callisto). But I was alwasy
> using xdoclet-1.2.3.
>
>
> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
> news:elrsp2$e26$1@utils.eclipse.org...
>> Well, *for the time being* we are focused on Tomcat. I think WTP does
>> everything we need, except for the xdoclet part.
>>
>> As an aside, my install of the all-in-one WTP package (1.5.2) gives me an
>> error that the xdoclet-1.2.1.jar library can't be found. Do you know
>> anything
>> about that? So basically, as is, I can't do *any* xdoclet from WTP until
>> I
>> get worked around that. It was suggested in a different thread that I
>> just
>> download that jar from sourceforge and put it out in my environment
>> somewhere,
>> but that just doesn't seem like the clean way to do it.
>>
>> So I have been considering the JBoss plugin, mainly for the xdoclet
>> stuff. I
>> agree that the packaging and all can be handled pretty nicely from ant.
>>
>> Can you install just the xdoclet part of the JBoss plugin? Or do you get
>> it
>> all?
>>
>> Of course, the "for the time being" caveat above is admittedly
>> short-sighted.
>> So I agree with you that a single integrated tool would be best.
>>
>>
>> In article <elr8b4$tar$1@utils.eclipse.org>, "Ulf Gohde"
>> <ulf.gohde@banctec.co.uk> wrote:
>>>Scott,
>>>
>>>so, to answer your question using the jboss plugin in combination WTP
>>>seems
>>>to be ok apart from the plugin being beta and therefore probably not
>>>completely bug free.
>>>
>>>But instead of mixing two J2EE development plugins it would be nice to
>>>use
>>>one instead. Especially because our product runs against several
>>>AppServer
>>>(JBoss, Weblogic, Websphere) and what I have seen so far in WTP is nice.
>>>The
>>>only thing that is a mess is the xdoclet part.
>>>
>>>
>>>"Ulf Gohde" <ulf.gohde@banctec.co.uk> wrote in message
>>>news:elr5lb$7pv$1@utils.eclipse.org...
>>>>I am running the JBoss plugin (the newest beta2) together with WTP.
>>>>
>>>> The issues I found so far:
>>>>
>>>> 1. The jboss 3.2 server adapter that comes with the JBoss plugin seems
>>>> to
>>>> have re-publish problems with WTP ear projects. I haven't tried 4.0,
>>>> but
>>>> most of our customers are still on 3.2.7.
>>>> 2. The jboss 3.2.3 server adpater that comes with WTP doesn't seem to
>>>> work
>>>> properly with jboss 3.2.7
>>>>
>>>> Until now we basically used the JBoss plugin and have our own ant
>>>> scripts
>>>> to do all the packaging and deployment. Seems we have to stick with
>>>> that
>>>> for a while....
>>>>
>>>>
>>>>
>>>> "Scott Harper" <sharper3@austin.dot.rr.dot.com> wrote in message
>>>> news:elpch5$gmt$2@utils.eclipse.org...
>>>>> Ulf,
>>>>>
>>>>> Have you looked in to JBoss's "JBossIDE-Core" package? The way I read
>>>>> it, you
>>>>> can download that package separately and add it to a WTP installation.
>>>>> The
>>>>> Core package says it contains the JBoss XDoclet, Packaging, and J2EE
>>>>> Wizards.
>>>>> I agree about the JBoss XDoclet package, it is very nice. And I have
>>>>> used the
>>>>> Packaging as well.
>>>>>
>>>>> You can find the download here:
>>>>> http://labs.jboss.com/portal/jbosside/download/index.html
>>>>>
>>>>> I dug around through some of the forums and found a little further
>>>>> discussion,
>>>>> but not a whole lot.
>>>>>
>>>>> I'd be interested to hear if other people have done this successfully.
>>>>>
>>>>>
>>>>> scott
>>>>>
>>>>> In article <elpbd6$1j8$1@utils.eclipse.org>, "Ulf Gohde"
>>>>> <ulf.gohde@banctec.co.uk> wrote:
>>>>>>There are several flaws with the current xdoclet integration
>>>>>>
>>>>>>1. there is no way to define the memory settings for ant. The xdoclet
>>>>>>generation is invoked from within eclipse in separate jvm, so giving
>>>>>>eclipse
>>>>>>more memory does not help. For the amount of beans we have in our
>>>>>>product
>>>>>>we
>>>>>>are always running out of memory when running xdoclet with the the
>>>>>>standard
>>>>>>memory. ANT_OPTS seems to be completely ignored.
>>>>>>
>>>>>>2. I always thought the way the JBoss plugin works is very good. The
>>>>>>possibility to configure any xdoclet aspect is very nice and the fact
>>>>>>that
>>>>>>you end up with an xdoclet ant script per project is a clean approach.
>>>>>>And
>>>>>>it also enables me get around the memory issue. I just need to
>>>>>>configure
>>>>>>my
>>>>>>own ant task with a separate jvm and a -Xmx setting.
>>>>>>WTP is also generating an xdoclet build file but not per project. It
>>>>>>is
>>>>>>in
>>>>>><workspacedir> \.metadata\.plugins\org.eclipse.jst.j2ee.ejb.annotations.xdo cl
>>>et\
>>>>>>tempAnt.xml
>>>>>>and includes a property file that contains project specific paths.
>>>>>>That
>>>>>>indicates that these files are re-generated every time I run xdoclet -
>>>>>>unless you can have only one ejbmodule per workspace which I doubt.
>>>>>>What
>>>>>>was
>>>>>>the reasoning behind that?
>>>>>>
>>>>>>3. the generated xdoclet build script contains xdoclet.force=true
>>>>>>which
>>>>>>means everything gets regenerated ignoring timestamps. That might be
>>>>>>ok
>>>>>>for
>>>>>>small projects, but we have dozens of EJBs. I am not complaining about
>>>>>>build
>>>>>>times, because we are not constantly changing DD relevant things, but
>>>>>>it
>>>>>>is
>>>>>>a complete nightmare from a CVS point-of-view. If I change one
>>>>>>interface
>>>>>>and
>>>>>>run xdoclet, CVS is flagging several hundred files as changed instead
>>>>>>of
>>>>>>just 3-5. Changing the property to false is obviously an option, but
>>>>>>the
>>>>>>fact that the build file seems to be a temporary one makes it very
>>>>>>nasty.
>>>>>>I
>>>>>>would expect this as an option in the xdoclet configuration.
>>>>>>
>>>>>>I guess my main criticism is why everyone is trying to invent the
>>>>>>wheel
>>>>>>again and again instead of at least looking into existing solutions
>>>>>>(in
>>>>>>this
>>>>>>case it is the WTP team, but there are lots of other examples not only
>>>>>>within eclipse for it).
>>>>>>The server and publish part of WTP is nice. I like that. But the
>>>>>>xdoclet
>>>>>>part is far worse than the solution provided by the jboss plugin.
>>>>>>
>>>>>>Of course just my opinion... But it definitely is a nightmare for us
>>>>>>and
>>>>>>is
>>>>>>preventing us to go with WTP.
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 21:12:16 GMT 2024
Powered by FUDForum. Page generated in 0.03455 seconds |
] 
Search
Help
Register
Login
Home
