jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: Building Cactus with Maven -> I'd like to volonteer
Date Thu, 26 Jun 2003 07:04:50 GMT

> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 25 June 2003 23:33
> To: Cactus Users List
> Subject: Re: Building Cactus with Maven -> I'd like to volonteer


> > - Maven does *not* understand multiple source directories. It is
> possible to
> > give it the root of the source directories, and then it will walk
> them
> > (nice), but in Cactus' case there are the same classes in the j2ee12
> > j2ee13 repositories, so I'm having some duplicate class errors. What
> you're
> > doing here (copy/pasting directories) is too Ant-like I'm afraid.
> Besides,
> > it's a really weird idea... Couldn't you put everything in the same
> tree, and
> > use a factory?? I understand that some parts of the j2ee 1.2 spec
> > deprecated and outdated, but hey, there's anyway lots of
> stuff
> > in the "share" directory.
> > Anyway, I don't think a Maven build can be done easily without a
> unified
> > source tree.
> > BTW, my build succeeds because I wiped off the j2ee12 tree, which is
> useless
> > to me.
> It is not easily possible to eliminate the parallel source directories
> for j2ee12/j2ee13. It's not just about deprecation, but also about new
> methods and interfaces that have been added in j2ee13.
> I would assume that Maven can actually handle this, and that you've
> not found the correct approach yet. If it can't handle this, well, ...
> ugh. Show stopper.

Yes, Maven can handle this. The easiest solution (if we don't want to
change the current src structure), involves doing some copy: copy
j2ee${j2ee.api}/** and share/** to a target-${j2ee.api}/src directory
and then point Maven to target-${j2ee.api}/src.


> > - The PMD & checkstyle reports are producing lots of errors (wrong
> brackets
> > and everything), but some interesting things do show up (use of
> for
> > example)
> Why would we want to run both PMD and Checkstyle? We have been running
> Checkstyle all the time, and there's a configuration file in the root
> dir (checkstyle.xml). Certainly using any kind of default
> would cause a lot of violations.

Running PMD is nice I think but we need to decide what rules we would
like to verify. It's good to run them all, look at the generated report
and then tune the rules. For checkstyle, as Chris said, we already know
what we want.

> > - The Clover report seems to be half broken, but I think it's the
> > maven-clover-plugin's fault. Anyway that's a non-free software, who
> would
> > actually use that to do some serious work :-)

That's not correct. Cactus owns a Clover license and it's free. I know
you were joking but I really like Clover ;-)

> IIUC, the Clover support in Maven isn't quite up to the task yet,
> because we need to generate the report after multiple test runs and
> builds of sub-projects have finished (framework, integration/ant,
> samples/servlet)... Vincent should know the details.

Yep... :-) There's some work to be done there but it's quite easy I
think. Maven has a "clover:on", "clover:off" feature that should support
this use case. Need to experiment with it though.

> > - JUnit, javadoc and all the other reports I've tried were ok.
> >
> > Concerning today's emails :
> > - I think the Maven-built web site can be customized. I have never
> it
> > before, thus.

It is possible by providing our own templates (by overriding the
maven.xdoc.pomDocuments and maven.xdoc.projectInfo properties). These
templates have to be velocity templates ATM.

That said, we are free to not use the xdoc and sites plugins provided by
Maven and instead use ours. It is quite easy to do actually. Another,
probably easier solution is to modify the xdoc plugin to support XSL

The devil is probably in the details... :-) (like parameter passing,

> > - There's a maven-gump plug-in, so Gump intergration should be
> I'm a
> > CruiseControl user, so I can't really say more about Gump.
> The maven-gump plugin would only solve a tiny bit of the problem (it
> just generates the gump descriptor AFAIK). The real problem is that
> Maven needs to be bootstrappable by Gump (which I think is just noble
> theory as of yet), and the Gump must be able to execute our build,
> doesn't currently work using a Maven-based build. All this due to
> community "incompatibility", not technical reasons. Sigh.

Yep. I had seen some discussion about this on the Gump mailing list but
I can't recall the outcome (if there were any!).


View raw message