[jbosstools-dev] The horrors of jar-file validation in dali/hibernate
Max Rydahl Andersen
max.andersen at redhat.com
Thu Jun 14 04:48:12 EDT 2012
>>>>>>> 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)
afaics, the classpath of the project is where Dali should look, i.e. libraries referenced and project workspace names.
>> 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.
Again, nothing in the pom.xml is relevant here - pom.xml is just read by m2e and then it configure eclipse standard java/web projects to have the right dependencies.
This is not m2e nor mvn specific - you could remove the pom.xml and m2e eclipse nature after loaded the project and it should still work.
/max
More information about the jbosstools-dev
mailing list