I like Ant more, and I think I would use maven more if it could be integrated into Eclipse. I have not found a maven/eclipse plugin that works...
On 10/25/06, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
I'm not sure if it's relevant for MINA, but I like the way Spring distributions are organized: * one uber jar: for users who don't care about the size of jars (like me) * smaller jars for those who want to pick and choose * all dependencies, with clear documentation about what you need in which case * ant build works out-of-the-box, no internet-connection needed I understand that supporting two build tools (and + maven) causes overhead, but it would be interesting for non-Maven users (like me). Maarten On 10/25/06, Trustin Lee <[EMAIL PROTECTED]> wrote: > 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 > >
