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

> this problem marker is created by JPA Validator. It checks the jar at the path: > > /src/main/java/sportsclub-domain.jar and doesn't find it. Where does it get that path from ?

> 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.

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.

/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

>>> this problem marker is created by JPA Validator. It checks the jar at the path: >>> >>> /src/main/java/sportsclub-domain.jar and doesn't find it. >> Where does it get that path from ? > It gets defaultSourceRoot of the project and appends jar name to it (for the projects without Dynamic Web project facet). yeah, well that isn't right for sure - should look in the classpath if anything. >>> 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?

> 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 ?

>> 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 ?

/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

>>>>> 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 ;)]\

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.

>>> 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.

>>>> 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

>>>>>>> How the validator should be pdated? >>>>>> 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

But I see it in Maven dependencies. Look at the attached image. 14.06.2012 12:52, Dmitry Geraskov написал: > 14.06.2012 11:48, Max Rydahl Andersen написал: >>>>>>>>> How the validator should be pdated? >>>>>>>> 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. > This is not true, look at the attached picture. The project is in pom.xml dependencies but not in dependencies from Eclipse view. I imported all the projects as maven projects. >> >> /max <dependencies2.jpg>