Changing groupId for javaee
by Paul Gier
I'd like to change the maven groupId for the javaee project to
"org.jboss.javaee". Please let me know if this will cause problems for anyone.
I will be updating the microntainer dependencies, and any others that I find.
If you see any dependencies on javaee, please update them to the new groupId,
after I make the change.
Thanks!
17 years, 4 months
JBoss AS CI in Hudson
by Rajesh Rajasekaran
JBoss Application Server continuous integration builds and test suite
runs have been moved over to hudson from cruisecontrol.
The builds are accessible from http://hudson.jboss.org/
Click on the JBoss AS tab for the AS builds.
The runs on cruisecontrol will be disabled from tomorrow.
Build notifications will be sent to builds(a)lists.jboss.org
Please subscribe to the mailing list if you haven't.
https://lists.jboss.org/mailman/listinfo/builds
Hudson provides a better continuous integration environment than
cruisecontrol in a number of ways.
To name a few, the master/slave setup allows the execution of parallel
builds to provide quicker feedback.
Employees will be able to schedule builds themselves, monitor build
queues and be able to get instant status on the builds.
JBoss AS and other projects available on http://hudson.jboss.org/ are
the first set of projects to be made public.
Hudson, as a project itself is in its maturing phase and as we have
fixes and enhancements we will be making those available.
http://hudson.jboss.org/ is still in its early phase and as we get other
JBoss projects migrated we will be continuously monitoring and enhancing
the system
Please provide any feedback or improvements you would like to have in
this continuous integration system.
Above said, the junit plugin in hudson does not support the
JUnitResultFormatter test names used in the AS test suites for
differentiating the test configurations.
Hence, in addition to the hudson reports, the original junit reports are
made available under "Artifacts" till the junit plugin is enhanced.
Any feedback is appreciated.
Thanks
Rajesh
17 years, 4 months
JB5 Beta3 library dependencies
by Dimitris Andreadis
Tracking down the various dependencies for JB5 Beta3.
http://jira.jboss.com/jira/browse/JBAS-4562
https://svn.jboss.org/repos/jbossas/trunk/build/build-thirdparty.xml
- We have 10 components at snapshot level. They must reach at least a Beta state until
mid-September. Can the respective owners verify they can deliver on time and make sure the
updates are tracked with subtasks in JIRA (JBAS-4562), including any transitive dependencies
those component may have?
<componentref name="jboss/aop" version="snapshot"/>
<componentref name="jboss/integration" version="snapshot"/>
<componentref name="jboss/jboss-jaspi-api" version="1.0-SNAPSHOT"/>
<componentref name="jboss/jboss-javaee" version="5.0.0-SNAPSHOT"/>
<componentref name="jboss/jboss-security-spi" version="2.0.1-SNAPSHOT"/>
<componentref name="jboss/jbosssx" version="2.0.1-SNAPSHOT"/>
<componentref name="jboss/jbosssx-client" version="2.0.1-SNAPSHOT"/>
<componentref name="jboss/jbossts" version="snapshot"/>
<componentref name="jboss/messaging" version="snapshot"/>
<componentref name="jboss/microcontainer" version="snapshot"/>
- What other component updates are required? Are those entered in JIRA as well? For the time
being we have:
Hibernate Annotations 3.3.1 (from 3.2.1)
Hibernate Entity Manager 3.3.2 (from 3.2.1)
What about jgroups 2.5 ? (now at 2.4.1.SP3). Is something else missing? Any objections on
including Hibernate Validator?
- Synch with AS 4.2.x
xdoclet could go to 1.2.3 (from 1.2b3)
remoting to 2.2.1, or 2.2.2 when available (now at 2.2.0.SP4)
- Removals. Are the following *really* needed? Most do not exist at all in 4.2.x.
wutka-dtdparser
backport-concurrent
jbossretro
apache-myfaces
commons-el
easymock
ehcache
sleepycat
spring
jbpm
opensaml
- Inconsistencies
Don't know how we've managed but we have *two* version of dom4j. Interestingly enough, the
last wins:
<componentref name="dom4j" version="1.6.1-brew"/>
<componentref name="dom4j" version="1.6.1jboss"/>
I'm inclined to keep the brew'ed one (used in 4.2.x, too) or does someone remember what's
special with the 1.6.1jboss one?
Another inconsistency is that JBM brings in the old JBoss Common 1.2.0.GA in thirdparty,
although we are using the Common 2.x series. Not sure if it has any other implications.
Cheers
/Dimitris
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
JBoss AS, Project Lead
JBoss, a Division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 4 months
Libs from tools/lib in thirdparty/libraries.ent
by Brian Stansberry
Can anyone tell me how the following bit gets added to
thirdparty/libraries.ent in Branch_4_2 when the file is built? Seems to
be magic... not coming through the component-info.xml stuff that drives
the other sections.
<!-- Ant -->
<property name="apache.ant.root" value="${project.tools}"/>
<property name="apache.ant.lib" value="${apache.ant.root}/lib"/>
<path id="apache.ant.classpath">
<pathelement path="${apache.ant.lib}/ant.jar"/>
</path>
I'm trying to create an equivalent section for ant-junit.jar so I can do
http://jira.jboss.com/jira/browse/JBAS-4641.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 4 months
what triggers the the install targets
by Thomas Diesler
Hi,
I'm trying to move the jbossws container integration to the AS code
base. In build-dist.xml I created
<target name="_module-webservices-most">
<property name="_module.name" value="webservices" override="true"/>
<property name="_module.output" override="true"
value="${project.root}/${_module.name}/output"/>
that is supposed to install the artifacts that are build in the
webservices module. The target is however never called.
Who knows how is this supposed to work (i.e. how do I need to hook up
the new target)
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 4 months
AS5 workspace downloading jbpm
by Anil Saldhana
Wondering why AS5 is downloading jBPM and why it is so painfully slow,
while the rest of the archives are quick to download.
----------------
synchronize.jbpm:
[get] Getting:
http://repository.jboss.com/jbpm/3.1.2/component-info.xml
[get] To:
C:\cygwin\home\asaldhana\JB5\jboss-head\thirdparty\jbpm\componen
t-info.xml
[get] local file date : Mon Apr 09 11:24:22 CDT 2007
[get] Not modified - so not downloaded
synchronize.jbpm.jbpm.zip:
[mkdir] Created dir:
C:\cygwin\home\asaldhana\JB5\jboss-head\thirdparty\jbpm
\lib
[get] Getting: http://repository.jboss.com/jbpm/3.1.2/lib/jbpm.zip
[get] To:
C:\cygwin\home\asaldhana\JB5\jboss-head\thirdparty\jbpm\lib\jbpm
.zip
[get] ....................................................
[get] ....................................................
Add in excess of 5min to download this
---------------------
--
Anil Saldhana
Project/Technical Lead,
JBoss Security & Identity Management
JBoss, A division of Red Hat Inc.
http://labs.jboss.com/portal/jbosssecurity/
17 years, 4 months
Weird trace log
by Carlo de Wolf
I'm getting weird trace log lines:
2007-08-16 14:13:00,258 TRACE [org.jboss.deployment.EARStructure:70] Not recognised: ejb3_bb_stateless_enventry_ejb.jar
There is no Logger defined in EARStructure and thus nothing interesting
on line 70.
But AbstractStructureDeployer defines this:
protected Logger log = Logger.getLogger(getClass());
But still nothing interesting on line 70.
1. Shouldn't AbstractStructureDeployer use
Logger.getLogger(AbstractStructureLogger.class)?
2. What the hell is going on?
Carlo
17 years, 4 months
What is the intended maven repository structure?
by Jason T. Greene
Looking at our maven repository, their seems to be a large variety of
conventions on where to put packages. Even the same package exists in
multiple locations.
Has it been decided where packages are supposed to be?
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
17 years, 4 months
