Hi all,

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)

While I'm looking for the Apache projects which uses EasyMock to clarify
some license issue with MIT-license, I've found that Tapestry team adopted
Ant + Forrest instead of Maven. This way has an apparent advantage for MINA:

1) We can easily package multiprojects into one tarball.

2) We can generate various versions of multiprojects; mina-all, mina-core,
mina-ssl, ... And, we can distribute all the JARs in one tarball with no
effort.

3) We don't need to worry about generating one site documentation for
multiprojects such as delegating JavaDocs and other reports.

4) Forrest provides better document generation.

There are some downside for it, too:

1) We cannot use Maven repository. Actually we can, but we have to assume
that Maven Ant bridge is installed for a user's computer.

2) We cannot use Maven deployment feature.

But I think this is OK because we can just use Maven-Ant bridge or JAM (
http://www.javagen.com/jam/index.html).

WDYT?

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

[ Post a follow-up to this message ]

Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a =E9crit :

> Hi all,
>
> 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 ha=
ve
> to bother Maven team and manuals to build a satistifiable build system fo=
r
> MINA (and of course for other projects of us)

I looked at Maven 2 too, and came to the same conclusion. It is unusable un=
til
documentation improves.

> While I'm looking for the Apache projects which uses EasyMock to clarify
> some license issue with MIT-license, I've found that Tapestry team adopte=
d
> Ant + Forrest instead of Maven. This way has an apparent advantage for MI=
NA:
>
> 1) We can easily package multiprojects into one tarball.
>
> 2) We can generate various versions of multiprojects; mina-all, mina-core=
,
> mina-ssl, ... And, we can distribute all the JARs in one tarball with no
> effort.
>
> 3) We don't need to worry about generating one site documentation for
> multiprojects such as delegating JavaDocs and other reports.
>
> 4) Forrest provides better document generation.
>
> There are some downside for it, too:
>
> 1) We cannot use Maven repository. Actually we can, but we have to assume
> that Maven Ant bridge is installed for a user's computer.
>
> 2) We cannot use Maven deployment feature.
>
> But I think this is OK because we can just use Maven-Ant bridge or JAM (
> http://www.javagen.com/jam/index.html).
>
> WDYT?
>

I think Ivy is also worth taking a look at:

http://jayasoft.org/ivy/doc/comparison

I always hear good feedback from users.

Cheers,

J-F

[ Post a follow-up to this message ]

Hi J-F,

2005/11/15, daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org <daune.jf-/BlEExAzoZb
jMQX/wY3yqAC/G2K4zDHf@public.gmane.org>:
>
> I think Ivy is also worth taking a look at:
>
> http://jayasoft.org/ivy/doc/comparison
>
> I always hear good feedback from users.


Thank you for the heads up. I'll definitely look into it.

Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

[ Post a follow-up to this message ]

daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org wrote:

>
> I think Ivy is also worth taking a look at:
>
> http://jayasoft.org/ivy/doc/comparison
>
> I always hear good feedback from users.


Ivy is indeed quite good. It does what it should do.

I'm using it when I can, but documentation unfortunately lags 100 miles
behind. I not only it is incomplete but I also find the explanation a
bit too confusing most of the times and certainly worth an ounce of
example rather than a pound of words.  Finding your answer is actually a
bit challenging, this is why I'm still in a "prototype" mode and
certainly using 10% of its features.

That said, it does not get in my way, which is one of the very first
thing I'm asking for a tool

[ Post a follow-up to this message ]

On 11/15/05, Stephane Bailliez <sbailliez-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:[vb
col=seagreen]
> daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org wrote:
> 
>
>
> Ivy is indeed quite good. It does what it should do.
>
> I'm using it when I can, but documentation unfortunately lags 100 miles
> behind.[/vbcol]

This was the impression I got from users as well.

There was some discussion about this on the Maven Users list a couple
of months back... this reminded me to put that thread together. Here
is a more up to date comparison of feautres (the link above is from
February before Maven was released)

http://docs.codehaus.org/display/MA...ure+Comparisons

We're actually finding a few people are starting to use the Maven ant
tasks now for their dependency management without converting the
build.

Cheers,
Brett

[ Post a follow-up to this message ]

On 11/15/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi all,
>
> 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 ha=
ve
> to bother Maven team and manuals to build a satistifiable build system fo=
r
> 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?

BTW, we don't mind being bothered 

> 1) We can easily package multiprojects into one tarball.
>

I assume you mean for the site - this is something I want to focus on
soon - I was thinking ApacheCon would be a good time to do some
discussion 

You can at least use the same ant tags you'd have used anyway inside
the maven build.

> 2) We can generate various versions of multiprojects; mina-all, mina-core=
,
> mina-ssl, ... And, we can distribute all the JARs in one tarball with no
> effort.

can be done in Maven quite simply.

> 3) We don't need to worry about generating one site documentation for
> multiprojects such as delegating JavaDocs and other reports.

Not sure how this is different to 1)?

>
> 4) Forrest provides better document generation.

No doubt, it is a publishing system  Maven's focus is simple and
integrated documentation (even if it isn't quite there in the new
system)

> There are some downside for it, too:
>
> 1) We cannot use Maven repository.  Actually we can, but we have to assum=
e
> that Maven Ant bridge is installed for a user's computer.

well, you could put it in SVN... 

> 2) We cannot use Maven deployment feature.
>
> But I think this is OK because we can just use Maven-Ant bridge or JAM (
> http://www.javagen.com/jam/index.html).
>

If you use the Maven ant tasks, you will still need to write a POM so
that transitive dependencies work for other projects that depend on it
(like Geronimo).

Can I add some others downsides?

- you'd miss out on Alex's recent work on a confluence -> maven doc convert=
er
- you'd miss out on the osgi plugin (could be a bigger problem for
other parts of the project)
- you'd miss out on the other Maven features you are using like simple
tools integration (emma) and reporting, etc

> WDYT?

Well, I'm biased, but I think it is premature.

I'd like to know the exact concerns you have. Documentation is one,
I've recently added back the getting started guide sections that gave
an overview so maybe that will help.

I'd be very concerned if it was difficult to build any of the projects
here given all the plugins and dependencies are available. Especially
mina, which already builds (I've just updated it in line with the m1
build).

I think its worth breaking down into the sections that you are trying
to address (build, dependencies, site) and decide what a suitable tool
is for each. If you find a particular tool does do a good job when it
is in use, from a Maven perspective I'd be interested to hear your
comparitive experiences.

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.

Anyway, let me know if there is anything I can do to help.

- Brett

[ Post a follow-up to this message ]

Brett Porter wrote:

>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.
>
>
It looks crystal clear to me that MINA goes way beyond Directory and is
going into its own direction. Directory kind of served as an incubator
exactly the way Tomcat did for Ant or Digester, or Struts did for
commons-validator, etc...

There's nothing bad from that, it is a very good thing as it helps make
it more robust due to a wider audience as MINA is bound to be integrated
with just about anything that requires such a communication framework.

[ Post a follow-up to this message ]

Brett Porter wrote:[vbcol=seagreen]
> On 11/15/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
 wrote:
> 

Trustin,

I am finding Maven 2 to be many times better than Maven 1 and I have
been moving in the direction that we were going to use Maven 2 on
Directory.  I'm not sure what you're looking for for documentation, but
I've figured out what I've needed from looking at other POM examples,
notably the ones in Plexus and Maven 2 SVN, and from directly asking
Brett Maven 2 questions on IRC.  For functionality not yet in Maven 2 I
have been writing plugins (in Java), which I never did for Maven 1 on
account of Jelly.

I only have 1 data point and no personal experience with Ivy, but over
on the Felix project, one user stated coming from the Ivy/Ant setup to
Maven 2/OSGi and finding "My whole development workflow is light years
ahead of my previous ant/nano container/ivy environment."

Enrique

[ Post a follow-up to this message ]

Hi Brett,

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

2005/11/15, Brett Porter <brett.porter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> projects. 
> have 
> for 
>
> 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
[url]http://www.ibiblio.org/maven/org.slf4j/jars/jcl104-over-slf4j-1.0-beta9.jaris[/url
]
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/

[ Post a follow-up to this message ]

On 11/16/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I'd like to split MINA into multiple Maven subprojects:
>
> * mina-core
> * mina-extension-ssl
> * mina-integration-spring
> * mina-integration-netty

sounds like a good plan.

>
> 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

all can be done with the assembly plugin (descriptorId
jar-with-dependencies) - an example is maven-artifact-ant in the maven
repository.

>
> Plus 'mvn dist' will have to generate two tarballs:
>
> * mina-<version>.tar.gz
> * mina-src-<version>.tar.gz

Also the assembly plugin -the default should suite (descriptorId of
bin and src respectively).

> 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, ...

Aggregation in the site is where we need to improve support (though m1
didn't do it either). Custom solution or working with us on it will be
required here. Each plugin needs some extra support to do this I think
- eg clover needs to merge databases, javadoc needs to pull in
multiple source directories.

>
> 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.

I'm not sure what you mean here about two streams (dev and release?).
If its what I'm tinhking, I agree. Release included/specific docs in
the project, static site that is independant (faq, news, etc) is a
separate project. reports are on the project, and only on the dev
version.

> 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 Sprin=
g
> 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.sl...4j-1.0-beta9.j=
ar
> is the same one with commons-logging-1.0.4.jar.  Please let me know if we
> can do so with M2.

That specific feature is planned for maven 2.1, but the way you do it now i=
s:

<dependency>
..
<artifactId>spring-core</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>

> 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.  Th=
at
> causes some build errors in Eclipse unfortunately.  I did work fine with =
M1.

I'm not familiar with that issue - can you ensure it has been reported?

Thanks,
- Brett

[ Post a follow-up to this message ]