is there a method in the FieldTagsHandler class to determine if the field
being processed is actually from the class's parent class?
thanks.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something
hello.
just wondering if there's a method exists in the FieldTagsHandler class (or
using another approach) to determine if the field being processed is
actually from the class's parent class?
thanks.
---
This SF.NET email is sponsored by:
congratulations! :)
At 09:02 03/01/15 -0800, you wrote:
Hi all,
german montly JavaMagazin with my article about
xdoclet
will hit stores tomorrow. I already received feedback
and questions about xdoclet from this article.
---
This SF.NET em
happy new year everyone!
quick question:
if a module needs to create and use a custom class that extends
xdoclet.core.build.classes.xdoclet.tagshandler.FieldTagsHandler (i.e.
FieldTagsHandlerCustom), where should it go and how does one tell xdoclet
to use the custom class when executing the mo
hello.
currently, the hibernate task is generating the class mapping files
(XXX.hbm.xml) to my project's "config_generated" directory. if there are
no previously-generated hibernate mapping files in the directory, the task
works fine. however, if the task is spewing out the following exceptio
At 16:49 02/12/27 +1100, you wrote:
> is there any way to get it to generate the mapping file with a fixed
name
> (i.e. "hibernate-mapping.xml") in the top level of the output
directory?
H its considered good form to name the mapping document for
foo.bar.Baz as foo/bar/Baz.hbm.xml. That appro
is there any way to get it to generate the mapping file with a fixed name
(i.e. "hibernate-mapping.xml") in the top level of the output directory?
i currently have 1 class that i'm using as a test ("User") with the
hibernate task and the mapping file that is being generated is:
User_Hibernate.
are you using an ejb task-generated VO? if so, why? are you able to just
create a simple java class and add hibernate and struts tags? sorry, i
don't understand the dependency on ejb VO's...
what you're doing sounds pretty cool. are you doing this to try to nearly
automate the process of du
assword="${db.password}"
url="${db.url}"
generateTables="true"
/>
however, hibernate and the others wouldn't need the "xmlMapping" attribute,
so i would need to redesign this a little..
i've nearly finished a new castor subtask for xdoclet and part of it
actually makes a connection to the database and creates the tables for you.
however, i'm getting the below error when i execute the subtask, even
though the (postgresql) jdbc driver is on the classpath:
[ejbdoclet] (XDocletMai
just wondering why this move was made?
i'm using xdoclet on several projects and rather than copying all the
xdoc .jars to each project's lib directory, i'm using a build.properties
file to store references to each module.jar located in the cvs-downloaded
target/lib directory. now that the ver
thanks andrew.
i will try cvs updating again. :)
At 13:52 02/12/18 +, you wrote:
Looks like a CVS problem to me :-)
The file wasn't being updated by someone else at the same time, was it?
I've had occasional problems like this in the past. Usually, if I leave
it a while and try again i
anyone know why this is happening?
cvs [update aborted]: cannot rename file .new.XDocletTagSupport.java to
XDocletTagSupport.java: File exists
thanks.
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Lear
what type of i18n support do you mean?
if related to .properties files, i believe that apache's ExtendedProperties
class in the commons project supports i18n:
http://jakarta.apache.org/commons/sandbox/configuration/index.html
At 15:07 02/12/01 -0800, you wrote:
Hi guys,
A little question: sh
i've been working on it, but xdoclet is undergoing some major changes from
version 1.2 to 2, namely switching to velocity as the templating engine.
as such, i've been hesistant to keep working on a version that will be
scrapped, and waiting for word on the stability of xdoclet2 to begin
working
just wondering how stable the core of xdoclet2 is currently? is it at the
point where we can start writing velocity templates and generate code? i
was working on castor for 1.2, but was working on other things for a while
and was advised to wait until development for xdoclet2 started...
since
just a suggestion, but could each module in xdoclet (i.e. jboss) have its
own cvs module so that each respective group (i.e. jboss group) will have
control over it, manage it, yet it still integrate with and keep up-to-date
with the core xdoclet?
At 17:13 02/09/19 -0400, you wrote:
>+1
>
>Th
thank you for your reply andrew.
the new architecture is very nice!
thanks again.
At 00:02 02/07/01 +0100, you wrote:
>A wise old hermit known only as tek1 <[EMAIL PROTECTED]> once said:
> > questions about latest dev/cvs release
> > -
perhaps there is an opportunity for all 3 projects (middlegen, dods, and
jboss gui) to work together? they all seem to have definite benefits and
provide very useful and different views of the underlying code in an ejb
system. furthermore, with xdoclet at the core to generate all the
ejb-rela
19 matches
Mail list logo
