mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Moving to Java 5 and merging all subprojects into one big project.
Date Thu, 26 Oct 2006 16:50:00 GMT
On Thu, 2006-10-26 at 07:54 -0400, Alex Karasulu wrote:
> Trustin Lee wrote:
> > On 10/26/06, Alex Karasulu <aok123@bellsouth.net> wrote:
> >>
> >> Trustin Lee 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
> >> >> worse than with separate jars.
> >> >
> >> >
> >> > The problem Vinod mentioned is very different from what you're talking
> >> > about
> >> > here.
> >>
> >> That's why there is an "Also" in my 2nd paragraph.  I agreed with Vinod
> >> and added to it to describe other problems.
> >>
> >> > As I already told Vinod, we can use 'provided' scope dependencies.
> >>
> >> It's not a matter of scope.  It's a matter of having additional stuff in
> >> the jar that you don't want.  Besides the bloat it could create
> >> dependency issues.
> >>
> >> Basically we've spent time and effort ironing out the way this multi
> >> project is setup.  It just works.  I don't see a reason to change it.
> >> I'm going to have to veto this change at this point.  I'm not convinced
> >> you have a good reason to do it and there are disadvantages.
> > 
> > 
> > I basically agree with your point of view in the long term.  I thought 
> > about
> > this issue during the night and I realized that we had a problem in
> > communication because I raised two issues into one thread.  Vinod raised a
> > good point here.  We can get rid of Java5 subproject and move to Java 5
> > first, and then need to think about project organization later if we really
> > need to do so.
> Yeah this is what I'm thinking.  The Java 5 move is important and I'm 
> all for that.  However let's see where MINA is going to go with all the 
> add ons we're going to throw into the project.
> We may find we need to keep this multi-project structure after 
> destroying it.  So this is why I think we should just be a bit more patient.

As mentioned before, am in favor of the move to Java 5 and the
consolidation of sub-projects. Now, based on some of the feedback given
on this thread I am not very clear on the reasons for the sub=projects,
but if they serve the communities interest by eliminating bloat of code
or dependencies them I am for keeping them as well. If they don't do
either of these well enough and are more for working around the Java1.4
vs Java 5 dev problem (as Trustin suggested) let's combine them. Of
course it's a trade off - it's code development and administration
versus systems engineering and runtime (download bandwidth, disk storage
and memory).  

To this I would like to add two more things to consider. The first has
to do with project structure the second more to how we integrate within
and between Mina and ApacheDS. Both have to do with OSGi. AFAIK we are
still moving to support OSGi in this release. (Right?)

1. Depending on what is done with the project structure the move to a
Mina OSGi could be as trivial as a patch to one pom or in the case of a
multiproject multiple poms. So, the question we should as ourselves: 

Is there real benefit to Mina being a multiple module runtime (multiple
bundles) where the various Mina modules can be dynamically downloaded,
installed, updated, stopped or started?

If the answer to that question is yes, besides keeping the multiproject
structure we will have to do one more thing, ---> We have to change our
current Mina sub projects to consolidate packages so they are uniquely
contained within each of the projects. (IE packages cannot span multiple
projects.) I think this is easy and will not impact anyone way of doing

If the answer is the need for a multi-module Mina is no, then we (I) can
easily patch the single Pom (of the combined uberproject) or wrap the
multiple jars (in a separate project).

2. The next release of Spring (2.1) will support OSGi. Not really sure
how this is going to impact us but it could for the better.
Just doing some initial experimentation with it to see how we can
leverage it with ApacheDS. IMHO the OSGi enabled Spring could have a big
impact on both ApacheDS and Mina. 

Check it out:



View raw message