When JBossXB, common, test and aop are properly standalone.
I've still not seen something I can manage in this respect.
Cache, Remoting, Webservices maybe happy to run before they can walk,
I am not.
On Mon, 2006-05-01 at 08:44 -0500, Scott M Stark wrote:
The mc code should be pulled out of
Then either head should be moved to svn so that project refactoring can
be done with history maintained, or these modules be removed from
jboss-head and reintegrated as binary dependencies so that they can be
migrated seperately.
I doubt a complete move is practical given the J1, JBW timeline
Which of this is the showstopper?
http://jira.jboss.com/jira/browse/JBBUILD-307
The issue for me is being able to develop against the
HEAD/Snapshot of each dependent project without creating an infinite
number of versions in the repository. :-)
e.g. the ongoing integration between AOP/MC
require
JBBUILD-307 subtasks:
2. Create script to modify a SVN jbossas repo and change the
directories to the proper names is certainly a show stopper as the
migration of the cvs modules does not honor the cvs module aliases. The
jboss-head or jboss-4.0.x tag/branch from cvs contains the raw cvs
module
On Tue, 2006-05-02 at 09:07 -0500, Scott M Stark wrote:
It would potentially be possible to require the MC projects
to be developed against head while still being thirdparty
binaries in the main jboss-head build.
i.e. You would checkout the projects separately into the head tree.
Ok, I'll do this. If you want to use JDK5 features, we should
also look at make jboss retro binaries.
Yes, I do so we need separate binaries for 14.
I'll make JBoss-Head build on the JBossMC-1.0.2.GA binaries.
Besides the bean deployer in varia, only EJB3 is using it
until
Ok, then we just need to define a cutoff date for the common module to
be frozen in head and then remove the module from jboss-head and switch
to binary imports. Alexey I don't see any cvs commits to jbossxb
recently, are you already working off of the svn repo?
-Original Message-
From:
The first problem I've come across is that AOP is using the container
project for the metadata repository interfaces.
There is no binary release of this yet,
since it is still being developed.
So how doable is this while we are still working on the AOP/MC
integration with still unstable apis?
We have to bootstrap the repository with a snapshot version. This can be
a local jbossbuild repository override to avoid having to synch through
cvs and then out to the webserver.
It's the same problem we will face when developing multiple maven
projects with inter-dependencies. Maven just has a
This is the use case which Maven enables especially well, no?
ie, update code in container, build it, and then test the impact in AOP.
The jars from container are integrated into the AOP build using Maven's
local repository. There is no update the repository step since it is
part of the default
On Tue, 2006-05-02 at 11:54 -0500, Scott M Stark wrote:
We have to bootstrap the repository with a snapshot version. This can be
a local jbossbuild repository override to avoid having to synch through
cvs and then out to the webserver.
Can you explain how this works?
I can put a snapshot of
Correct.
-Original Message-
From: Ryan Campbell
Sent: Tuesday, May 02, 2006 10:12 AM
To: Scott M Stark; Adrian Brock
Cc: QA; 'jboss-development@lists.sourceforge.net'
Subject: RE: jboss-head-jdk-matrix Build Failed
This is the use case which Maven enables especially well, no?
Right. And if you were to be to be in heavy development mode, rather
than publishing a number of different versions, you would just publish
snapshots to the public repository. This eliminates the need to create
a buttload of versions.
Ruel Loehr
JBoss QA
-
With jbossbuild we have to do the rebuild snapshot step manually because
its not supported by the build. With maven you could pull all of these
projects together with the dependcies and missing/out of date binaries
will be built. You could convert these projects to use maven first to
achieve this.
If container depended on aop and aop was not yet built and had not yet
published any binary artifacts, the build of course, would fail. This
is assuming that both of these were standalone projects. If they were
contained under the same parent build maven would look first for the
built artifacts
Scott M Stark wrote:
Ok, then we just need to define a cutoff date for the common module to
be frozen in head and then remove the module from jboss-head and switch
to binary imports. Alexey I don't see any cvs commits to jbossxb
recently, are you already working off of the svn repo?
No, I've
No, it doesn't.
We plan to reduce the lag on the repository updates, which should reduce
our exposure to this problem.
-Original Message-
From: Adrian Brock
Sent: Tuesday, May 02, 2006 4:45 PM
To: QA
Cc: Adrian Brock; Bill Burke; Brian Stansberry; Clebert Suconic;
Dimitris Andreadis;
The ejb3 usage of the hibernate PersistenceXmlLoader is
broken:
/services/cruisecontrol/checkout/jboss-head/ejb3/src/main/org/jboss/ejb3/Ejb3Deployment.java:598:
deploy(java.net.URL,java.util.Map,org.xml.sax.EntityResolver) in
org.hibernate.ejb.packaging.PersistenceXmlLoader cannot be
This is my fault.
compile-classes-only:
[mkdir] Created dir:
/services/cruisecontrol/checkout/jboss-head/testsuite/output/classes
[javac] Compiling 2773 source files to
/services/cruisecontrol/checkout/jboss-head/testsuite/output/classes
[javac]
Webservices is breaking the build in a 1.4
JDK:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006
4:20 PM
To: Anil Saldhana;
[EMAIL PROTECTED]; Dimitris Andreadis;
jboss-development@lists.sourceforge.net; QA; Rajesh Rajasekaran; Scott M Stark;
module-webservice14:BUILD FAILED/services/cruisecontrol/checkout/jboss-head/build/build.xml:631: The following error occurred while executing this line:/services/cruisecontrol/checkout/jboss-head/build/build-distr.xml:1432:
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ben Wang
Sent: Monday, August 22, 2005 11:13 AM
To: Ryan Campbell; jboss-development@lists.sourceforge.net; QA
Subject: [JBoss-dev] RE: jboss-head-jdk-matrix Build Failed
No, it should since it is not a major release
@lists.sourceforge.net
Subject: RE: [JBoss-dev] RE: jboss-head-jdk-matrix Build Failed
This EJB3 tutorial is still broken, are there any plans to fix it?
Maybe it just needs updating to the latest JBossCache in jboss-head?
On Mon, 2005-08-22 at 19:10, Adrian Brock wrote:
jboss-head builds now,
but the tutorial
();
__
From:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ben Wang
Sent: Monday, August 22, 2005 11:13 AM
To: Ryan Campbell; jboss-development@lists.sourceforge.net; QA
Subject: [JBoss-dev] RE: jboss-head-jdk-matrix Build Failed
No, it should since it is not a major release branch
On Mon, 2005-08-22 at 14:15, Steve Ebersole wrote:
FWIW, for me, manually moving over the built
cache/output/lib/jboss-cache.jar file to thirdparty/jboss/cache/lib
fixed my issues. Seems ejb3 is using APIs that are present in the
source tree of cache, but not in the thirdparty binary.
This
The change to MappingObjectModelProvider was incompatible with j2se 1.4[execmodules] /scratch/cruisecontrol/checkout/jboss-head/common/src/main/org/jboss/xb/binding/MappingObjectModelProvider.java:182: cannot resolve symbol[execmodules] symbol : constructor IllegalStateException
26 matches
Mail list logo
