mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maarten Bosteels" <mbosteels....@gmail.com>
Subject Re: Moving to Java 5 and merging all subprojects into one big project.
Date Wed, 25 Oct 2006 14:16:22 GMT
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).


On 10/25/06, Trustin Lee <trustin@gmail.com> wrote:
> On 10/25/06, Alex Karasulu <aok123@bellsouth.net> 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

View raw message