"skajotde" wrote : Version madnes is my argument and I describe my way to improve/balance this situation ;) (from experience with work on granular libraries). That's fair, but your proposal involves coupling the release schedule of all EJB3 components. This comes at the cost of the 2 drawbacks I'd presented. Would an additional assembly of all the EJB3 component resources in one place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources from the various component versions that are in the EJB3 1.0.0 distribution? "skajotde" wrote : Please don't generalise. There are projects as like whole EJB3, dont libraries. You've now defined a difference between "project" (ie. EJB3) and "library" (the components that make up a project release); that distinction wasn't present before. "skajotde" wrote : In definition I would separate projects from libraries. Project has separate vesioning and release schedule but library not necessary. For the reasons laid out previously, separate release schedule for each component is necessary (or at least desirable). This *ensures* that nothing has changed when no source changes have been made. It's about a guarantee of stability, one of the reasons we've componentized so heavily in the first place. "skajotde" wrote : You say maven releases will have independent releases - ok, so I think there should be additional release as zipped whole binary because it is project not library. Why EJB3 doesn't release zipped distribution like JBossWS, JBossAS, JBM (there is secret installer) ? We are in Linux World and Linux Users don't like when something try hide details. I think you're just asking for a new assembly to contain all of the EJB3 binaries in a unified JAR. And another one for all sources. "skajotde" wrote : I'm not pro shell scripts but ejb3-installer imho should be in zipped distro and operates on files in this zip. Now I guess it downloads jars from maven repo ? No, the ejb3-plugin contains all artifacts to be installed, and is a standard executable JAR. There's no downloading involved. "skajotde" wrote : I suspect you are maven fan and it is main reason to using automagic installer. I'm not so (I have many trouble with unpredicatble maven dependencies). When you download whole distribution there is closed space and you see what you get. With maven this space of dependecies are open and very fast grow (to 1GB maven repo) and I have many class conflicts because I dont see which library is using. Predicable closed dependencies is my prefered way to configure project and it is main reason I ask if there is enable one whole binary of EJB3. So user is not forced to maven when using EJB3. I didn't follow a lot of that reasoning. * We use Maven as a build tool and work through both its benefits and shortcomings. No one I've found has been a "fan" for any non-technical reason. * Maven has nothing to do with the "automagic installer" (ejb3-plugin). * As an end-user you're not forced to use Maven at all. Take our built artifacts and go. * The issue of dependencies isn't just Maven's fault. The EJB3 project must declare dependencies to be built, and AS provides its own dependency chain. So there's a compilation/test set and a runtime set, which may be mismatched. We've been in talks to address this. "skajotde" wrote : Little digression and other question: What is way to get dependency to ejb3 in my maven project. I will have to list all libraries explicite, all 22 libraries ? Just bring in org.jboss.ejb3:jboss-ejb3-as-int:1.0.0. Everything else will come in transitively. But if you're just building applications that *use* JBoss EJB3, you can get by with just the EJB3 API and the JBoss EJB3 External API. Or more simply, a dependency upon jbossall-client.jar. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204860#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...