On 10/25/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Also let me add that there will be more version collisions between MINA dependencies and the same dependencies used in apps that use MINA but perhaps of a different version. When you have one jar this problem is worse than with separate jars.
The problem Vinod mentioned is very different from what you're talking about here. As I already told Vinod, we can use 'provided' scope dependencies. Dependencies will be specified clearly via POM and documentation. Having multiple subprojects and managing dependency is a whole different problem. I don't see why you are saying that one jar has more problem than separate jars in dependency management. MINA will grow fast and more additions will be made over time
compounding this issue. Keeping things separate is a release management hassle I know but I've discovered tricks to reduce that overhead with Maven just recently at ApacheCon US when talking to some maven folks.
You must be talking about the <dependencymanagement> tag that Alan told us. I don't think there's no essential difference in there from one project with all depenencies specified. IMHO, Maven multiproject is an idea to simplify the build tool itself rather than to help build tool users. One possible problem is that we might have a huge subproject that needs multiproject architecture someday. But we don't have such demand in the near future, considering our growth rate. We can simply expand the project when we really have to do, and it's not today, and we already over-expanded projects, and it's origin was Java 5 compilation issue. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
