Comment 1 Neil Hauge 2009-02-03 18:28:01 EST

I apologize for not responding to this earlier, but I wasn't sure quite how to respond to this issue. 

It would appear that we are not handling the case where this filtering is being done, and I assume that would be a bug on our part.  But I'm not sure I understand the request very well.  The JPA tools don't rely on compiled classes, but rather require Java sources to work with.  The tooling manipulates .java files via the JDT, and as a result I don't think we can move away from this standard use-case (java files in source folders).  

It seems that there may be a new use case here, which involves (I think) working with Java source files located in the output folder.  I'm not sure if or how this would work given our current usage of JDT, but perhaps someone could investigate the possibilities in this area.

Comment 2 Markus Knittig 2009-02-11 16:38:52 EST

(In reply to comment #1)
> It would appear that we are not handling the case where this filtering is being
> done, and I assume that would be a bug on our part.  But I'm not sure I
> understand the request very well.  The JPA tools don't rely on compiled
> classes, but rather require Java sources to work with.  The tooling manipulates
> .java files via the JDT, and as a result I don't think we can move away from
> this standard use-case (java files in source folders).  

Java sources are still in source folders and work fine with Dali. Only resources (all non-Java source files) like persistence.xml and orm.xml can be filtered and therefore need to be read from the output folder.

Comment 3 Oliver Gierke 2009-02-13 07:33:15 EST

+1

Can only second that. JPA Tools are entirely unusable if you use m2eclipse which is really annoying if you have a lot of projects build on this combination ;).

Regards,
Ollie

Comment 4 Max Rydahl Andersen 2009-02-13 09:34:02 EST

hmm - how is Dali supposed to *edit* persistence.xml in the output ? that is not really relevant.

Where is the persistence.xml in the first place ?

Comment 5 Markus Knittig 2009-02-13 11:07:19 EST

(In reply to comment #4)
> hmm - how is Dali supposed to *edit* persistence.xml in the output ? that is
> not really relevant.

Good point, but I write the persistence.xml myself anyway. I still would like to use the Persistence Outline/Properties...

> Where is the persistence.xml in the first place ?

src/main/resources/META-INF/persistence.xml
src/main/resources is a java soure folder, but, as Eugene pointed out, all files are excluded, because m2eclipse handles resources with a custom builder to be able to filter resources.

Comment 6 Neil Hauge 2009-08-03 11:52:10 EDT

There is some discussion going on about using Maven with Dali JPA on the Dali newsgroup.

Here is the root of the thread:

http://www.eclipse.org/newsportal/article.php?id=717&group=eclipse.technology.dali#717

Comment 7 Markus Knittig 2009-08-04 14:42:18 EDT

(In reply to comment #6)
> There is some discussion going on about using Maven with Dali JPA on the Dali
> newsgroup.

Nothing new, the posters probably don't use resource filtering...

Comment 8 Paul Fullbright 2010-04-01 12:16:13 EDT

*** Bug 290929 has been marked as a duplicate of this bug. ***

Comment 9 Philippe Marschall 2010-04-14 05:02:06 EDT

I created an issue against m2eclipse "MNGECLIPSE-2197":https://issues.sonatype.org/browse/MNGECLIPSE-2197

Comment 10 Oliver Gierke 2010-04-14 05:56:51 EDT

(In reply to comment #9)
> I created an issue against m2eclipse
> "MNGECLIPSE-2197":https://issues.sonatype.org/browse/MNGECLIPSE-2197

I don't really get why looking up classpath resources done against filtered source folders should be M2Eclipse's fault. Dali simply has to inspect the applications target folders. I think the main bug is to expect resources being filtered from the source folders cannot appear in the classpath in any case. In M2Eclipse case, as the pom.xml is the simple place of truth all resources have to marked as excluded as it applies the filtering configured in the pom and the rather limited filtering of Eclipse has to be "deactivated" somehow.

Regards,
Ollie

Comment 11 Neil Hauge 2010-04-26 17:10:05 EDT

We are going to be doing some work in this area for our next release which will hopefully improve this general issue.

Comment 12 Paul Fullbright 2010-06-24 20:26:59 EDT

bug 317900 has been opened to track a solution to this problem.

Comment 13 Paul Fullbright 2010-07-30 15:55:11 EDT

bug 317900 has been fixed, which should go a long way towards addressing this issue.  The problem remains to map runtime artifacts to resource locations (or to allow build resources to be used), and I feel this puts the ball in m2eclipse's court to provide an implementation of ResourceLocator that will do this.

Comment 14 ludo 2011-03-01 14:57:12 EST

more and more GlassFish users, using maven are seeing this...

Comment 15 Neil Hauge 2011-03-01 16:43:52 EST

CC'ing m2e project lead.  Igor...perhaps you could comment on the possibility for an m2e solution for this issue based on the Dali changes made in bug 317900?  It would be great if we could work something out for Indigo.

Comment 16 Igor Fedorenko 2011-03-04 10:00:11 EST

Adding Fred Bricon to CC who maintains m2e/wtp integration, which is not part of m2e eclipse.org project, at least not yet.

Comment 17 Neil Hauge 2011-08-25 11:27:00 EDT

Update:  Progress is being made on a solution outside of the Dali project in the m2e-wtp tooling.  I don't have information on an date for this support, but it is currently targeted to m2e-wtp 0.14.

This issue can be tracked further here - https://issues.sonatype.org/browse/MECLIPSEWTP-11.  

I am un-targeting this bug as it won't be fixed in a Dali release, but will leave it open for tracking purposes until there is a solution available.

Comment 18 Philihp Busby 2011-08-31 21:02:48 EDT

The real world is still seeing this problem, 3 years later.

http://stackoverflow.com/questions/3701901/eclipse-does-not-recognize-content-of-persistence-xml

Comment 19 Neil Hauge 2011-09-01 15:03:18 EDT

(In reply to comment #18)
> The real world is still seeing this problem, 3 years later.

I can understand the frustration, and I can assure everyone that the Dali project is very interested in getting proper Maven support, as there is obvious demand from our users.  I see m2e-wtp as the proper and only real solution at this time, and as such we have been collaborating with those involved in this effort.  I will try to get more information on when 0.14 is planned for release.

Comment 20 Fred Bricon 2011-09-02 04:43:40 EDT

(In reply to comment #19)
> I will try to get more information on when 0.14 is planned for release.

I plan on releasing before the end of september. That means I'll get my hands on the matter real soon, probably next week.

Comment 21 Fred Bricon 2011-09-02 06:07:31 EDT

Is there an update site containing Dali or WTP nighlty builds so I can get m2e-wtp's own tycho build running?

Comment 22 Neil Hauge 2011-09-07 10:34:21 EDT

(In reply to comment #21)
> Is there an update site containing Dali or WTP nighlty builds so I can get
> m2e-wtp's own tycho build running?

Nightly WTP builds are available at the following location:

http://build.eclipse.org/webtools/committers/

Milestone and integration builds are found here:

http://download.eclipse.org/webtools/downloads/

Indigo maintenance builds are labeled "3.3.1", Juno builds are "3.4.0".  Each build has a hosted p2 repository, which can be found by appending "/repository" to the end of the build page URL.  So for the latest nightly build, the p2 repo is located here:

http://build.eclipse.org/webtools/committers/wtp-R3.3.1-M/20110907002726/M-3.3.1-20110907002726/repository/

The nightly's aren't retained for very long, so that is something to be aware of.

Comment 23 Fred Bricon 2011-09-09 05:09:33 EDT

Hi,

I've been trying to implement a Maven Resource Locator. I'm still not exactly sure where I'm going but, so far I wrote a *very* simple, naive implementation, which basically returns the files under the build output folder and delegates everything else to the SimpleJavaResourceLocator.
That means the project explorer always displays the resolved / filtered persistence.xml. The problem is if you click on the nodes under the JPA Content icon, it'll open the resolved file, not the source one.

So if I were to return the source file instead, well we'd get the opposite. Correct edited file but invalid connection parameter values, if they were filtered.

So. I can probably return the original source file  when maven filtering is deactivated, and the filtered file when it's on, but that feels a bit odd.
WDYT?

Also it seems the getRuntimePath method is never used/referenced.

Comment 24 Paul Fullbright 2011-09-15 10:06:34 EDT

There has been a lot of confusion on this issue.  After conversations with Fred Bricon, I think we can say that the fix to bug 317900 should solve almost all (if not indeed all) issues with maven.

The problem is that somewhere someone suggested that we should be looking at *output* files when maven is concerned.  This led to the idea that m2e should implement a resource locator to map runtime locations to files in the output directories.  This is not the case.  Dali should be fine with source files in every scenario I (and others) can imagine.  Exclusions were the problem.  *Not* filtering.

We're very close to marking this as fixed (in Indigo).  We ask that any who have had problems with this in the past try this in Indigo and indicate if it is no longer a problem or give more details if it is still a problem.

Comment 25 Neil Hauge 2011-09-28 14:52:33 EDT

It should also be noted that inconsistent results in testing on Indigo based builds could be due to bug 357810.  If Dali doesn't appear to be working as expected, please perform a project Clean... to ensure that the JPA or JAXB project has been built correctly after import.  This should only have to be done once per project and will no longer be necessary after bug 357810 is fixed in Indigo SR2.

Comment 26 Anttix Mising name 2011-10-18 23:59:49 EDT

I would like to add that the inconsistency consistently (pun intended) manifests itself when adding a new dependency to a Mavenized project in Indigo. After re-updating the project configuration (Maven->Update project configuration) the error disappears again. Unfortunately I am not in a position to try any patches.

Here is how to reproduce:

1. Switch to Java EE perspective

2. Create new Maven project (File->New->Other->New Maven Project) from archetype:
    Group ID: org.codehaus.mojo.archetypes
    Artifact ID: webapp-jee5
    Version: 1.3

3. Add a dummy Servlet so there is some Java code for compilers to pick up (New -> Servlet)

4. Create a directory src/main/resources/META-INF

5. Run Maven->Update project configuration

6. Verify that src/main/resources was added to source folders (Java Resources)

7. Enable JPA facet (Properties->Project Facets) and select "Disable Library Configuration" as "Type" (click on "additional configuration" prompt)

8. Verify that persistence.xml was generated to src/main/resources/META-INF

9. Now add a new dependency to the project (Maven->Add Dependency) eg hsqldb:hsqldb:1.8.0.10 or org.hibernate:hibernate-entitymanager:3.6.7.Final

10. The persistence.xml error will appear.

11. Select Maven->Update project configuration or Project->Clean

12. The error disappears again.


My configuration:
Operating system: Fedora 15 x86_64

Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 1
Build id: 20110916-0149

M2E - Maven Integration for Eclipse
Version: 1.0.100.20110804-1717

Dali Java Persistence Tools - JPA Support
Version: 3.0.1.v201108163011-7R7F7CFC7sRdiShWvWQYU375
Build id: 20110324075937

Comment 27 Paul Fullbright 2011-11-15 16:52:42 EST

Antix, I believe that is the behavior to 357810.

Without any further comment on this bug, I am going to resolve it fixed.

Comment 28 Wolfgang Fahl 2015-02-13 08:08:46 EST

This bug is still there in my Eclipse Luna.

Comment 29 Wolfgang Fahl 2015-02-13 08:11:21 EST

http://stackoverflow.com/questions/3701901/eclipse-does-not-recognize-content-of-persistence-xml is pointing here.