JavaFX(Maven)+EJB项目编译过慢且依赖过重问题求助

First off, this is absolutely not normal—pulling in the full glassfish-embedded-all dependency is overkill for almost every use case, and that's exactly why you're seeing massive JAR sizes and glacial build times. Let's break down what's happening and how to fix it:

Why You're Seeing These Issues #

The glassfish-embedded-all artifact is a monolithic bundle containing the entire GlassFish application server—EJB container, web server, JPA provider, security services, and every other component GlassFish offers. It's designed for niche scenarios like running full integration tests with an embedded server, not for regular application development or deployment.

• The 100MB JAR makes sense because you're packaging an entire server alongside your simple Hello World code.
• The 10+ minute build time comes from Maven having to download, unpack, and package this enormous dependency every time you build.
• The javax.naming.NoInitialContextException happens because EJBs rely on a JNDI context to be looked up; without an embedded server or connection to a remote server, there's no JNDI environment available at runtime.

Solutions (Tailored to Your Use Case) #

1. If You're Deploying to a Standalone GlassFish Server #

This is the most common scenario. The standalone GlassFish server already provides all the EJB/JNDI components you need—you don't have to package them with your app.

• Update your pom.xml to set the dependency's scope to provided:

  <dependency>
      <groupId>org.glassfish.main.extras</groupId>
      <artifactId>glassfish-embedded-all</artifactId>
      <version>5.0</version>
      <scope>provided</scope>
  </dependency>
  

  The provided scope tells Maven to use this dependency for compilation and local development, but exclude it from your final JAR. This will immediately shrink your JAR size to just your code and necessary lightweight dependencies, and cut build time drastically.

• For local testing, you can either start a standalone GlassFish server and deploy your app to it, or create a Maven profile that enables the embedded dependency only for test runs (so it doesn't affect production builds).

2. If You Need a Lightweight Embedded EJB Container for Local Testing #

If you want to avoid starting a full standalone server for quick tests, swap glassfish-embedded-all for a smaller, purpose-built embedded EJB container like Apache OpenEJB:

• Replace the GlassFish dependency with:

  <dependency>
      <groupId>org.apache.openejb</groupId>
      <artifactId>openejb-core</artifactId>
      <version>4.7.5</version>
      <scope>test</scope>
  </dependency>
  

  OpenEJB is focused solely on EJB execution, so it's a fraction of the size of GlassFish embedded. You'll need to adjust your JNDI initialization code to use OpenEJB's context factory, but it'll eliminate the huge JAR and slow builds entirely.

3. If Your JavaFX App is a Remote EJB Client #

If you're calling EJBs from a JavaFX client (not packaging EJBs with the client), you don't need any server dependencies at all. The NoInitialContextException here is because you haven't configured the client to connect to your remote GlassFish server's JNDI context.

• Remove the glassfish-embedded-all dependency entirely.
• Add only the JAR containing your EJB's remote interface (or include the interface classes directly in your client project).
• Configure the JNDI context in your JavaFX code to point to the remote server:

  Properties jndiProps = new Properties();
  jndiProps.setProperty(Context.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
  jndiProps.setProperty(Context.PROVIDER_URL, "http://localhost:8080/glassfish-web-http-client");
  
  InitialContext ctx = new InitialContext(jndiProps);
  YourEJBRemote ejb = (YourEJBRemote) ctx.lookup("java:global/your-ear-name/your-ejb-module/YourEJB!com.yourpackage.YourEJBRemote");
  

  This way, your client connects directly to the remote GlassFish server, and your JAR stays tiny and builds quickly.

内容的提问来源于stack exchange，提问作者Bruno A