Am 19.03.2013 11:02, schrieb Emmanuel Lécharny:
Le 3/19/13 10:20 AM, Arnaud bourree a écrit :
2013/3/19 Emmanuel Lécharny <[email protected]>:
Le 3/19/13 3:00 AM, sebb a écrit :
I mean, this is something we might have to deal with. I know that we
are taking all our time to get Mina 3 our, so that we are sure every
one will have switched to another NIO lib in the mean time, but still
... ;-)
If you rename the Java package you also need to change the Maven
coordinates (and vice versa).
Otherwise there will be classloading issues.
Laoding two jars with the same group/same artifactId is quite a
challenge with maven anyway :)
So, yes, we will have to rename the maven artifactId too.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
-1
my opinion whatever I'm not commiter:
Sure with framework like OSGi you can have separate class-loader, but
other to move out conflict, but otherelse that is bad idea to try to
made two libraries versions working together in a same application:
- If you used a 3rd part library which used Mina2 and you want to used
Mina3: forget Mina3 and do it with Mina2
- if you used 2 or more 3rd part libraries which used different major
versions of Mina: invest time in 3rd par library with oldest version
to propose patch with newest version.
Sometime, you just have no choice...
It would be extermely painful to be forced to keep working with an old
version just because a third party library is necessary, even if it's
not a critical part of your application...
Try using something like RMIClassloader maybe help with this problem
but wouldn't it be better to provide a compatibility layer for mina3 ?
in my opinion the rename does not realy help, if there are bugs in util
classes or for those who patch mina
with own code the have now to patch two versions
are the changes so bad that a partial rename or creating a new module is
not easyer?
