Sorting out the common project maven mess
by Adrian Brock
I've just been through the common project (but not JBossXB)
and sorted out the mess it had become.
1) There was a circular dependency betten common-core
and jboss-test (and transitively common-core and common-logging-log4j).
I've removed common-core's use of jboss-test which solves the issue.
It now just uses plain junit. The only actual use was the initialization
of log4j. I've changed the tests to use System.out.println()
2) There was some confusion between whether these artifiacts
should go in the jboss or org.jboss namespace.
I've now made it consistently use the org.jboss namespace.
Although there are no releases of the logging framework in the org.jboss
namespace this should be done with a 2.0.5.GA release and everybody
then should be using those artifacts.
3) The poms were referencing fixed releases of some artifacts.
So for example even if you changed something in common-core the
other projects didn't see it. Instead they downloaded an older
release from repository.jboss.com
I also think this should use version properties from build/pom.xml
like we do in other projects instead of having to update the
version changes in many different places.
4) I made the common-logging-log4j/jdk dependencies on
common-core optional. Since these are only required for
features rather than normal use.
i.e. in log4j for the TCLFilter's use of WeakSet
and in jdk for the DOMConfigurator's use of property editors.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 9 months
Custom testsuite configs
by Brian Stansberry
In testsuite/build.xml I see a bunch of instances of the following sort
of thing, where an attempt is made to create a config with a limited set
of items in deploy/:
<create-config baseconf="default" newconf="tomcat-federation">
<patternset>
<include name="conf/**"/>
<include name="deployers/**"/>
<include name="deploy/jbossweb.sar/**"/>
<include name="deploy/ROOT.war/**"/>
<include name="lib/**"/>
<include name="deploy/jmx-console.war/**"/>
<include name="deploy/jmx-invoker-service.xml"/>
<include name="deploy/hsqldb-ds.xml"/>
<include name="deploy/jbossjca-service.xml"/>
<include name="deploy/jboss-local-jdbc.rar"/>
<include name="deploy/jboss-jdbc-metadata.sar"/>
<include name="deploy/security*"/>
</patternset>
</create-config>
This kind of thing is really fragile; e.g. this config will no longer
start since it's missing newly added stuff like
deploy/transaction-service.xml and deploy/remoting-service.xml.
Whenever I look at these, it seems the idea was to have a trimmed
deployment that starts faster. Not to actually exclude something in
order to test what happens when it isn't there. A couple seconds faster
start IMHO isn't worth the fragility.
I'm going to convert all these to this:
<patternset>
<include name="conf/**"/>
<include name="deployers/**"/>
<include name="deploy/**"/>
<include name="lib/**"/>
</patternset>
I'll leave the previous detail config there, but commented out. If one
of these configs actually did want to exclude something, please add an
<exclude/> to make it explicit.
- Brian
P.S. I have a weird deja-vu sense of having done this before???
16 years, 9 months
WARNING: Mavenizing Thirdparty (2nd try)
by Paul Gier
Hi Everyone,
I'd like to make a second attempt at replacing build-thirdparty.xml with maven.
I'm going to add a new file called build-maven.xml to the build directory.
This will allow anyone who is interested to try it out before the actual
switch. I'm planning to do some additional testing and dependency checking this
afternoon (I still need to make some updates to jbossws dependencies), and then
make the change to build.xml at the end of the day today.
I will leave the build-thirdparty.xml file in the build directory for testing
this week, and then if everything is working fine, it can be removed next week.
If this conflicts with any changes you had planned, or you have concerns about
this please let me know.
Thanks!
16 years, 9 months
