problem: mvn site
i now have moved the org.appfuse.model.* into my own project and changed
my pom to:
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-${web.framework}</artifactId>
<version>${appfuse.version}</version>
<type>war</type>
<exclusions>
<exclusion>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-data-common</artifactId>
</exclusion>
</exclusions>
</dependency>
but when i run mvn site i get this messege:
Unable to load class declared as <mapping
class="org.appfuse.model.User"/> in the configuration
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.hibernate.MappingException: Unable to load class declared as
<mapping class="org.appfuse.model.User"/> in the co
nfiguration:
at
org.hibernate.cfg.AnnotationConfiguration.parseMappingElement(AnnotationConfiguration.java:545)
at
org.hibernate.cfg.Configuration.parseSessionFactory(Configuration.java:1479)
i can run mvn jetty:run
anyone an idea??
thanks,
tibi
tibi wrote:
> ok than i will take my loss.
>
> tibi
>
>
> Nathan Anderson wrote:
>> Glad to hear you got it working as you wanted. After thinking about
>> this thread a bit I have come to the conclusion that Bryan and Matt
>> are probably right. In most cases it is best as is, but there are
>> exceptions [like yours] where the developer can just go in and make
>> the simple change.
>>
>> Nathan
>>
>> tibi wrote:
>>> ok followed your guid.
>>>
>>> perfect!
>>> its a real plus for appfuse that even changing core classes is
>>> documented well!
>>>
>>> i changed the table name off role to app_role.
>>> org.appfuse.model.Role.java
>>> @Table(name="app_role")
>>> i changed the sample-data.xml in the src/test/resources:
>>> from:
>>> <table name='role'>
>>> to
>>> <table name='app_role'>
>>>
>>> and integration tests work again with app_role as table name.
>>>
>>> thanks,
>>>
>>> off course i would be even more happy if this all was not needed
>>> (and i did not need to fork) and am still hoping that in the next
>>> release the tables ware all named app_* :-)
>>>
>>>
>>> ciao,
>>>
>>> tibi
>>>
>>>
>>>
>>>
>>> Matt Raible wrote:
>>>> If you want to change the table names, you may need to use the
>>>> following and modify the @Table annotation.
>>>>
>>>> http://appfuse.org/display/APF/AppFuse+Core+Classes
>>>>
>>>> It's possible there's a way to override this (ideally in
>>>> hibernate.cfg.xml), but I've never done it, so don't know.
>>>>
>>>> Matt
>>>>
>>>> On 3/15/07, tibi <[EMAIL PROTECTED]> wrote:
>>>>> ok now i do have the problem...
>>>>> i had a role table
>>>>> matt you said something about using hibernate to change the table
>>>>> name
>>>>> for tha appfuse tables?
>>>>>
>>>>> tibi
>>>>>
>>>>> tibi wrote:
>>>>> > nope only app_ for the tables needed
>>>>> > so only the 3 which come with appfuse.
>>>>> >
>>>>> > i have a db with 41 tables with a lot of data. I'm working on
>>>>> making a
>>>>> > report manager on it
>>>>> > luckily no table name corresponds to app_user, role user_role
>>>>> but if
>>>>> > it did i had to rename the tables.
>>>>> > and that is inconvenient
>>>>> >
>>>>> > or use 2 instances and that gets complicated as well. i don't
even
>>>>> > know if appfuse can manage 2 db's.
>>>>> >
>>>>> > i don't see any problem in naming the 3 tables app_user app_role
>>>>> > app_user_role by default.
>>>>> > and I'm not really interesting in roller but i guess they had an
>>>>> idea
>>>>> > to start using roller_
>>>>> > only they didn't do it right.
>>>>> >
>>>>> > tibi
>>>>> >
>>>>> > ps added English spell checking for you guy's ;) should be a bit
>>>>> > better now.
>>>>> >
>>>>> >
>>>>> >
>>>>> > Matt Raible wrote:
>>>>> >> Yes, but are you really going to add the app_ prefix to all the
>>>>> tables
>>>>> >> in your application while you're developing it? The reason
>>>>> I've seen
>>>>> >> this done most of the time is so you can deploy multiple
>>>>> applications
>>>>> >> in one database. Databases are cheap - get a 2nd instance. ;-)
>>>>> >>
>>>>> >> Another reason I don't like is because roller does it, but they
>>>>> only
>>>>> >> did it halfway, so there's a number of tables in my database
with
>>>>> >> roller_ and the rest don't have the prefix. It's ugly IMO.
>>>>> >>
>>>>> >> +--------------------------+
>>>>> >> | Tables_in_roller |
>>>>> >> +--------------------------+
>>>>> >> | autoping |
>>>>> >> | bookmark |
>>>>> >> | entryattribute |
>>>>> >> | folder |
>>>>> >> | folderassoc |
>>>>> >> | newsfeed |
>>>>> >> | pingcategory |
>>>>> >> | pingqueueentry |
>>>>> >> | pingtarget |
>>>>> >> | rag_config |
>>>>> >> | rag_entry |
>>>>> >> | rag_group |
>>>>> >> | rag_group_subscription |
>>>>> >> | rag_subscription |
>>>>> >> | referer |
>>>>> >> | roller_audit_log |
>>>>> >> | roller_comment |
>>>>> >> | roller_hitcounts |
>>>>> >> | roller_properties |
>>>>> >> | roller_tasklock |
>>>>> >> | roller_user_permissions |
>>>>> >> | roller_weblogentrytag |
>>>>> >> | roller_weblogentrytagagg |
>>>>> >> | rollerconfig |
>>>>> >> | rolleruser |
>>>>> >> | usercookie |
>>>>> >> | userrole |
>>>>> >> | weblogcategory |
>>>>> >> | weblogcategoryassoc |
>>>>> >> | weblogentry |
>>>>> >> | webpage |
>>>>> >> | website |
>>>>> >> +--------------------------+
>>>>> >>
>>>>> >> Matt
>>>>> >>
>>>>> >> On 3/14/07, tibi <[EMAIL PROTECTED]> wrote:
>>>>> >>> great more votes for app_* ;-)
>>>>> >>> there are only 3 tables i would change it to
>>>>> >>> app_user
>>>>> >>> app_role
>>>>> >>> app_user_role
>>>>> >>>
>>>>> >>> and all problems are gone. no reserved words and only very
rarely
>>>>> >>> problems with existing db's
>>>>> >>> its clear and simpel
>>>>> >>>
>>>>> >>> tibi
>>>>> >>>
>>>>> >>> Nathan Anderson wrote:
>>>>> >>> > This all seems like familiar ground ;)
>>>>> >>> >
>>>>> >>> > I like the prefix idea. It's always kinda bugged me that the
>>>>> only
>>>>> >>> > table with a prefix was "app_user". It's like, "one of
>>>>> these things
>>>>> >>> > is not like the others." ;)
>>>>> >>> >
>>>>> >>> > In an ideal world I would like to see all the tables have a
>>>>> matching
>>>>> >>> > prefix that is configured somewhere with a default of
>>>>> "app_" or
>>>>> >>> > something similar. But I have no idea how hard that is to
>>>>> do.. :/
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > Nathan
>>>>> >>> >
>>>>> >>> > Matt Raible wrote:
>>>>> >>> >> Yeah, but the problem with that is we get into the whole
>>>>> >>> >> plural-table-names debate. I chose app_user because of
Oracle
>>>>> >>> >> originally. I thought "role" was a keyword too, but
>>>>> apparently not.
>>>>> >>> >>
>>>>> >>> >> Matt
>>>>> >>> >>
>>>>> >>> >> On 3/14/07, Sanjiv Jivan <[EMAIL PROTECTED]> wrote:
>>>>> >>> >>> I prefer "users" as "user" is a reserved word in Oracle.
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> On 3/14/07, Matt Raible <[EMAIL PROTECTED]> wrote:
>>>>> >>> >>> > Are you using Hibernate? If so, there's a
NamingStrategy
>>>>> >>> feature you
>>>>> >>> >>> > can use to add your own prefixes.
>>>>> >>> >>> >
>>>>> >>> >>> > I'm considering renaming "app_user" to "user" to be more
>>>>> >>> standard.
>>>>> >>> >>> > Since these names can be changed, it seems to make
>>>>> sense, no?
>>>>> >>> >>> >
>>>>> >>> >>> > Matt
>>>>> >>> >>> >
>>>>> >>> >>> > On 3/14/07, tibi < [EMAIL PROTECTED]> wrote:
>>>>> >>> >>> > > hi matt and others,
>>>>> >>> >>> > >
>>>>> >>> >>> > > i use appfuse on an existing database structure.
>>>>> appfuse uses 3
>>>>> >>> >>> tables.
>>>>> >>> >>> > > i would like to see that the naming off these tables
>>>>> would be
>>>>> >>> >>> kind of
>>>>> >>> >>> > > unique (like appfuse_rol, appfuse_user_rol)
>>>>> >>> >>> > >
>>>>> >>> >>> > > just an idea...
>>>>> >>> >>> > >
>>>>> >>> >>> > > ciao,
>>>>> >>> >>> > >
>>>>> >>> >>> > > tibi
>>>>> >>> >>> > >
>>>>> >>> >>> > >
>>>>> >>> >>>
>>>>> >>>
>>>>>
---------------------------------------------------------------------
>>>>> >>> >>> > > To unsubscribe, e-mail:
>>>>> >>> >>> [EMAIL PROTECTED]
>>>>> >>> >>> > > For additional commands, e-mail:
>>>>> >>> [EMAIL PROTECTED]
>>>>> >>> >>> > >
>>>>> >>> >>> > >
>>>>> >>> >>> >
>>>>> >>> >>> >
>>>>> >>> >>> > --
>>>>> >>> >>> > http://raibledesigns.com
>>>>> >>> >>> >
>>>>> >>> >>> >
>>>>> >>> >>>
>>>>> >>>
>>>>>
---------------------------------------------------------------------
>>>>> >>> >>> > To unsubscribe, e-mail:
>>>>> >>> >>> [EMAIL PROTECTED]
>>>>> >>> >>> > For additional commands, e-mail:
>>>>> [EMAIL PROTECTED]
>>>>> >>> >>> >
>>>>> >>> >>> >
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >
>>>>> >>> >
>>>>>
---------------------------------------------------------------------
>>>>> >>> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
>>>>> >>> > For additional commands, e-mail:
>>>>> [EMAIL PROTECTED]
>>>>> >>> >
>>>>> >>> >
>>>>> >>>
>>>>> >>>
>>>>>
---------------------------------------------------------------------
>>>>> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> >>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>>>> >
>>>>> >
>>>>>
>>>>>
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
