Adam Bien's Weblog
How To Package @Local Interfaces In An EAR?
Got an interesting question:
Lets say you have an EAR archive which contains 3 EJB projects: one project that contains @Local interfaces that are the facades for all three EJB's. The idea is that all 3 of them can communicate with each other using that project as a dependency. Or: The second way is to have for each EJB Project one additional project that has the facade @Local interface and each EJB project to depend those who needs. Which is better?This question is impossible to answer because the reason for the modularization of the EAR is unknown. Before you are going to think about modularization I would start with answering the following questions:
- How often do you have to partially deploy contents of the EAR?
- Is it likely that you will NOT deploy the interface JAR, but only the "implementation" JARs? Why you are doing that?
- How often are you going to change the implementation without recompiling the interfaces?
Without explicit modularization requirements I would package all the clearly separated modules, components and projects into one, big, single EJB-JAR inside the WAR. In Java EE 6 I would use (see: Is Java EE 6 War The New EAR?) The Pragmatic Modularization And Packaging) WAR-packaging and put all the components into a single JAR or even into the classes folder. With Maven you could use the: jar-with-dependencies assembly configuration. If you are still developing with the ancient Java EE 5, I would create a "everything" EJB-JAR and an "everything" WAR inside the EAR. If you are going to implement an API, which is going to be implemented by several JAR-modules, I would provide a single JAR with all interface for each EJB-JAR. I would expect then to find these JARs in several EARs without any modification. Remember: Premature Extensibility (In Java EE 6) Is the Root of Some Evil :-) See also and How To Kill An OSGi Project - With 10 Questions
NEW Special Events: From HTML 5 over Java EE App Building and NoSQL / Distributed Computing to Microservices