Apache Directory Project - [mina] Using Ant + Forrest like Tapestry team does.

Author

[mina] Using Ant + Forrest like Tapestry team does.

Trustin Lee

2005-11-15, 2:45 am

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/

daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@publ

2005-11-15, 2:45 am

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

Trustin Lee

2005-11-15, 5:45 pm

Hi J-F,

2005/11/15, daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org <daune.jf-/BlEExAzoZbjMQX/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/

Stephane Bailliez

2005-11-15, 5:45 pm

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

Brett Porter

2005-11-15, 5:45 pm

On 11/15/05, Stephane Bailliez <sbailliez-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> 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.

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

Brett Porter

2005-11-15, 5:45 pm

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

Stephane Bailliez

2005-11-15, 5:45 pm

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.

Enrique Rodriguez

2005-11-15, 5:45 pm

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

Trustin Lee

2005-11-15, 5:45 pm

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
http://www.ibiblio.org/maven/org.sl...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/

Brett Porter

2005-11-15, 5:45 pm

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

John E. Conlon

2005-11-15, 8:45 pm

> on the Felix project, one user stated coming from the Ivy/Ant setup...

Also (this user - yours truely) is currently using Apache Forrest for
internal project documentation as well.

My comment on 'light years' relates to the simplified approach to the
build that the central pom.xml of the M2-osgi-plugin gives me as well as
the ease of deployment/upgrade of OSGi bundles. The comment was by no
means meant as a knock against any of the other technologies. On the
contrary Ivy* and Forrest** each in its own sphere can accomplish more
than M2 for dependency management and documentation respectively. But
learning, keeping current, and maintaining the infrastructure has been a
challenge. Now I am still kicking the tires with M2/OSGi and have not
yet migrated my projects to from Ant/Ivy,Forrest, but I am hopeful that
if I need something special I could use the M2 plugin technology (now
Java based) to integrate with one or more of these technologies to get
what I currently have but in a more integrated fashion.

* Jayasoft (Home of Ivy) is on the JSR 277 expert group and hopefully
can help standardize some of their excellent Ivy technology features
which I expect will make their way into M2.
See: http://jayasoft.org/ivy/doc/comparison for a comparison of Ivy to
other technologies including M1 & M2.

** Forrest (sub project of Cocoon)
Currently I call Forrest in my ANT builds with:
<target
name="docs"
depends="test, javadocs, jdepend, generate-docs, doc-schema,
build-docs"
description="Builds all the documentation.">
<ant antfile="${env.FORREST_HOME}/forrest.antproxy.xml"
target="site"/>
</target>

So I expect even with out doing M2 plugins it will be easy to call
forrest's ant build from M2 if I have to.
Another positive development is that the Forrest/Cocoon dev folks are,
like ApacheDS moving toward OSGi, so we can all look forward to having
Cocoon bundles in the OSGi quiver when heavy duty production XML/XSL
pipelining is needed.

thanks again to all the ApacheDs/Mina team,
John

On Tue, 2005-11-15 at 07:16, Enrique Rodriguez wrote:
> Brett Porter 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
>

Brett Porter

2005-11-15, 8:45 pm

Thanks for the great quote, just some nit picks on your mail

On 15 Nov 2005 18:40:49 -0600, John E. Conlon <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote:
> * Jayasoft (Home of Ivy) is on the JSR 277 expert group and hopefully
> can help standardize some of their excellent Ivy technology features
> which I expect will make their way into M2.

Also worth noting that Apache is also on the expert group as a whole,
and so is Jason Van Zyl from Maven and Richard Hall from Felix as
independants.

> See: http://jayasoft.org/ivy/doc/comparison for a comparison of Ivy to
> other technologies including M1 & M2.

Way, way out of date (January, before Maven 2.0 had any public
releases). We've for the most part surpassed Ivy's feature set
(actually, in about March

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

> ** Forrest (sub project of Cocoon)

Actually, Forrest is a project in its own right now
(http:///forrest.apache.org).

> So I expect even with out doing M2 plugins it will be easy to call
> forrest's ant build from M2 if I have to.

Absolutely, and I'm sure we could do a forrest plugin if there is interest.

Cheers,
Brett