Hi Brett!
I would rather prefer to make it differently.
a) junit tests should be left as they are. (still no way to skip them!)
b) For other types of tests (integration tests, stress tests etc.)
we can make it similarly as it was done with Reports (plugable API):
iuTests
iuTestcactus/iuTest
iuTesthttpUnit/iuTest
iuTestdbunit/iuTest
iuTestsurefire/iuTest (once Jason will finish it ;) )
/iuTests
Each of those tests types will keep its own configuration settings etc
and course the possibility of running e.g.just cactus tests will still
remain.
Then integration test can be even integrated with of reports.
reports
...
reportiutest/report
/reports
There is a lot of details which I skipped (for example resource processing
for tests), but this is just a fresh idea.
what you think?
regards
Michal
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 2:34 AM
To: Maven Developers List
Subject: [PROPOSAL] Maven POM re-org to address deps + test issues
Hi,
Based on the discussions about test levels and about isolating test,
runtime and compile time dependencies, I thought about some changes to
the POM that might help, and got a bit carried away ;)
This is a work in progress with a few limitations discussed later, but I
thought it might be a good starting point for a discussion to address
some of the issues. Bear in mind I wrote this on the train at 7am this
morning ;)
What I propose is remove build/ and everything in it. Move
nagEmailAddress/ to that level, and then add the following elements:
sets
set
namerequired-name/name
extends
extendset-name/extend
extendother-set-name/extend
/extends
src
directory.../directory
includes
include.../include
/includes
excludes
exclude.../exclude
/excludes
/src
dependencies
!-- as before --
/dependencies
resources
!-- as before --
/resources
plugins
!-- Default is include all --
includes
include.../include
/includes
excludes
exclude.../exclude
/excludes
/plugins
properties
!-- Actually put these into Jelly context (or Ant?) during
processing of plugin --
property.namevalue/property.name
/properties
/set
!-- repeat for test set, java set, JAXB set, cactus test set,
performance test set, ... --
/sets
Finally, you can includes/exclude sets from the command line to avoid
processing certain sets:
maven -Dexclude.sets=perf-test,integ-test
or
maven -Dinclude.sets=gen-jaxb,default
Now the problems I see with it:
* Not that comfortable with the extends syntax - bit too similar to POM
inheritance. Could be used to fold subprojects. However, need a way to
include deps and classpath built sources of other sets without
duplication. Any thoughts on this?
* This pattern allows multiple source trees. It does takes care of
generated source (antlr, jaxb) more cleanly (source would be the
descriptor files, then plugin uses addPath for java sources). However,
could be used to have multiple java source trees for a real project.
Maybe this is ok - let those who've demanded it have it, but perhaps
display a warning every run that it is a bad practice :)
* The specification of plugins does worry me a bit, but I don't see
alternatives. Certain things should make use of new plugins
automatically (some site related plugin should apply to all source
trees), but others must be blocked out.
Also, how does this fit with maven-new's structure?
Cheers,
Brett
--
Web Developer
f2 network ~ everything essential
02 8596 4437
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
