--- [EMAIL PROTECTED] wrote:
> A few comments for discussion:
>
> [EMAIL PROTECTED] wrote on 03/01/2003 11:26:42 AM:
> [snip]
>
> > Index: maven.xml
> >
>
===================================================================
> > <project default="java:jar" xmlns:j="jelly:core"
> xmlns:
> > maven="jelly:maven" xmlns:util="jelly:util">
> >
> > <!-- copies unit testing stuff -->
> > <postGoal name="test:compile">
> This should no longer be necessary with the
> unitTest/resources/resource
> stuff.
I think they're organized that way so that the jelly
test scripts are located alongside their invoking
classes. However, I'm completely ambivalent.
> > <copy todir="${maven.test.dest}">
> > <fileset dir="src/test">
> > <include name="**/*.properties"/>
> > <include name="META-INF/services/*"/>
> > <include name="**/*.jelly"/>
> > <include name="**/*.xml"/>
> > <include name="**/*.html"/>
> > <include name="**/*.dtd"/>
> > <include name="**/*.rng"/>
> > </fileset>
> > </copy>
> > </postGoal>
> >
> > </project>
> >
> >
> [snip]
> > Index: project.properties
> [snip]
> > maven.jarResources.basedir=src/java
> This property wont be used anymore.
Works for me.
> [snip]
> > # use Sun coding standards
> Maven now defaults to Sun coding standards. But
> since we're overriding, we
> should use:
>
> maven.checkstyle.properties=project.properties
>
> > maven.checkstyle.header.ignore.line =
> 1,2,3,4,5,6
> This becomes
> checkstyle.header.ignoreline = 1,2,3,4,5,6
>
> > maven.checkstyle.const.pattern =
> ^[a-z][a-zA-Z0-9]*$
> checkstyle.pattern.const = ^[a-z][a-zA-Z0-9]*$
> >
> [snip]
> > maven.checkstyle.max.line.len = 100
> checkstyle.maxlinelen = 100
>
> > maven.checkstyle.ignore.whitespace = true
> checkstyle.ignore.whitespace = true
>
> > maven.checkstyle.ignore.public.in.interface =
> true
> checkstyle.ignore.public.in.interface = true
As you wish. I don't need anybody to check my style.
:)
> [snip]
> > Index: project.xml
> >
>
===================================================================
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE project [
> > <!-- see file for description -->
> > <!ENTITY commonDeps SYSTEM
> "file:../../commonDependencies.ent">
> > ]>
> We could use the <extend> of the project to pick up
> common elements.
Not familiar with that tag. Let's see... Aha. Well,
I could take it or leave it. I like using plain old
XML when it's convenient. Less likely to wig out.
> [snip]
>
> > <dependency>
> > <id>commons-jelly</id>
> > <version>SNAPSHOT</version>
> > </dependency>
> Jelly's got to be in the common dependencies, right?
Nope. The core build needs those dependencies too.
Making Jelly dependent on itself would be quite a
trick.
> I was going to do this as a commit, but I figured we
> should discuss it
> first.
>
> Fire away, I've got the flameproof suit on :)
No jacket required.
- Morgan
> --
> dIon Gillard, Multitask Consulting
> Blog:
> http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
