There was a bug in this area on the EclipseLink side, but I thought it was fixed already: https://bugs.eclipse.org/bugs/show_bug.cgi?id=311020

Ken, which version of EclipseLink do you have?

Here are the dependencies in the POM as generated by the IDE

<dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>2.1.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>javax.persistence</artifactId>
            <version>2.0.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>org.eclipse.persistence.jpa.modelgen.processor</artifactId>
            <version>2.1.0</version>
            <scope>provided</scope>
        </dependency>

Actually, it seems that now i cannot even run maven projects that have a persistence unit and a test class so I am escalating this to p2

Product Version: NetBeans IDE Dev (Build 201009260000)
Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01-279
System: Mac OS X version 10.5.8 running on x86_64; MacRoman; en_US (nb)
Userdir: /Applications/NetBeans/userdirs/6.10-20100926

Could you attach your project please? I've tested what I could and it seems to work for me. It is not smooth but I was never able to reproduce your error. Thx.

Here are the steps that resulted in the problem for me with Maven projects.

http://wiki.netbeans.org/DocsSimpleTestWithEmbeddedEJB#Simple_Test_of_EJB_Module

Please let me know if there is some problem with the steps or a workaround.

Basically, the project will build until I add a test. After that, the project cannot build because of the error. If I delete the test class, I can build the project again.

If I create the same project with Ant, the project builds and the test passes.

I can reproduce it now.

(In reply to comment #1)
> There was a bug in this area on the EclipseLink side, but I thought it was
> fixed already: https://bugs.eclipse.org/bugs/show_bug.cgi?id=311020

Can anybody else test this? It does not work for me regardless of version of EclipseLink I use (2.0.3, 2.1*, 2.2*). It does fail for me whenever I do Clean&Build because it includes tests compilation which is the trigger for the error.

If I disabled org.eclipse.persistence.jpa.modelgen.processor in pom.xml I can compile test and test execution fails with "NamingException: Lookup failed for 'jdbc/sample' in SerialContext" - have no idea why; in Ant based projects the same scenario works fine.

Correction: it does not work on Maven3; on Maven2 I cannot reproduce the "Unable to load persistence.xml" problem. Anybody any idea why?

I guess Jesse is the only one who might know. Also this is probably time sensitive, considering the fact that Maven 3 final will be released any day now.

I can reproduce the "Unable to load persistence.xml" problem using Maven 2.2.1.

I'm afraid I don't know anything about it. If it is reproducible then you should not have much difficulty tracking it down (run with -X). First make sure that the test project locks down exact versions of all plugins, since the default POM is different in M3 (but M3 will also warn you if you forgot this step).

It looks similar to fail by canonical processor but there is https://bugs.eclipse.org/bugs/show_bug.cgi?id=311020 which is resolved and compilation shouldn't fail on missed persistence.xml.

I see this link was provided before. Just checked with 2.1.1 source(likely the same as 2.1.0) and there is no revert in behavior in corresponding eclipselink class, also searched full src and there is no "Unable to load persistence.xml" message anywhere if I didn't miss something.
So it may be another issue.

tried http://wiki.netbeans.org/DocsSimpleTestWithEmbeddedEJB#Simple_Test_of_EJB_Module
and got test failure and corresponding build failure on clean&build ,after test code(body only) commenting and Clean and Test have all tests passed. Using latest nb build and maven from nb distribution (marked as 3.0 in preferences) and tried with stand alone maven 3.0 beta, all fine.

  Kenneth, can you check which version of eclipselink is added to dependencies? (just check META-INF/manifest.mf in jar)

The dependencies are as listed in the pom.xml in the comments of this issue.
EclipseLink version specified in the pom is 2.1.0

No EclipseLink info is contained in the project jar.

But if it helps, in the artifact eclipselink-2.1.0.jar that is listed under the Dependencies node for the project, the MANIFEST.MF of the jar contains the following:

Ant-Version: Apache Ant 1.7.0
Created-By: 2.4 (IBM Corporation)
Specification-Title: Eclipse Persistence Services
Specification-Vendor: Eclipse.org - EclipseLink Project
Specification-Version: 2.1.0
Implementation-Title: org.eclipse.persistence
Implementation-Vendor: Eclipse.org - EclipseLink Project
Implementation-Version: 2.1.0.v20100614-r7608
Release-Designation: EclipseLink 2.1.0
Premain-Class: org.eclipse.persistence.internal.jpa.deployment.JavaSEC
 MPInitializerAgent

This is the dependency added by the IDE

thanks, version seems valid, unfortunately have no more ideas for now

Forgot everything I said before - I tracked the problem down and it lies somewhere else. The problem is that

  <dependency>
    <groupId>org.glassfish.extras</groupId>
    <artifactId>glassfish-embedded-all</artifactId>
    <version>3.0</version>
    <scope>test</scope>
  </dependency>

is empty jar which refers to hundreds of other jars via ClassPath attribute in its manifest. And one of the referenced jars is also org.eclipse.persistence.jpa.modelgen.jar which in GlassFish version 3.0 is too old - it is 2.0.1 version. So depending on the placement of glassfish-embedded-all dependency in you pom.xml it may or may not work - if you place glassfish-embedded-all as first dependency as suggested in the tutorial which triggered this problem then you get this error. If glassfish-embedded-all is placed after org.eclipse.persistence.jpa.modelgen.processor BUT before javaee-api then everything is OK.

Well done, I think the setup can hardly get more error-prone for user. :-) Incorrect placing of glassfish-embedded-all can result either in the error described in this issue or in a magical "ClassFormatError: Absent Code attribute in method that is not native or abstract in class file". And even if a user gets it right they will end up with "NamingException: Lookup failed for
'jdbc/sample' in SerialContext" which so far I have no idea what is it caused by. Should we even have a tutorial recommending using embeddable EJB container from Maven?? I'm missing where we are helping user here.

In Ant projects the situation is not that bad because usage of embeddable EJB container classpath is hard coded in build-impl.xml and user does not see it on test execution classpath and annotation processors have their own classpath.

So the most appropriate resolution is "WORKSFORME".

I'm going to correct what I said earlier:

(In reply to comment #16)
> The problem is that
> 
>   <dependency>
>     <groupId>org.glassfish.extras</groupId>
>     <artifactId>glassfish-embedded-all</artifactId>
>     <version>3.0</version>
>     <scope>test</scope>
>   </dependency>
> 
> is empty jar which refers to hundreds of other jars via ClassPath attribute in
> its manifest.

That's not true for Maven. For Ant based project we do refer directly to glassfishv3/glassfish/lib/embedded/glassfish-embedded-static-shell.jar (6kB) from GlassFish installation and that file does refer to other internal GlassFish jar files via its manifest. For Maven project union of all required classes was merged into single 46MB jar. And that also explains "NamingException: Lookup failed for 'jdbc/sample' in SerialContext" exception - Maven's glassfish-embedded-all is different(!) from glassfish-embedded-static-shell used in Ant. If I used glassfish-embedded-all from Ant instead of glassfish-embedded-static-shell I get the same NamingException. Anybody knows anything about origins of glassfish-embedded-all? Or should I just file a report for GlassFish team?

Isn't this related to bug 187585? I.e. we would like to update the embeddable container reference to a newer GlassFish, but that does not work.

(In reply to comment #16)
> one of the referenced jars is also
> org.eclipse.persistence.jpa.modelgen.jar which in GlassFish version 3.0 is too
> old - it is 2.0.1 version. So depending on the placement of
> glassfish-embedded-all dependency in you pom.xml it may or may not work

Not sure if it is relevant in this case, but remember that you can specify exclusions in a Maven dependency in case it is pulling in unwanted transitive dependencies.

OK, so I am assuming there is no workaround for this.
Currently we can say that you can create and run tests for EJBs using the embedded EJB container except when the EJB uses JPA.

I believe that Maven generates the classpath based on the order the dependencies are listed in the POM. So it seems like the tutorial should mention the importance of the order.

I filed new GF issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=13865

(In reply to comment #18)
> Isn't this related to bug 187585? I.e. we would like to update the embeddable
> container reference to a newer GlassFish, but that does not work.

I tested 3.0 and 3.0.1 Maven artifacts and they both have a problem. So it is not related.

(In reply to comment #20)
> OK, so I am assuming there is no workaround for this.

Once GF issue is resolved (for example a new jar is published to Maven repository) you could continue with the tutorial and emphasize/explain where exactly to place glassfish-embedded-all dependency - the order of dependencies corresponds to classpath order so it is important.

(In reply to comment #21)
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13865

The answer is to use "system" scoped dependency which is very similar to "provided" scope with difference that a path to JAR on local filesystem must be specified. Basically in order to use GlassFish's implementation of embeddable EJB container a JAR from GlassFish installation must be used, eg.:

        <dependency>
            <groupId>org.glassfish.extras</groupId>
            <artifactId>glassfish-embedded-static-shell</artifactId>
            <version>3.0.1</version>
            <scope>system</scope>
            <systemPath>/home/software/glassfishv3/glassfish/lib/embedded/glassfish-embedded-static-shell.jar</systemPath>
        </dependency>

The path specified must be absolute path but instead of hardcoding it in pom.xml it would be better to use something like

            <systemPath>${glassfish.home}/glassfish/lib/embedded/glassfish-embedded-static-shell.jar</systemPath>

and set glassfish.home to '/home/software/glassfishv3' in one of Maven's property files (I do not know what's the best practice for Maven), ideally in a parent POM so that the value is inherited to all other projects where it may be needed.

BTW. I added a note to issue 187585 to use system scope.

(In reply to comment #22)
> set glassfish.home to '/home/software/glassfishv3' in one of Maven's
> property files (I do not know what's the best practice for Maven)

Add to ~/.m2/settings.xml:

<profile>
    <id>glassfish</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <glassfish.home>/home/software/glassfishv3</glassfish.home>
    </properties>
</profile>

But it is terrible to ask users to do this; system scope should be considered a last resort. The GF team should be told to provide a usable artifact in the official repository.

I agree this sounds rather hacky. I wonder whether we could use the Arquillian approach and whether that would be a cleaner solution: http://community.jboss.org/en/arquillian/blog/2010/10/04/the-perfect-recipe-for-testing-jpa-2-revisited

(In reply to comment #23)
> But it is terrible to ask users to do this; system scope should be considered a
> last resort. The GF team should be told to provide a usable artifact in the
> official repository.

Agreed. I do not think this is going to change anytime soon though. EJB 3.1 introduced an API for embedding EJB container in non-EE application, for example for unit testing. And GlassFish impl of this API basically requires GlassFish installation with most of its internal jars. It should be doable to package all of them into a single jar (similarly like glassfish-embedded-all maven artefact which is "embeddable glassfish server" as opposed to just EJB container) and ask for list of input parameters to configure the EJB container.

(In reply to comment #25)
> It should be doable to package all of them into a single jar

Better would be to create an empty "placeholder" artifact with dependencies on all of the components, which you could depend on as a shortcut.

After Petr H's fix for bug 190387: http://hg.netbeans.org/web-main/rev/8f528cc092cb - would it be possible to do an out-of-the box set up of the embeddable EJB container (as discussed last week in Prague)? For example when the user sets the server, we could add/modify the dependency with system scope pointing to the embeddable container within the server installation, right?

I can create a new issue for this.

BTW, does the groupId and artifactId and version matter in this case? When I just use some arbitrary junk for these, it continues to work (which begs the question why these elements are required if scope is system).

(In reply to comment #28)
> BTW, does the groupId and artifactId and version matter in this case?

No.

Again, system scope should be considered deprecated, and the IDE should certainly never add a system-scoped dep to a user's project. If there is a "standard" JAR that can be used to work as an embedded container, you (or the "maintainers") should upload it to a public repo, so people can use it as a regular test-scope dep.

Well, there *is* a jar in the Maven repo, see: http://download.java.net/maven/glassfish/org/glassfish/extras/glassfish-embedded-static-shell/3.1-SNAPSHOT/

However, this jar is IMO broken, see my comment in: https://glassfish.dev.java.net/issues/show_bug.cgi?id=13865

I think whatever you do, you will *always* need a local installation of the server and will need to point to it when running tests, there is no way around it. Even the JBoss blog says: "You need to set the JBOSS_HOME environment variable to point to a JBoss AS installation" (see http://community.jboss.org/en/arquillian/blog/2010/10/04/the-perfect-recipe-for-testing-jpa-2-revisited).

(In reply to comment #30)
> Well, there *is* a jar in the Maven repo [...]
> However, this jar is IMO broken, see my comment in:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13865

Sounds like it is indeed broken. JARs published to a Maven repo should not include Class-Path headers. So reopen that bug and get them to fix it right.

(And no one should be using a SNAPSHOT dependency except for prototyping.)

(In reply to comment #27)
> I can create a new issue for this.

Please do so and I will have a look. Thx.

Done - bug 191590.