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.
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.
1 of 1 people found this helpful
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.