On 10/25/06, Trustin Lee <[EMAIL PROTECTED]> 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.
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.
May I just request that we take a step back and focus on the real
issue. The real pain in the current project structure IMO is the
recompilation needed to use the java5 construct usage, which will go
away after the move to java5. Apart from that, I don't think it's
really an issue to use multiple jars. I doubt there would be anyone
using all of the different MINA jar's at the moment.
For more convenient IDE browsing and some user friendliness I don't
think its fair to force jars / dependencies on users. I wrongly said
that the scope should be 'compile' in the pom, as you pointed out, it
should be 'provided'. I for one don't want to have spring, jmx, netty
etc when I can do without them.
A middle ground would be to use a maven plugin like uberjar to allow
users to build a single consolidated jar. This could also be put up
for download on the releases page.
Regards,
Vinod.
