Thank you for your great will to help us first of all. :)
2005/11/15, Brett Porter <[EMAIL PROTECTED]>:
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?
I thought we can port it easily.
Yes, that is perhaps a problem. I don't know much about OSGi. Enrique, could you help me out here?
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.jar is the same one with commons-logging-1.0.4.jar. Please let me know if we can do so with M2.
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.
-- > 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.jar is 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/
