[jbosstools-dev] The horrors of jar-file validation in dali/hibernate

[Dmitry Geraskov]

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 complete picture.
>
> 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 
view.
>
>>>> 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 
error.
>
>>>>> 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)
>
> /max
>
>>> /max
>>>
>>>>> /max
>>>>>
>>>>>> Dmitry
>>>>>>
>>>>>> 08.06.2012 11:33, Max Rydahl Andersen wrote:
>>>>>>> Dima,
>>>>>>>
>>>>>>> Can you track down why https://issues.jboss.org/browse/JBIDE-11534 is happening on projects like https://github.com/snowdrop/snowdrop-examples ?
>>>>>>>
>>>>>>> /max