Changing the issue type of this ticket given this is not really a bug but rather a 'feature improvement'. This limitation is already noted in the known issues section of the reference guide. Further details about the complexity of supporting the full specification of the JSR-303 spec are offered in ROO-804.

Please vote for this ticket so we can gauge community interest.

Assigning to Alan given he has implemented this improvement. The known issues section still needs clean up.

Checks for @Size, @Max, @Min, and @Column(length = ?) Added

Is this resolved in 1.1.0M2? I am getting constraint violation exceptions with tests generated by --testAutomatically for the following entities:

entity --class ~.domain.security.Users --testAutomatically --table security_users
field string --fieldName username --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
field string --fieldName password --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
field string --fieldName passwordAgain --transient --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
field string --fieldName salt --notNull --sizeMax 25 --class ~.domain.security.Users
field boolean --fieldName enabled --class ~.domain.security.Users
controller scaffold --class ~.web.security.UsersController --entity ~.domain.security.Users

entity --class ~.domain.security.Authorities --testAutomatically --table security_roles
field string authority --notNull --sizeMax 50 --sizeMin 8 --regexp ^ROLE_[A-Z]* --class ~.domain.security.Authorities
controller scaffold --class ~.web.security.AuthoritiesController --entity ~.domain.security.Authorities

entity --class ~.domain.security.UserAuthority --testAutomatically --table security_role_user
field reference --fieldName users --type ~.domain.security.Users --class ~.domain.security.UserAuthority
field reference --fieldName authorities --type ~.domain.security.Authorities --class ~.domain.security.UserAuthority
controller scaffold --class ~.web.security.UserAuthorityController --entity ~.domain.security.UserAuthority

The users tests fail because you have annotated a transient field with a @NotNull - remove this and it will pass, and we don't support the @Pattern annotation used in Authorities. The test data generated in DoD is not compatible with the pattern specified, hence the failure.

Hi, I think I have a same problem.
I generate my domain class IpRange like this:
entity --class ~.domain.IpRange --testAutomatically
field string --notNull --fieldName startIp --regexp ^(([0-9]|[1-9][0-9]|1[0-9]

|2[0-4][0-9]|25[0-5])$
field string --notNull --fieldName endIp --regexp ^(([0-9]|[1-9][0-9]|1[0-9]

|2[0-4][0-9]|25[0-5])$

tests fail because of:
<error message="validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ]" type="javax.validation.ConstraintViolationException">javax.validation.ConstraintViolationException: validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ]

Is there any other way (either now or planned for future) where I can supply valid data, without a need to push in aj file and change IpRangeDataOnDemand.java?

Since this Jira issue is related to @Size, would you please raise a new feature request for @Pattern support in data on demand. We like to keep the Jira tickets as fine grained as possible.

As a workaround now, you can always push-in refactor the Dod ITD and modify the methods yourself to supply @Pattern-compatible test data.

Hi. I'm enjoying my experimentation with Roo.

However, I ran into this problem within the first 30 minutes.

A newbie question: can you define "you can always push-in refactor the Dod ITD and modify the methods yourself"