directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [mina] Using Ant + Forrest like Tapestry team does.
Date Tue, 15 Nov 2005 13:32:14 GMT
Hi Brett,

Thank you for your great will to help us first of all. :)

2005/11/15, Brett Porter <brett.porter@gmail.com>:
>
> > I've been playing with Maven 2 and splitting MINA into multiple
> projects.
> > But at this time, Maven 2 documentation is far from perfection, and we
> have
> > to bother Maven team and manuals to build a satistifiable build system
> for
> > MINA (and of course for other projects of us)
>
> Can you elaborate on this? Regardless of what you decide here, I'd
> like to get your feedback on how it can be improved as there has been
> a lot of work on it recently and that is continuing.
>
> Have you seen the new documentation section that came with 2.0?


Yes, but some plugins have blank fields in its documentation. And I don't
know how to do to fulfill my need with Maven yet.

I'll explain you what I want to do:

I'd like to split MINA into multiple Maven subprojects:

* mina-core
* mina-extension-ssl
* mina-integration-spring
* mina-integration-netty

I'd like to generate the five JARs when I run 'mvn package':

* mina-all-<version>.jar, which contains classes from all subprojects
* mina-core-<version>.jar
* mina-extension-ssl-<version>.jar
* mina-integration-spring-<version>.jar
* mina-integration-netty-<version>.jar

Plus 'mvn dist' will have to generate two tarballs:

* mina-<version>.tar.gz
* mina-src-<version>.tar.gz

For documentation, running 'mvn site' will have to generate one site
documentation that provides:

* A single site like we ran 'mvn' site for one project; one JavaDoc, one
coverage report, ...

I think the site should be splitted to a separate project because we have
two stream and have to provide documentation for both at one site.

WDYT?

- you'd miss out on Alex's recent work on a confluence -> maven doc
> converter


I thought we can port it easily.

- you'd miss out on the osgi plugin (could be a bigger problem for
> other parts of the project)


Yes, that is perhaps a problem. I don't know much about OSGi. Enrique, could
you help me out here?

- you'd miss out on the other Maven features you are using like simple
> tools integration (emma) and reporting, etc


EMMA provides Ant task, and I think I have more control over EMMA with Ant
because I can make it doesn't run instrumentation process every time I
compile source code like Maven does. And MINA doesn't use much reporting
AFAIK:

* XRef
* JavaDoc
* EMMA

And I think there's some dependency issue for M2, too. It is because we're
using SLF4J and Spring framework at the same time and M2 provides an
indirect dependency resolver. SLF4J provides a jar which eases migration
from commons-logging. It has the exact API with what commons-logging has,
but it simply forwards all calls to SLF4J actually. But the POM of Spring
framework is saying it depends on commons-logging. M2 will retrieve
commons-logging, but it shouldn't for MINA. There should be some way to
specify
http://www.ibiblio.org/maven/org.slf4j/jars/jcl104-over-slf4j-1.0-beta9.jaris
the same one with
commons-logging-1.0.4.jar. Please let me know if we can do so with M2.

Back on topic, one thing that is important is that it is consistent
> with the rest of the project. MINA seems almost like a little island
> within Directory at the moment. It shouldn't go one direction that the
> rest of the project isn't going to take.


You're right. That's why we're asking questions to the list. :)

I hope this clarified our concern.

Cheers,
Trustin

PS: BTW I've found a bug that an eclipse project file generated by 'mvn
eclipse:eclipse' didn't include all JARs in the JRE such as jsse.jar. That
causes some build errors in Eclipse unfortunately. I did work fine with M1.
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message