directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Re: [mina] Using Ant + Forrest like Tapestry team does.
Date Tue, 15 Nov 2005 12:45:59 GMT
On 11/15/05, Trustin Lee <trustin@gmail.com> 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 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?

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

Mime
View raw message