14.06.2012 10:48, Max Rydahl Andersen wrote:
>>>>> How the validator should be updated?
>>>> My guess is that persistence.xml has a relative reference to a jar which
the validator does not resolve correctly.
>>> There is no this jar in projects, but one of the project named
"sportsclub-domain" and I think it will be generated in the
sportsclub-domain.jar and available in classpath of our project, but the question is how
can I know this?
>> isn't sportsclub-domain in the list of dependent projects ? could check when
refs with xyz.jar if there is a xyz named project?
> Yes, we depend on the project (but through pom.xml, I guess I can pick this up
somehow). And I guessed that I could fix this by checking names of the projects we depend
on. But would this fix be absolutely correct or only will fix this particular situation?
What if the jar will be located somewhere else (for example in source folder of the
project we depend on)?
Nothing prevents you from looking multiple places ;)]\
Sure, but I would like to
know where should I look. (User problem helps
to find only one place - the projects names we depend on)
the validation here is tricky to do since at design/tooling time you do not have the
Wether this is setup via pom.xml or not should not matter.
Yes, but if Hibernate
tools will be used without any Maven plugins I
will not know about the dependencies in pom.xml. But probably this is
not our problem as user's project will not be Maven project from Eclipse
>>> I could provide a place for such validation for the guy working with web
projects who know what will be available at runtime(Rob, Fred,...?).
>> so this is validation *we* control and not dali ?
> This is a default Dali validation which we easily could override.
ah nice - where in the code is the current validation ?
Would like to see what kind of validation they do currently.
AbstractJarFileRef#buildJarFile() should not return null to remove this
>>>> I recall there being discussions on dali-dev on this subject because the
JPA spec is not clear about it.
>>>> One way to "fix" this is to at least not make this an error by
default since jars might not exist at tooling time.
>>> This would also switch off correct error messages.
>> All JPA validation messages or just those concerning similar jar reference errors
> Only the jar references validation.
okey - then that is definitely a fallback solution (to downgrade them to warning since
otherwise you get false positives)
>>>>> 08.06.2012 11:33, Max Rydahl Andersen wrote:
>>>>>> Can you track down why
is happening on projects like