You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@apache.org> on 2008/06/07 14:59:02 UTC
[2.0 refactoring] What about splitting mina-core ?
Hi,
in the past two weeks, I browsed the code, and I found that mina-core
could be splitted in one common project and some sub-project, namely :
- mina-future
- mina-socket
- mina-vmpipe
- mina-datagram (?)
- mina-filter-xxx (we have many filters)
The idea is to keep commons simple, and separate concerns.
The main package (common) contains 79 classes, far too much, and could
also be splitted into sub-packages.
This is just a suggestion, in order to open the discussion, I have not
established a strong position about what should be done.
There are two strong cons to this approach :
- users already using 2.0-M1 will have to fix their code
- it will now be necessary to import more than one jar
(I prefer to bring those on the table right now :)
But I think that if we don't do this kind of reorganiztion _before_ the
2.0-RC1, it will be too late and a potential 3.0 release will suffer
from the existing installed base.
I realize that those proposals may be imperfect, but the idea i really
to open the discussion.
Thoughts ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 25, 2008 at 9:54 AM, Julien Vermillard
<jv...@archean.fr> wrote:
> Ok, let's do that, anyway I finally deployed a new snapshot.
Thanks!
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Wed, 25 Jun 2008 09:46:36 +0200
"Niklas Gustavsson" <ni...@protocol7.com> wrote:
> On Wed, Jun 25, 2008 at 9:30 AM, Julien Vermillard
> <jv...@archean.fr> wrote:
> > Ok will try to do it today,
>
> Thanks!
>
> > anyway we got a problem ftpserver &
> > asyncweb shouldn't depend on MINA snapshot but on MX releases for
> > avoid this kind of problems, when we release next milestone (I
> > suppose it can be done as soon we decided to stop changing
> > packages :D) we need to change the subproject dependencies. If
> > there is a big move needed by one of the subproject we will just
> > need to release a milestone.
>
> Agreed, for FtpServer we did depend on M1 for a while. However, we
> then needed some stuff developed in M2-SNAPSHOT (for blacklisting) so
> I had to depend on the snapshot version. As soon as M2 is available,
> we will try to stick with that. I think we should attempt to get it
> out fairly soon.
>
> /niklas
Ok, let's do that, anyway I finally deployed a new snapshot.
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 25, 2008 at 9:30 AM, Julien Vermillard
<jv...@archean.fr> wrote:
> Ok will try to do it today,
Thanks!
> anyway we got a problem ftpserver &
> asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
> this kind of problems, when we release next milestone (I suppose it can
> be done as soon we decided to stop changing packages :D) we need to
> change the subproject dependencies. If there is a big move needed by
> one of the subproject we will just need to release a milestone.
Agreed, for FtpServer we did depend on M1 for a while. However, we
then needed some stuff developed in M2-SNAPSHOT (for blacklisting) so
I had to depend on the snapshot version. As soon as M2 is available,
we will try to stick with that. I think we should attempt to get it
out fairly soon.
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
>
>> IMHO, IoEvent and IoEventType belongs to an event package, under the
>> session package.
>>
>>
>>
> IMO two classes are not enough reason to create a package.
True. Not a big deal to have those guys in session.
> Also we need to
> be careful about move too many things around needlessly. Remember each
> change you make will impact users.
>
I checked on asyncWeb, the burden is very minimum. Of course, you will
have to go through imports to get it work again, but this is not such a
big work.
The main advantage is that it brings a lot of clarity on MINA code !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> On Wed, 25 Jun 2008 09:16:17 +0200
> "Niklas Gustavsson" <ni...@protocol7.com> wrote:
>
>
>> On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
>> <jv...@archean.fr> wrote:
>>
>>> Thanks Emmanuel for the big commit, everything is compiling fine
>>> here. Everybody will need to rename there import in mina 2.0 apps.
>>>
>> Could we publish a new snapshot to the Maven repo? As it stands,
>> FtpServer wont build unless you build MINA on your own.
>>
>> I'm currently behind a firewall and unable to do the deployment
>> myself :-/
>>
>> /niklas
>>
> Hi
> Ok will try to do it today, anyway we got a problem ftpserver &
> asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
> this kind of problems, when we release next milestone (I suppose it can
> be done as soon we decided to stop changing packages :D) we need to
> change the subproject dependencies. If there is a big move needed by
> one of the subproject we will just need to release a milestone.
>
> WDYT ?
>
yep we should not depend on SNAPSHOTs in ftpserver and asyncweb. If we
need a new release, then it's easy to cut a M2, M3 etc...
It's just a matter of changing the pom.xml.
We also could create a meta-pom.xml (a pom.xml which just build all the
sub-project and MINA) in order to be able to build all the projects
together. Something like MINA-with-dependencies like what we have on
Directory.
> Julien
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Wed, 25 Jun 2008 09:16:17 +0200
"Niklas Gustavsson" <ni...@protocol7.com> wrote:
> On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
> <jv...@archean.fr> wrote:
> > Thanks Emmanuel for the big commit, everything is compiling fine
> > here. Everybody will need to rename there import in mina 2.0 apps.
>
> Could we publish a new snapshot to the Maven repo? As it stands,
> FtpServer wont build unless you build MINA on your own.
>
> I'm currently behind a firewall and unable to do the deployment
> myself :-/
>
> /niklas
Hi
Ok will try to do it today, anyway we got a problem ftpserver &
asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
this kind of problems, when we release next milestone (I suppose it can
be done as soon we decided to stop changing packages :D) we need to
change the subproject dependencies. If there is a big move needed by
one of the subproject we will just need to release a milestone.
WDYT ?
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
<jv...@archean.fr> wrote:
> Thanks Emmanuel for the big commit, everything is compiling fine here.
> Everybody will need to rename there import in mina 2.0 apps.
Could we publish a new snapshot to the Maven repo? As it stands,
FtpServer wont build unless you build MINA on your own.
I'm currently behind a firewall and unable to do the deployment myself :-/
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 24 Jun 2008 14:23:48 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
> Julien Vermillard wrote:
> > On Fri, 20 Jun 2008 16:19:11 +0200
> > Emmanuel Lecharny <el...@apache.org> wrote:
> >
> >
> >>>>> IMHO, IoEvent and IoEventType belongs to an event package, under
> >>>>> the session package.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> IMO two classes are not enough reason to create a package. Also
> >>>> we need to be careful about move too many things around
> >>>> needlessly. Remember each change you make will impact users.
> >>>>
> >>>> Alex
> >>>>
> >>>>
> >>> Hi,
> >>>
> >>> for session.event & session.config it's not enought for a package
> >>>
> >>>
> >> ok. Makes sense.
> >>
> >>> for write, it should go in session because it really tied to
> >>> session
> >>>
> >> session.write ?
> >>
> >>
> >>
> >>> Now I start to wonder why we got this "common" package perhaps all
> >>> that can go directly to o.a.mina root ?
> >>>
> >>>
> >> This will impact all the imports in ftpserver and asyncweb, but we
> >> can do it.
> >>
> >>
> >>> Julien
> >>>
> >>>
> >>>
> >>
> >
> > Thanks Emmanuel for the big commit, everything is compiling fine
> > here. Everybody will need to rename there import in mina 2.0 apps.
> >
> > Now I would like to discuss about the *.common.* package ? does we
> > need it ? I think no, it's increasing import length for no much
> > gain.
> Well, after having looked at the hierarchy, I think it would be
> better to keep this extra level, as you have filter, handler,
> transport and utils package on the same level than common.
>
> I would rather suggest we rename it to core, or keep common as a name.
>
> wdyt ?
>
+1 for renaming to core like the module
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> On Fri, 20 Jun 2008 16:19:11 +0200
> Emmanuel Lecharny <el...@apache.org> wrote:
>
>
>>>>> IMHO, IoEvent and IoEventType belongs to an event package, under
>>>>> the session package.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> IMO two classes are not enough reason to create a package. Also we
>>>> need to be careful about move too many things around needlessly.
>>>> Remember each change you make will impact users.
>>>>
>>>> Alex
>>>>
>>>>
>>> Hi,
>>>
>>> for session.event & session.config it's not enought for a package
>>>
>>>
>> ok. Makes sense.
>>
>>> for write, it should go in session because it really tied to session
>>>
>>>
>> session.write ?
>>
>>
>>
>>> Now I start to wonder why we got this "common" package perhaps all
>>> that can go directly to o.a.mina root ?
>>>
>>>
>> This will impact all the imports in ftpserver and asyncweb, but we
>> can do it.
>>
>>
>>> Julien
>>>
>>>
>>>
>>
>
> Thanks Emmanuel for the big commit, everything is compiling fine here.
> Everybody will need to rename there import in mina 2.0 apps.
>
> Now I would like to discuss about the *.common.* package ? does we need
> it ? I think no, it's increasing import length for no much gain.
>
Well, after having looked at the hierarchy, I think it would be better
to keep this extra level, as you have filter, handler, transport and
utils package on the same level than common.
I would rather suggest we rename it to core, or keep common as a name.
wdyt ?
> Julien
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Fri, 20 Jun 2008 16:19:11 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
>
> >>> IMHO, IoEvent and IoEventType belongs to an event package, under
> >>> the session package.
> >>>
> >>>
> >>>
> >> IMO two classes are not enough reason to create a package. Also we
> >> need to be careful about move too many things around needlessly.
> >> Remember each change you make will impact users.
> >>
> >> Alex
> >>
> >
> > Hi,
> >
> > for session.event & session.config it's not enought for a package
> >
> ok. Makes sense.
> > for write, it should go in session because it really tied to session
> >
> session.write ?
>
>
> > Now I start to wonder why we got this "common" package perhaps all
> > that can go directly to o.a.mina root ?
> >
> This will impact all the imports in ftpserver and asyncweb, but we
> can do it.
>
> > Julien
> >
> >
>
>
Thanks Emmanuel for the big commit, everything is compiling fine here.
Everybody will need to rename there import in mina 2.0 apps.
Now I would like to discuss about the *.common.* package ? does we need
it ? I think no, it's increasing import length for no much gain.
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
>>> IMHO, IoEvent and IoEventType belongs to an event package, under the
>>> session package.
>>>
>>>
>>>
>> IMO two classes are not enough reason to create a package. Also we
>> need to be careful about move too many things around needlessly.
>> Remember each change you make will impact users.
>>
>> Alex
>>
>
> Hi,
>
> for session.event & session.config it's not enought for a package
>
ok. Makes sense.
> for write, it should go in session because it really tied to session
>
session.write ?
> Now I start to wonder why we got this "common" package perhaps all that
> can go directly to o.a.mina root ?
>
This will impact all the imports in ftpserver and asyncweb, but we can
do it.
> Julien
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Fri, 20 Jun 2008 09:55:10 -0400
"Alex Karasulu" <ak...@apache.org> wrote:
> On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny
> <el...@apache.org> wrote:
>
> >
> >>
> > IMHO, IoEvent and IoEventType belongs to an event package, under the
> > session package.
> >
> >
> IMO two classes are not enough reason to create a package. Also we
> need to be careful about move too many things around needlessly.
> Remember each change you make will impact users.
>
> Alex
Hi,
for session.event & session.config it's not enought for a package
for write, it should go in session because it really tied to session
+1
for all the others
Now I start to wonder why we got this "common" package perhaps all that
can go directly to o.a.mina root ?
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
>
>>
> IMHO, IoEvent and IoEventType belongs to an event package, under the
> session package.
>
>
IMO two classes are not enough reason to create a package. Also we need to
be careful about move too many things around needlessly. Remember each
change you make will impact users.
Alex
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Julien,
I followed your proposal, and moved the classes into the proposed
packages, fixed a few visibility issues (protected methods and such).
More inline...
Julien Vermillard wrote:
> First thought about class in o.a.m.common :
>
> I tried to give a category for each class (buffer,service,future,etc..)
>
> IoBufferHexDumper.java buffer
> SimpleBufferAllocator.java buffer
> BufferDataException.java buffer
> IoBuffer.java buffer
> IoBufferWrapper.java buffer
> AbstractIoBuffer.java buffer
> IoBufferAllocator.java buffer
> CachedBufferAllocator.java buffer
>
Just perfect. The IoBufferHexDumper could simply be removed and a static
method can be define in utils instead.
> DefaultFileRegion.java file
> FileRegion.java file
>
+1
> IoFilter.java filterchain
> IoFilterLifeCycleException.java filterchain
> IoFilterChainBuilder.java filterchain
> IoFilterChain.java filterchain
> IoFilterEvent.java filterchain
> IoEvent.java filterchain
> IoFilterAdapter.java filterchain
> IoEventType.java filterchain
> UnknownMessageTypeException.java filterchain/demux
>
IMHO, IoEvent and IoEventType belongs to an event package, under the
session package.
UnknownMessageTypeException belongs to the session package, too.
> IoFuture.java future
> WriteFuture.java future
> DefaultCloseFuture.java future
> IoFutureListener.java future
> CloseFuture.java future
> CompositeIoFuture.java future
> ConnectFuture.java future
> DefaultWriteFuture.java future
> DefaultIoFuture.java future
> DefaultReadFuture.java future
> DefaultConnectFuture.java future
> ReadFuture.java future
>
Perfect.
> AbstractPollingIoConnector.java polling
> AbstractPollingIoAcceptor.java polling
> AbstractPollingIoProcessor.java polling
> AbstractPollingConnectionlessIoAcceptor.java polling
>
+1
> WriteToClosedSessionException.java service
> TransportMetadata.java service
> SimpleIoProcessorPool.java service
> NothingWrittenException.java service
> IoHandlerAdapter.java service
> IoHandler.java service
> IoProcessor.java service
> IoServiceListenerSupport.java service
> IoServiceListener.java service
> IoService.java service
> AbstractIoAcceptor.java service
> DefaultIoFilterChain.java service
> DefaultTransportMetadata.java service
> DefaultWriteRequest.java service
> AbstractIoConnector.java service
> AbstractIoService.java service
> DefaultIoFilterChainBuilder.java service
> ExpiringSessionRecycler.java service
> IoAcceptor.java service
> IoConnector.java service
>
DefaultIoFilterChain and DefaultIoFilterChainBuilder should be in filterchain, I think.
ExpiringSessionRecycler should be in session
DefaultWriteRequest should be in another package, with WriteRequest, WriteRequestQueue, WriteRequestWrapper, WriteTimeOutException and WriteToClosedSessionException.
> IdleStatus.java session
> WriteException.java session
> AttributeKey.java session
> AbstractIoSession.java session
> WriteRequestWrapper.java session
> WriteTimeoutException.java session
> DummySession.java session
> TrafficMask.java session
> WriteRequestQueue.java session
> WriteRequest.java session
> IoSessionDataStructureFactory.java session
> IoSessionInitializationException.java session
> IoSessionInitializer.java session
> DefaultIoSessionDataStructureFactory.java session
> IoSessionAttributeMap.java session
> IdleStatusChecker.java session
> IoSessionRecycler.java session
> IoSession.java session
>
For the two following files, I would create a sub package (config) :
AbstractIoSessionConfig.java session/config
IoSessionConfig.java session/config
I think that a 'write' package could be usefull too :
DefaultWriteRequest.java write
WriteException.java write
WriteRequest.java write
WriteRequestQueue.java write
WriteRequestWrapper.java write
WriteTimeOutException.java write
> DefaultExceptionMonitor.java ?
> RuntimeIoException.java ?
> IoUtil.java ?
> ExceptionMonitor.java ?
>
> Anyway this package is now bloated ;)
>
So we are close to something better. Should I commit the package
modifications ? Here is the new hierarchy :
./org/apache/mina/common/RuntimeIoException.java
./org/apache/mina/common/IoUtil.java
./org/apache/mina/common/ExceptionMonitor.java
./org/apache/mina/common/DefaultExceptionMonitor.java
./org/apache/mina/common/buffer/AbstractIoBuffer.java
./org/apache/mina/common/buffer/BufferDataException.java
./org/apache/mina/common/buffer/IoBuffer.java
./org/apache/mina/common/buffer/SimpleBufferAllocator.java
./org/apache/mina/common/buffer/CachedBufferAllocator.java
./org/apache/mina/common/buffer/IoBufferAllocator.java
./org/apache/mina/common/buffer/IoBufferWrapper.java
./org/apache/mina/common/buffer/IoBufferHexDumper.java
./org/apache/mina/common/file/DefaultFileRegion.java
./org/apache/mina/common/file/FileRegion.java
./org/apache/mina/common/filterchain/DefaultIoFilterChainBuilder.java
./org/apache/mina/common/filterchain/IoFilterEvent.java
./org/apache/mina/common/filterchain/IoFilterLifeCycleException.java
./org/apache/mina/common/filterchain/IoFilterAdapter.java
./org/apache/mina/common/filterchain/DefaultIoFilterChain.java
./org/apache/mina/common/filterchain/IoFilterChain.java
./org/apache/mina/common/filterchain/IoFilterChainBuilder.java
./org/apache/mina/common/filterchain/IoFilter.java
./org/apache/mina/common/future/ReadFuture.java
./org/apache/mina/common/future/DefaultWriteFuture.java
./org/apache/mina/common/future/DefaultCloseFuture.java
./org/apache/mina/common/future/DefaultReadFuture.java
./org/apache/mina/common/future/CompositeIoFuture.java
./org/apache/mina/common/future/DefaultConnectFuture.java
./org/apache/mina/common/future/ConnectFuture.java
./org/apache/mina/common/future/IoFutureListener.java
./org/apache/mina/common/future/WriteFuture.java
./org/apache/mina/common/future/CloseFuture.java
./org/apache/mina/common/future/DefaultIoFuture.java
./org/apache/mina/common/future/IoFuture.java
./org/apache/mina/common/polling/AbstractPollingIoProcessor.java
./org/apache/mina/common/polling/AbstractPollingIoAcceptor.java
./org/apache/mina/common/polling/AbstractPollingIoConnector.java
./org/apache/mina/common/polling/AbstractPollingConnectionlessIoAcceptor.java
./org/apache/mina/common/service/IoProcessor.java
./org/apache/mina/common/service/AbstractIoService.java
./org/apache/mina/common/service/IoAcceptor.java
./org/apache/mina/common/service/IoConnector.java
./org/apache/mina/common/service/IoHandlerAdapter.java
./org/apache/mina/common/service/SimpleIoProcessorPool.java
./org/apache/mina/common/service/IoService.java
./org/apache/mina/common/service/IoHandler.java
./org/apache/mina/common/service/IoServiceListenerSupport.java
./org/apache/mina/common/service/AbstractIoConnector.java
./org/apache/mina/common/service/IoServiceListener.java
./org/apache/mina/common/service/DefaultTransportMetadata.java
./org/apache/mina/common/service/AbstractIoAcceptor.java
./org/apache/mina/common/service/TransportMetadata.java
./org/apache/mina/common/session/TrafficMask.java
./org/apache/mina/common/session/IoSessionRecycler.java
./org/apache/mina/common/session/DummySession.java
./org/apache/mina/common/session/IdleStatus.java
./org/apache/mina/common/session/IoSessionInitializationException.java
./org/apache/mina/common/session/IoSessionAttributeMap.java
./org/apache/mina/common/session/DefaultIoSessionDataStructureFactory.java
./org/apache/mina/common/session/AbstractIoSession.java
./org/apache/mina/common/session/ExpiringSessionRecycler.java
./org/apache/mina/common/session/IoSessionInitializer.java
./org/apache/mina/common/session/AttributeKey.java
./org/apache/mina/common/session/IdleStatusChecker.java
./org/apache/mina/common/session/IoSession.java
./org/apache/mina/common/session/UnknownMessageTypeException.java
./org/apache/mina/common/session/IoSessionDataStructureFactory.java
./org/apache/mina/common/session/config/IoSessionConfig.java
./org/apache/mina/common/session/config/AbstractIoSessionConfig.java
./org/apache/mina/common/session/event/IoEvent.java
./org/apache/mina/common/session/event/IoEventType.java
./org/apache/mina/common/write/WriteRequest.java
./org/apache/mina/common/write/WriteToClosedSessionException.java
./org/apache/mina/common/write/WriteRequestQueue.java
./org/apache/mina/common/write/DefaultWriteRequest.java
./org/apache/mina/common/write/WriteException.java
./org/apache/mina/common/write/NothingWrittenException.java
./org/apache/mina/common/write/WriteTimeoutException.java
./org/apache/mina/common/write/WriteRequestWrapper.java
./org/apache/mina/common/RuntimeIoException.java
./org/apache/mina/common/IoUtil.java
./org/apache/mina/common/ExceptionMonitor.java
./org/apache/mina/common/DefaultExceptionMonitor.java
Any different POV ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
First thought about class in o.a.m.common :
I tried to give a category for each class (buffer,service,future,etc..)
IoBufferHexDumper.java buffer
SimpleBufferAllocator.java buffer
BufferDataException.java buffer
IoBuffer.java buffer
IoBufferWrapper.java buffer
AbstractIoBuffer.java buffer
IoBufferAllocator.java buffer
CachedBufferAllocator.java buffer
DefaultFileRegion.java file
FileRegion.java file
IoFilter.java filterchain
IoFilterLifeCycleException.java filterchain
IoFilterChainBuilder.java filterchain
IoFilterChain.java filterchain
IoFilterEvent.java filterchain
IoEvent.java filterchain
IoFilterAdapter.java filterchain
IoEventType.java filterchain
UnknownMessageTypeException.java filterchain/demux
IoFuture.java future
WriteFuture.java future
DefaultCloseFuture.java future
IoFutureListener.java future
CloseFuture.java future
CompositeIoFuture.java future
ConnectFuture.java future
DefaultWriteFuture.java future
DefaultIoFuture.java future
DefaultReadFuture.java future
DefaultConnectFuture.java future
ReadFuture.java future
AbstractPollingIoConnector.java polling
AbstractPollingIoAcceptor.java polling
AbstractPollingIoProcessor.java polling
AbstractPollingConnectionlessIoAcceptor.java polling
WriteToClosedSessionException.java service
TransportMetadata.java service
SimpleIoProcessorPool.java service
NothingWrittenException.java service
IoHandlerAdapter.java service
IoHandler.java service
IoProcessor.java service
IoServiceListenerSupport.java service
IoServiceListener.java service
IoService.java service
AbstractIoAcceptor.java service
DefaultIoFilterChain.java service
DefaultTransportMetadata.java service
DefaultWriteRequest.java service
AbstractIoConnector.java service
AbstractIoService.java service
DefaultIoFilterChainBuilder.java service
ExpiringSessionRecycler.java service
IoAcceptor.java service
IoConnector.java service
AbstractIoSessionConfig.java session
IdleStatus.java session
WriteException.java session
AttributeKey.java session
AbstractIoSession.java session
WriteRequestWrapper.java session
WriteTimeoutException.java session
DummySession.java session
TrafficMask.java session
WriteRequestQueue.java session
WriteRequest.java session
IoSessionDataStructureFactory.java session
IoSessionInitializationException.java session
IoSessionInitializer.java session
DefaultIoSessionDataStructureFactory.java session
IoSessionAttributeMap.java session
IoSessionConfig.java session
IdleStatusChecker.java session
IoSessionRecycler.java session
IoSession.java session
DefaultExceptionMonitor.java ?
RuntimeIoException.java ?
IoUtil.java ?
ExceptionMonitor.java ?
Anyway this package is now bloated ;)
BTW I'm out of office for 1 week.
Julien
On Mon, 09 Jun 2008 13:05:24 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
> Ok, ok, I have to admit that my proposal was not that good :)
>
> So let's move to something more sane, which seems to gather more
> approval : reviewing the packages we have in mina-core.
>
> More to come...
>
>
> Mark Webb wrote:
> > +1
> >
> > On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu
> > <ak...@apache.org> wrote:
> >> I don't really have a specific view point on this topic. I would
> >> rather have more efficient and easily maintained internals. I
> >> don't know if this accomplishes that but I'm sure you guys can
> >> hash that out.
> >>
> >> Regards,
> >> Alex
> >>
> >> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny
> >> <el...@apache.org> wrote:
> >>
> >>
> >>> Mark Webb wrote:
> >>>
> >>>
> >>>> I do not think this is a good idea.
> >>>>
> >>>>
> >>>>
> >>> Looking at the three answers, it seems so ;)
> >>>
> >>> 3. We may confuse things for alot of people who may already be
> >>> using
> >>>> 2.0. Telling users that they will have to fix their code
> >>>> because of a re-organization looks bad on our part IMHO.
> >>>>
> >>>>
> >>>>
> >>> Regardless to the refactoring question, this is the kind of risk
> >>> we have to consider, in any case. More than confusing the users
> >>> who have based their code on the current 2.0 stack, I think it's
> >>> much more important to build a coherent stack we will live with
> >>> for a long time. Waiting for a 3.0 version and differing
> >>> refactoring just because we have users of the current trunk is
> >>> certainly not a good idea. Trunk is trunk, using it is a risk,
> >>> and it's well know.
> >>>
> >>> Thanks !
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> --
> >>> cordialement, regards,
> >>> Emmanuel Lécharny
> >>> www.iktek.com
> >>> directory.apache.org
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>
[2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Ok, ok, I have to admit that my proposal was not that good :)
So let's move to something more sane, which seems to gather more
approval : reviewing the packages we have in mina-core.
More to come...
Mark Webb wrote:
> +1
>
> On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu <ak...@apache.org> wrote:
>
>> I don't really have a specific view point on this topic. I would rather
>> have more efficient and easily maintained internals. I don't know if this
>> accomplishes that but I'm sure you guys can hash that out.
>>
>> Regards,
>> Alex
>>
>> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny <el...@apache.org>
>> wrote:
>>
>>
>>> Mark Webb wrote:
>>>
>>>
>>>> I do not think this is a good idea.
>>>>
>>>>
>>>>
>>> Looking at the three answers, it seems so ;)
>>>
>>> 3. We may confuse things for alot of people who may already be using
>>>
>>>> 2.0. Telling users that they will have to fix their code because of a
>>>> re-organization looks bad on our part IMHO.
>>>>
>>>>
>>>>
>>> Regardless to the refactoring question, this is the kind of risk we have to
>>> consider, in any case. More than confusing the users who have based their
>>> code on the current 2.0 stack, I think it's much more important to build a
>>> coherent stack we will live with for a long time. Waiting for a 3.0 version
>>> and differing refactoring just because we have users of the current trunk is
>>> certainly not a good idea. Trunk is trunk, using it is a risk, and it's well
>>> know.
>>>
>>> Thanks !
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Mark Webb <el...@gmail.com>.
+1
On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu <ak...@apache.org> wrote:
> I don't really have a specific view point on this topic. I would rather
> have more efficient and easily maintained internals. I don't know if this
> accomplishes that but I'm sure you guys can hash that out.
>
> Regards,
> Alex
>
> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
>> Mark Webb wrote:
>>
>>> I do not think this is a good idea.
>>>
>>>
>> Looking at the three answers, it seems so ;)
>>
>> 3. We may confuse things for alot of people who may already be using
>>> 2.0. Telling users that they will have to fix their code because of a
>>> re-organization looks bad on our part IMHO.
>>>
>>>
>> Regardless to the refactoring question, this is the kind of risk we have to
>> consider, in any case. More than confusing the users who have based their
>> code on the current 2.0 stack, I think it's much more important to build a
>> coherent stack we will live with for a long time. Waiting for a 3.0 version
>> and differing refactoring just because we have users of the current trunk is
>> certainly not a good idea. Trunk is trunk, using it is a risk, and it's well
>> know.
>>
>> Thanks !
>>
>>
>>
>>
>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Alex Karasulu <ak...@apache.org>.
I don't really have a specific view point on this topic. I would rather
have more efficient and easily maintained internals. I don't know if this
accomplishes that but I'm sure you guys can hash that out.
Regards,
Alex
On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Mark Webb wrote:
>
>> I do not think this is a good idea.
>>
>>
> Looking at the three answers, it seems so ;)
>
> 3. We may confuse things for alot of people who may already be using
>> 2.0. Telling users that they will have to fix their code because of a
>> re-organization looks bad on our part IMHO.
>>
>>
> Regardless to the refactoring question, this is the kind of risk we have to
> consider, in any case. More than confusing the users who have based their
> code on the current 2.0 stack, I think it's much more important to build a
> coherent stack we will live with for a long time. Waiting for a 3.0 version
> and differing refactoring just because we have users of the current trunk is
> certainly not a good idea. Trunk is trunk, using it is a risk, and it's well
> know.
>
> Thanks !
>
>
>
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Mark Webb wrote:
> I do not think this is a good idea.
>
Looking at the three answers, it seems so ;)
> 3. We may confuse things for alot of people who may already be using
> 2.0. Telling users that they will have to fix their code because of a
> re-organization looks bad on our part IMHO.
>
Regardless to the refactoring question, this is the kind of risk we have
to consider, in any case. More than confusing the users who have based
their code on the current 2.0 stack, I think it's much more important to
build a coherent stack we will live with for a long time. Waiting for a
3.0 version and differing refactoring just because we have users of the
current trunk is certainly not a good idea. Trunk is trunk, using it is
a risk, and it's well know.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Mark Webb <el...@gmail.com>.
I do not think this is a good idea.
1. You are assuming that everyone uses maven.
2. Based on many of the discussions that have been going on with this
group, I believe that we have more important issues to consider.
3. We may confuse things for alot of people who may already be using
2.0. Telling users that they will have to fix their code because of a
re-organization looks bad on our part IMHO.
On Sun, Jun 8, 2008 at 3:26 PM, Emmanuel Lecharny <el...@apache.org> wrote:
> Niklas Gustavsson wrote:
>>
>> On Sat, Jun 7, 2008 at 2:59 PM, Emmanuel Lecharny <el...@apache.org>
>> wrote:
>>
>>>
>>> Thoughts ?
>>>
>>
>> My feeling is that the cons outweigh the pros. Having multiple JARs
>> commonly turns out to confuse users, especially with a setup where you
>> can even get the very basic functionality working without choosing
>> your combination of JARs.
>
> With Maven, this is not really a big issue, IMHO. Consider that it's a one
> time burden...
>
> Now, if it degenerate to a dozens of jars, yes, I + your point.
>
> But even if we keep only one jar, I think we still have to create some new
> packages, because we have a big bag of classes in common, which make it
> quite difficult to find what are the relations between each classes.
>>
>> In addition, the current core JAR is about
>> 500 kb, not huge.
>>
>
> I didn't even mentioned the size in the pros ;)
>
> thanks !
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Alex Karasulu <ak...@apache.org>.
Ersin,
Thanks for suggesting this. This is exactly what I was thinking could help
both camps. Many projects have a xxx-foo.jar, xxx-bar.jar and an
xxx-all.jar which contains all packages. This also helps for OSGi'fication.
Alex
On Tue, Jun 10, 2008 at 8:51 AM, Ersin Er <er...@gmail.com> wrote:
> Hi,
>
> I would suggest having both a monolithic and a set of modular packages just
> as Spring Framework distribution has. Of course from the developers point
> of
> view there should be more packages and projects to make things more
> decoupled and understandable. They can all be compiled into separate jars
> and also can be assembled into one big jar.
>
> Greetings,
>
> Ersin Er
> http://www.ersin-er.name
>
> On Tue, Jun 10, 2008 at 10:31, Emmanuel Lecharny <el...@gmail.com>
> wrote:
>
> > 'Multiple' starts at 2 ;)
> >
> > I would suggest we start by reorganizing the packages first, and then
> > we may see if it really makes sense to split mina-core in 2 (or 3 ;)
> >
> > Thanks !
> >
> > On Tue, Jun 10, 2008 at 5:25 AM, Mike Heath <mh...@apache.org> wrote:
> > > I agree with Maarten and Julien, multiple packages may make sense but I
> > > don't see any value to multiple jars at this point.
> > >
> > > We had talked about separating IoBuffer and a few other other base
> > classes
> > > that might have utility outside of MINA into their own jar at one
> point.
> > I
> > > still like this idea.
> > >
> > > -Mike
> > >
> > > Julien Vermillard wrote:
> > >>
> > >> Hi,
> > >> look like I agree with Maarten,
> > >>
> > >> the common package is bloated, we need to split in some packages.
> > >>
> > >> For multiple jar, I'm using maven it's not too much burden for me, but
> > >> it's hard to see the advantage for that move.
> > >>
> > >> Julien
> > >>
> > >> On Sun, 8 Jun 2008 22:07:28 +0200
> > >> "Maarten Bosteels" <mb...@gmail.com> wrote:
> > >>
> > >>
> > >>>
> > >>> Hi,
> > >>>
> > >>> I fail to see strong advantages of having multiple jars.
> > >>> Having more packages seems like a good idea though.
> > >>>
> > >>> Maarten.
> > >>>
> > >>> On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson
> > >>> <ni...@protocol7.com> wrote:
> > >>>
> > >>>>
> > >>>> On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny
> > >>>> <el...@apache.org> wrote:
> > >>>>
> > >>>>>
> > >>>>> Niklas Gustavsson wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> My feeling is that the cons outweigh the pros. Having multiple
> > >>>>>> JARs commonly turns out to confuse users, especially with a setup
> > >>>>>> where you can even get the very basic functionality working
> > >>>>>> without choosing your combination of JARs.
> > >>>>>>
> > >>>>>
> > >>>>> With Maven, this is not really a big issue, IMHO. Consider that
> > >>>>> it's a one time burden...
> > >>>>>
> > >>>>
> > >>>> My worry is not around how to perform the actual work setting things
> > >>>> up, but rather how much a potential consumer would have to
> > >>>> understand about MINA before she can get going.
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> But even if we keep only one jar, I think we still have to create
> > >>>>> some new packages, because we have a big bag of classes in common,
> > >>>>> which make it quite difficult to find what are the relations
> > >>>>> between each classes.
> > >>>>>
> > >>>>
> > >>>> I certainly agree.
> > >>>>
> > >>>> /niklas
> > >>>>
> > >>>>
> > >
> > >
> >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Ersin Er <er...@gmail.com>.
Hi,
I would suggest having both a monolithic and a set of modular packages just
as Spring Framework distribution has. Of course from the developers point of
view there should be more packages and projects to make things more
decoupled and understandable. They can all be compiled into separate jars
and also can be assembled into one big jar.
Greetings,
Ersin Er
http://www.ersin-er.name
On Tue, Jun 10, 2008 at 10:31, Emmanuel Lecharny <el...@gmail.com>
wrote:
> 'Multiple' starts at 2 ;)
>
> I would suggest we start by reorganizing the packages first, and then
> we may see if it really makes sense to split mina-core in 2 (or 3 ;)
>
> Thanks !
>
> On Tue, Jun 10, 2008 at 5:25 AM, Mike Heath <mh...@apache.org> wrote:
> > I agree with Maarten and Julien, multiple packages may make sense but I
> > don't see any value to multiple jars at this point.
> >
> > We had talked about separating IoBuffer and a few other other base
> classes
> > that might have utility outside of MINA into their own jar at one point.
> I
> > still like this idea.
> >
> > -Mike
> >
> > Julien Vermillard wrote:
> >>
> >> Hi,
> >> look like I agree with Maarten,
> >>
> >> the common package is bloated, we need to split in some packages.
> >>
> >> For multiple jar, I'm using maven it's not too much burden for me, but
> >> it's hard to see the advantage for that move.
> >>
> >> Julien
> >>
> >> On Sun, 8 Jun 2008 22:07:28 +0200
> >> "Maarten Bosteels" <mb...@gmail.com> wrote:
> >>
> >>
> >>>
> >>> Hi,
> >>>
> >>> I fail to see strong advantages of having multiple jars.
> >>> Having more packages seems like a good idea though.
> >>>
> >>> Maarten.
> >>>
> >>> On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson
> >>> <ni...@protocol7.com> wrote:
> >>>
> >>>>
> >>>> On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny
> >>>> <el...@apache.org> wrote:
> >>>>
> >>>>>
> >>>>> Niklas Gustavsson wrote:
> >>>>>
> >>>>>>
> >>>>>> My feeling is that the cons outweigh the pros. Having multiple
> >>>>>> JARs commonly turns out to confuse users, especially with a setup
> >>>>>> where you can even get the very basic functionality working
> >>>>>> without choosing your combination of JARs.
> >>>>>>
> >>>>>
> >>>>> With Maven, this is not really a big issue, IMHO. Consider that
> >>>>> it's a one time burden...
> >>>>>
> >>>>
> >>>> My worry is not around how to perform the actual work setting things
> >>>> up, but rather how much a potential consumer would have to
> >>>> understand about MINA before she can get going.
> >>>>
> >>>>
> >>>>>
> >>>>> But even if we keep only one jar, I think we still have to create
> >>>>> some new packages, because we have a big bag of classes in common,
> >>>>> which make it quite difficult to find what are the relations
> >>>>> between each classes.
> >>>>>
> >>>>
> >>>> I certainly agree.
> >>>>
> >>>> /niklas
> >>>>
> >>>>
> >
> >
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
'Multiple' starts at 2 ;)
I would suggest we start by reorganizing the packages first, and then
we may see if it really makes sense to split mina-core in 2 (or 3 ;)
Thanks !
On Tue, Jun 10, 2008 at 5:25 AM, Mike Heath <mh...@apache.org> wrote:
> I agree with Maarten and Julien, multiple packages may make sense but I
> don't see any value to multiple jars at this point.
>
> We had talked about separating IoBuffer and a few other other base classes
> that might have utility outside of MINA into their own jar at one point. I
> still like this idea.
>
> -Mike
>
> Julien Vermillard wrote:
>>
>> Hi,
>> look like I agree with Maarten,
>>
>> the common package is bloated, we need to split in some packages.
>>
>> For multiple jar, I'm using maven it's not too much burden for me, but
>> it's hard to see the advantage for that move.
>>
>> Julien
>>
>> On Sun, 8 Jun 2008 22:07:28 +0200
>> "Maarten Bosteels" <mb...@gmail.com> wrote:
>>
>>
>>>
>>> Hi,
>>>
>>> I fail to see strong advantages of having multiple jars.
>>> Having more packages seems like a good idea though.
>>>
>>> Maarten.
>>>
>>> On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson
>>> <ni...@protocol7.com> wrote:
>>>
>>>>
>>>> On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny
>>>> <el...@apache.org> wrote:
>>>>
>>>>>
>>>>> Niklas Gustavsson wrote:
>>>>>
>>>>>>
>>>>>> My feeling is that the cons outweigh the pros. Having multiple
>>>>>> JARs commonly turns out to confuse users, especially with a setup
>>>>>> where you can even get the very basic functionality working
>>>>>> without choosing your combination of JARs.
>>>>>>
>>>>>
>>>>> With Maven, this is not really a big issue, IMHO. Consider that
>>>>> it's a one time burden...
>>>>>
>>>>
>>>> My worry is not around how to perform the actual work setting things
>>>> up, but rather how much a potential consumer would have to
>>>> understand about MINA before she can get going.
>>>>
>>>>
>>>>>
>>>>> But even if we keep only one jar, I think we still have to create
>>>>> some new packages, because we have a big bag of classes in common,
>>>>> which make it quite difficult to find what are the relations
>>>>> between each classes.
>>>>>
>>>>
>>>> I certainly agree.
>>>>
>>>> /niklas
>>>>
>>>>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Mike Heath <mh...@apache.org>.
I agree with Maarten and Julien, multiple packages may make sense but I
don't see any value to multiple jars at this point.
We had talked about separating IoBuffer and a few other other base
classes that might have utility outside of MINA into their own jar at
one point. I still like this idea.
-Mike
Julien Vermillard wrote:
> Hi,
> look like I agree with Maarten,
>
> the common package is bloated, we need to split in some packages.
>
> For multiple jar, I'm using maven it's not too much burden for me, but
> it's hard to see the advantage for that move.
>
> Julien
>
> On Sun, 8 Jun 2008 22:07:28 +0200
> "Maarten Bosteels" <mb...@gmail.com> wrote:
>
>
>> Hi,
>>
>> I fail to see strong advantages of having multiple jars.
>> Having more packages seems like a good idea though.
>>
>> Maarten.
>>
>> On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson
>> <ni...@protocol7.com> wrote:
>>
>>> On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny
>>> <el...@apache.org> wrote:
>>>
>>>> Niklas Gustavsson wrote:
>>>>
>>>>> My feeling is that the cons outweigh the pros. Having multiple
>>>>> JARs commonly turns out to confuse users, especially with a setup
>>>>> where you can even get the very basic functionality working
>>>>> without choosing your combination of JARs.
>>>>>
>>>> With Maven, this is not really a big issue, IMHO. Consider that
>>>> it's a one time burden...
>>>>
>>> My worry is not around how to perform the actual work setting things
>>> up, but rather how much a potential consumer would have to
>>> understand about MINA before she can get going.
>>>
>>>
>>>> But even if we keep only one jar, I think we still have to create
>>>> some new packages, because we have a big bag of classes in common,
>>>> which make it quite difficult to find what are the relations
>>>> between each classes.
>>>>
>>> I certainly agree.
>>>
>>> /niklas
>>>
>>>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
Hi,
look like I agree with Maarten,
the common package is bloated, we need to split in some packages.
For multiple jar, I'm using maven it's not too much burden for me, but
it's hard to see the advantage for that move.
Julien
On Sun, 8 Jun 2008 22:07:28 +0200
"Maarten Bosteels" <mb...@gmail.com> wrote:
> Hi,
>
> I fail to see strong advantages of having multiple jars.
> Having more packages seems like a good idea though.
>
> Maarten.
>
> On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson
> <ni...@protocol7.com> wrote:
> > On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny
> > <el...@apache.org> wrote:
> >> Niklas Gustavsson wrote:
> >>> My feeling is that the cons outweigh the pros. Having multiple
> >>> JARs commonly turns out to confuse users, especially with a setup
> >>> where you can even get the very basic functionality working
> >>> without choosing your combination of JARs.
> >>
> >> With Maven, this is not really a big issue, IMHO. Consider that
> >> it's a one time burden...
> >
> > My worry is not around how to perform the actual work setting things
> > up, but rather how much a potential consumer would have to
> > understand about MINA before she can get going.
> >
> >> But even if we keep only one jar, I think we still have to create
> >> some new packages, because we have a big bag of classes in common,
> >> which make it quite difficult to find what are the relations
> >> between each classes.
> >
> > I certainly agree.
> >
> > /niklas
> >
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Maarten Bosteels <mb...@gmail.com>.
Hi,
I fail to see strong advantages of having multiple jars.
Having more packages seems like a good idea though.
Maarten.
On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny <el...@apache.org> wrote:
>> Niklas Gustavsson wrote:
>>> My feeling is that the cons outweigh the pros. Having multiple JARs
>>> commonly turns out to confuse users, especially with a setup where you
>>> can even get the very basic functionality working without choosing
>>> your combination of JARs.
>>
>> With Maven, this is not really a big issue, IMHO. Consider that it's a one
>> time burden...
>
> My worry is not around how to perform the actual work setting things
> up, but rather how much a potential consumer would have to understand
> about MINA before she can get going.
>
>> But even if we keep only one jar, I think we still have to create some new
>> packages, because we have a big bag of classes in common, which make it
>> quite difficult to find what are the relations between each classes.
>
> I certainly agree.
>
> /niklas
>
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny <el...@apache.org> wrote:
> Niklas Gustavsson wrote:
>> My feeling is that the cons outweigh the pros. Having multiple JARs
>> commonly turns out to confuse users, especially with a setup where you
>> can even get the very basic functionality working without choosing
>> your combination of JARs.
>
> With Maven, this is not really a big issue, IMHO. Consider that it's a one
> time burden...
My worry is not around how to perform the actual work setting things
up, but rather how much a potential consumer would have to understand
about MINA before she can get going.
> But even if we keep only one jar, I think we still have to create some new
> packages, because we have a big bag of classes in common, which make it
> quite difficult to find what are the relations between each classes.
I certainly agree.
/niklas
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Niklas Gustavsson wrote:
> On Sat, Jun 7, 2008 at 2:59 PM, Emmanuel Lecharny <el...@apache.org> wrote:
>
>> Thoughts ?
>>
>
> My feeling is that the cons outweigh the pros. Having multiple JARs
> commonly turns out to confuse users, especially with a setup where you
> can even get the very basic functionality working without choosing
> your combination of JARs.
With Maven, this is not really a big issue, IMHO. Consider that it's a
one time burden...
Now, if it degenerate to a dozens of jars, yes, I + your point.
But even if we keep only one jar, I think we still have to create some
new packages, because we have a big bag of classes in common, which make
it quite difficult to find what are the relations between each classes.
> In addition, the current core JAR is about
> 500 kb, not huge.
>
I didn't even mentioned the size in the pros ;)
thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Jun 7, 2008 at 2:59 PM, Emmanuel Lecharny <el...@apache.org> wrote:
> Thoughts ?
My feeling is that the cons outweigh the pros. Having multiple JARs
commonly turns out to confuse users, especially with a setup where you
can even get the very basic functionality working without choosing
your combination of JARs. In addition, the current core JAR is about
500 kb, not huge.
/niklas