Well, "broken" ;) ...as the groupId is now using the maven2 scheme
the commons is already included in there.
But I will bring that up on commons dev to see how we will handle
this.
I agree but now eveywhere else "commons-" prefix is used in
artifact ids so you have to change it everywhere or nowhere.
The reason for that is that we inherited the group id for the
projects in proper. This should not be *required* for new project
getting released. But I would really prefer to use the maven2 group
scheme. Again - that's a topic for commmons-dev and not cocoon-dev.
..plus changing this that is probably the least work that is still to
be done ;)
Now build is just broken because jci-core cannot find parent pom...
Works just fine for me. Did you check out the whole sandbox? (Or
checkout the parent pom and "mvn install" it)
All tests work for me.
What (sub)projects are failing?
What operating system are you using?
What filesystem?
Can you send me the outputs?
I attach full Maven output so you can gather from it answers to
most of your questions:
Well, some of them ...could you please send me (off list) the test
outputs from the "target" dir?
G:\asf\commons-jci>mvn clean install
Windows - I somehow expected to see some problem there ;)
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.commons.jci.CompilingClassLoaderTestCase
Exception in thread "Thread-1" java.lang.RuntimeException: cannot
handle resource jci\Extended.java
OK ...that needs to be "jci/Extended.java". Easy to fix.
Everything tested on WinXP SP2 with Java 1.6.0 installed and ran
with Maven 2.0.4.
OK
Is FilesystemAlterationMonitorTestCase supposed to take so long
(about 1 minute)?
Yes, that's expected. Unfortunately the resolution for last-modified
information differs from filesystem to filesystem. So we have to use
some sleeps to make it work across platforms. This is just a testing
issue though.
cheers
--
Torsten
