Migrating from EJB2.1 to EJB3.x

[mikemil]

We are looking at migrating from EJB 2.1 over to EJB 3.x and I have what should be a simple question.   How do most folks maintain their EJB 3.x 'business interface' classes?   Do you just create the interface and then the implementation and keep them in-sync manually or is there some other way to manage them?

The reason I ask is because we currently use XDoclet quite heavily and one of the tasks we use is the ejbdoclet, where we (XDloet) tag a method as an ejb interface method and then our build process generates those classes/interfaces.   As a result, those are not files maintained in our repository.  I realize this isn't a lot of work but our current build process automatically handles this along with creating the jars for our EJB (remote) clients that include base code plus the remote 'business interface' classes needed by tthe remote clients.

[wdfink]

As there are only less classes you might do it manual or use tools like JBossIDE, Eclipse, Netbeans .....

I prefer such approach because you might have a separate API archive including all interfaces and classes used by other parties.

The benefit is that you have a git/svn repo where you can track API compatibility and the API 'design' is separated from the implementation.

[mikemil]

So are you saying you would keep the business interfaces in a separate folder from the implementation?   Generally, wouldn't you keep the interfaces in the same package/folder with the impl?  Not sure I am following you point?

Manually maintain the interfaces isn't a lot of work but does feel like a step backward from our current process where those classes only exist once they are generated by the build, and never hit the repository.  With all of the other possibly migrations, I want to prevent as many 'steps backward' as possible.

[wdfink]

I have a separate mvn (or ant) module but the package name is the same as the implementation. So the API-module is separated from the implementaion modul. Yes I know that i.e. with mvn/ant it is possible to separate the client interfaces and classes in a *-client.jar but it was a project requirement.

Manually maintain the classes I prefere because of having the API SCCS controlled, but it is my opinion.

In my last projects it often happen that a developer change a public interface without any notice because in the new build all interfaces are generated and at the end of the release process the regression tests fail because of such incompatible changes.