Ersin Er wrote:
0 Java5 migration
-1 Subprojects merging
MINA's current project structure seems almost perfect to me. It gives
you dependency granulalarity and provides Java5 support where needed.
I do not see a strong reason to do the both moves. But if Java 1.4 is
preventing MINA to support new features, Java5 move can be considered
more seriously.
I was questioning the Java 5 move myself.
However I think there are some real reasons why MINA should move in that
direction: concurrent libs, better performance with improved locking
constructs. I think eventually we're going to have an even better MINA
with 1.5.
We still have the 1.0 branch for those interested in sticking to 1.4.
What I do recommend is that MINA jumps to version 1.5 instead of 1.1 to
give a cue to users that something big has changed. A switch in JDK
versions is not a simple jump like the one from 0.9 to 1.0. It's a bit
more serious than that. You do want to give the users some kind of
hint. When they see you have jumped from 1.0 to 1.5 they will ask why
at least internally and take a closer look to see the differences if not
directly ask on the list.
If we bump MINA to 1.1 and unsuspecting users move to 1.1 they're going
to be surprised and perhaps a bit unhappy when they realize JDK 1.4 is
no longer supported. Again they'll have to dig around or ask the ML but
in the end they're not going to be happy.
In the end I think it's important to have some consistency in the way we
do versioning. I know there are some loop holes but we'll be consistent
in showing that something big has happened by skipping a few minor
versions as did the Tomcat folks.
Alex
On 10/26/06, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 10/26/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>
> Trustin Lee 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.
>
> 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.
I also agree with you that single project in Maven has disadvantages.
Again, it's about timing, considering the current dependency of MINA. As
long as we live with Maven, we have to use multiproject structure and we
can't change the way how a project is organized.
Thanks,
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
