Maven

[Jason van Zyl <jv...@zenplex.com>]

Hi,

Some Turbine developers have been playing around with Maven over the
last few days, but I would like to formally introduce the little project
for those who don't know anything about it. I'll give a brief outline of
what Maven can provide and outline a little proposal to employ Maven's
use in all our build systems.

For the impatient you can view the Maven site which actually uses Maven
to produce everything you see:

http://jakarta.apache.org/turbine/maven/

This is a very quick first iteration but I would like to use the Maven
site as a use case. The question being: How quickly can you get to know
a project's inner workings by looking at the information provided by
Maven's generated build system (and the tasks provided within)?

Maven is really a direct result of trying to get a hold on all the
pieces of Turbine that have been decoupled over the last year. We have
quite a few pieces now and it is becoming increasingly difficult to keep
track and assess what state these projects are actually in.

Right now Maven provides the following things:

-> a generic build system that works from a project descriptor

-> a generic unit testing system that works from a project descriptor

-> document generation system that works from a project descriptor. this
includes javadocs and html

-> source cross referencing with links to javadocs. the code was lifted
from the alexandria project

-> source metrics provided by jdepend 

-> changlog document created from the output of 'cvs log'

-> update mechanism for a project

-> integration with Gump

A project descriptor looks something like the following:

http://cvs.apache.org/viewcvs/jakarta-turbine-maven/project.xml?rev=1.6&content-type=text/vnd.viewcvs-markup

With one of these project descriptors, and the source for your project
of course, you can get everything you see on the Maven site.

How is the project descriptor created you ask? Well we're working on
being able to analyze your source using a java parser and BCEL and
determine most of the dependencies and we will have a CLI tool and a GUI
tool to help you make a correct project descriptor. Once you have the
project descriptor you're all set.

What I would like to over the next week is to move the Turbine projects
toward using Maven so that we can get a grip on all the Turbine projects
as a whole. This will give us a view on all our projects that we
currently don't have: the documentation and cross ref'd source with
links to the javadoc should help people become more familiar with the
code more quickly and the metrics produced should help us to see a
clearer path to refactoring. Another important point to mention is the
Gump integration. If the Maven project descriptors are correct then the
generated Gump descriptors will be correct and we can avoid most of the
Gump problems we've had because we can eliminate the data entry aspect
of keeping the gump descriptors up-to-date.

There are a few issues left to deal with like how to integrate very
different run-time testing requirements into a generic build system but
I think we will work these out and I believe this will overall be a
benefit. We can also integrate Maven into the TDK so that people can
have the option to develop their projects in the same way Turbine does.
I believe the uniformity in the display of project information will only
be a boon. And as the build system improves it can be rapidly integrated
into a development environment because the build system is generated
from the project descriptor so you don't even have to store the build
system in CVS. Also because the project descriptor is a simple XML file
if the structure changes Maven can also provide a DVSL transformation to
keep project descriptors current.

There is a ways to go, but as a first iteration I think we have
something that is pretty good. I was surprise by the number of people
who have expressed interest and many patches and contributions have been
made in a very, very short period of time.

I would also like to make a special note of the effort of Pete Kazmier
who has done a stellar job at making the documentation you see and
keeping it updated. I would also like to thank Geir for getting all the
DVSL working and Jeff for getting metrics targets working. Thanks must
also go to Jauncarlo Arnez for donating the JRCS code and Tom Copeland
for the BCEL dep resolving code. Anyway I think this will be a great
thing for Turbine and I would like to get things rolling this week even
if it is only discussion and refinement of what currently exists in
Maven.

Any thoughts and feedback are welcome :-)


-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Maven bootstrap error

[Kief Morris <ki...@bitbull.com>]

Ian Lim typed the following on 10:19 AM 3/10/2002 +0800
>if maven shows up with the error below:
>
>C:\src\kief\jakarta-turbine-maven\build-bootstrap.xml:85:
>java.lang.Exception: No
>class name for node 'description': This may be resolved by adding a
>className attribute
>
>You can delete off the crimson.jar parser in ANT_HOME\lib
>and replace it with a Xerces parser. In my case, I use xerces-1.4.3.jar.

Woohoo, thanks for this. I got stuck on this last week but nobody on dev
had an answer. Your fix works for me.

Kief


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Maven bootstrap error

[Ian Lim <ma...@yahoo.com.sg>]

Hi

if maven shows up with the error below:

C:\src\kief\jakarta-turbine-maven\build-bootstrap.xml:85:
java.lang.Exception: No
class name for node 'description': This may be resolved by adding a
className attribute

You can delete off the crimson.jar parser in ANT_HOME\lib
and replace it with a Xerces parser. In my case, I use xerces-1.4.3.jar.

And the whole thing works like a charm again :)

Regards
Ian Lim
=====================
Email: mailto:mallim_sg@yahoo.com.sg
Homepage: http://www.webappcabaret.com/mallim


----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: <tu...@jakarta.apache.org>; <tu...@jakarta.apache.org>
Sent: Tuesday, February 26, 2002 01:51 AM
Subject: Maven


> Hi,
>
> Some Turbine developers have been playing around with Maven over the
> last few days, but I would like to formally introduce the little project
> for those who don't know anything about it. I'll give a brief outline of
> what Maven can provide and outline a little proposal to employ Maven's
> use in all our build systems.
>
> For the impatient you can view the Maven site which actually uses Maven
> to produce everything you see:
>
> http://jakarta.apache.org/turbine/maven/
>
> This is a very quick first iteration but I would like to use the Maven
> site as a use case. The question being: How quickly can you get to know
> a project's inner workings by looking at the information provided by
> Maven's generated build system (and the tasks provided within)?
>
> Maven is really a direct result of trying to get a hold on all the
> pieces of Turbine that have been decoupled over the last year. We have
> quite a few pieces now and it is becoming increasingly difficult to keep
> track and assess what state these projects are actually in.
>
> Right now Maven provides the following things:
>
> -> a generic build system that works from a project descriptor
>
> -> a generic unit testing system that works from a project descriptor
>
> -> document generation system that works from a project descriptor. this
> includes javadocs and html
>
> -> source cross referencing with links to javadocs. the code was lifted
> from the alexandria project
>
> -> source metrics provided by jdepend
>
> -> changlog document created from the output of 'cvs log'
>
> -> update mechanism for a project
>
> -> integration with Gump
>
> A project descriptor looks something like the following:
>
>
http://cvs.apache.org/viewcvs/jakarta-turbine-maven/project.xml?rev=1.6&cont
ent-type=text/vnd.viewcvs-markup
>
> With one of these project descriptors, and the source for your project
> of course, you can get everything you see on the Maven site.
>
> How is the project descriptor created you ask? Well we're working on
> being able to analyze your source using a java parser and BCEL and
> determine most of the dependencies and we will have a CLI tool and a GUI
> tool to help you make a correct project descriptor. Once you have the
> project descriptor you're all set.
>
> What I would like to over the next week is to move the Turbine projects
> toward using Maven so that we can get a grip on all the Turbine projects
> as a whole. This will give us a view on all our projects that we
> currently don't have: the documentation and cross ref'd source with
> links to the javadoc should help people become more familiar with the
> code more quickly and the metrics produced should help us to see a
> clearer path to refactoring. Another important point to mention is the
> Gump integration. If the Maven project descriptors are correct then the
> generated Gump descriptors will be correct and we can avoid most of the
> Gump problems we've had because we can eliminate the data entry aspect
> of keeping the gump descriptors up-to-date.
>
> There are a few issues left to deal with like how to integrate very
> different run-time testing requirements into a generic build system but
> I think we will work these out and I believe this will overall be a
> benefit. We can also integrate Maven into the TDK so that people can
> have the option to develop their projects in the same way Turbine does.
> I believe the uniformity in the display of project information will only
> be a boon. And as the build system improves it can be rapidly integrated
> into a development environment because the build system is generated
> from the project descriptor so you don't even have to store the build
> system in CVS. Also because the project descriptor is a simple XML file
> if the structure changes Maven can also provide a DVSL transformation to
> keep project descriptors current.
>
> There is a ways to go, but as a first iteration I think we have
> something that is pretty good. I was surprise by the number of people
> who have expressed interest and many patches and contributions have been
> made in a very, very short period of time.
>
> I would also like to make a special note of the effort of Pete Kazmier
> who has done a stellar job at making the documentation you see and
> keeping it updated. I would also like to thank Geir for getting all the
> DVSL working and Jeff for getting metrics targets working. Thanks must
> also go to Jauncarlo Arnez for donating the JRCS code and Tom Copeland
> for the BCEL dep resolving code. Anyway I think this will be a great
> thing for Turbine and I would like to get things rolling this week even
> if it is only discussion and refinement of what currently exists in
> Maven.
>
> Any thoughts and feedback are welcome :-)
>
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
> http://tambora.zenplex.org
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Maven

[Incze Lajos <in...@mail.matav.hu>]

> > Would it be possible to create nightly builds from maven? I would give it
> > a try in a project that sits deeply behind a firewall, so cvs is not an
> > option.
> 
> Not sure I follow: do you want nightly builds of Maven, or you want to
> use Maven to produce nightly builds for another project?

I'd try to USE maven to produce builds, docs, metrics for an internal
project. So, I would need maven itself which sits inn cvs, now. Am I
misunderstood something?

incze

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Maven

[Jason van Zyl <jv...@zenplex.com>]

On Mon, 2002-02-25 at 16:51, Incze Lajos wrote:
> > Right now Maven provides the following things:
> > 
> > -> a generic build system that works from a project descriptor
> > 
> > -> a generic unit testing system that works from a project descriptor
> > 
> > -> document generation system that works from a project descriptor. this
> > includes javadocs and html
> > 
> > -> source cross referencing with links to javadocs. the code was lifted
> > from the alexandria project
> > 
> > -> source metrics provided by jdepend 
> > 
> > -> changlog document created from the output of 'cvs log'
> > 
> > -> update mechanism for a project
> > 
> > -> integration with Gump
> 
> Would it be possible to create nightly builds from maven? I would give it
> a try in a project that sits deeply behind a firewall, so cvs is not an
> option.

Not sure I follow: do you want nightly builds of Maven, or you want to
use Maven to produce nightly builds for another project?
 
> Thanks, incze
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Maven

[Incze Lajos <in...@mail.matav.hu>]

> Right now Maven provides the following things:
> 
> -> a generic build system that works from a project descriptor
> 
> -> a generic unit testing system that works from a project descriptor
> 
> -> document generation system that works from a project descriptor. this
> includes javadocs and html
> 
> -> source cross referencing with links to javadocs. the code was lifted
> from the alexandria project
> 
> -> source metrics provided by jdepend 
> 
> -> changlog document created from the output of 'cvs log'
> 
> -> update mechanism for a project
> 
> -> integration with Gump

Would it be possible to create nightly builds from maven? I would give it
a try in a project that sits deeply behind a firewall, so cvs is not an
option.

Thanks, incze

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>