[Fwd: [jboss-dev-forums] [Design of JBoss Build System] - JBossAS CR1 build plan]
by Scott M Stark
In case your not getting build forum emails.
-------- Original Message --------
Subject: [jboss-dev-forums] [Design of JBoss Build System] - JBossAS
CR1 build plan
Date: Fri, 8 Feb 2008 12:45:38 -0500 (EST)
From: scott.stark(a)jboss.org <do-not-reply(a)jboss.com>
To: jboss-dev-forums(a)lists.jboss.org
On today's call we still have confusion about what will be done for the
CR1 build of jbossas, including exporting of artifacts to maven repos
for use by other projects. The main point of confusion is related to how
ejb3 is going to be built. It needs jbossas artifacts in maven repo,
jbossas needs the ejb3 artifacts for the assembly.
The issues to resolve are:
1. What are the jbossas artifacts and how are they being uploaded to a
maven repo as part of the build. One simple issue I already see is that
the names of the artifacts are changed in the existing pom.xml files.
For example in the system project, while the current build produces
jboss-system-client.jar and jboss-system.jar artifacts, the
system/pom.xml defines jboss-as-system.jar.
We need to get to consistent artifact names in both builds as it affects
classpaths and configuration files, docs.
2. Getting the jbossas build to use maven artifacts. Nothing currently
validates the jbossas maven artifacts. The first step in doing this is
to replace the legacy jbossbuild repo with the maven repo as the source
for the thirdparty contents. How we do this using ivy, maven ant tasks,
etc. needs to be defined and documented, and the existing
build-thirdparty target replaced.
The next step would be to replace the existing project dependencies
(classpaths defined in tools/etc/buildmagic/modules.ent) with the same
type of maven repo references as was done for thirdparty.
At that point the build and testsuite would be based on the exportable
artifacts.
3. How is ejb3/jbossas going to be built with ejb3 as a separate
project, that depends on jbossas artifacts. Logically jbossas/ejb3 are a
collection of dependent projects. How this translates into a build
procedure from tagged codebases is what needs to be defined for CR1. We
won't have jbossas completely mavenized by that point, so how a
reproducible build results is the question.
4. Related to 3, do we need to restructure the jbossas project,
including breaking it up into separate svn projects to support the
creation of jbossas artifacts and the jbossas release assembly.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127926#4127926
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127926
_______________________________________________
jboss-dev-forums mailing list
jboss-dev-forums(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
16 years, 10 months
JBoss AS trunk freeze
by Dimitris Andreadis
We are freezing the AS trunk in preparations of the upcoming Beta4 release.
Please do not commit changes unless:
1) You are working on one of the blockers:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid...
2) You are performing testsuite improvements that do not affect the stability of the server,
or the testsuite runs.
If in doubt, drop me a line.
The plan is to complete work on the blockers by Thursday (tomorrow) COB, do a final
testsuite/tck run on Friday, and make the tagging decision during our regular TCK/AS confcall.
Thanks
/Dimitris
16 years, 10 months
JBoss-AS-5.0.x-TestSuite-sun15
by Dimitris Andreadis
In that latest run, the profile service config didn't start properly.
I guess it's because of WarClassLoaderDeployer changes not synched with the testsuite?
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
2008-02-01 08:44:07,356 ERROR
[org.jboss.system.server.profileservice.ProfileServiceBootstrap] Failed to load profile:
Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
WarClassLoaderDeployer
-> ClassLoading{Configured:** NOT FOUND **}
-> ClassLoaderSystem{Configured:** NOT FOUND **}
*** CONTEXTS IN ERROR: Name -> Error
ClassLoaderSystem -> ** NOT FOUND **
ClassLoading -> ** NOT FOUND **
16 years, 11 months
Re: ServiceBindingManager status?
by Brian Stansberry
(copying the general jboss dev list)
I believe the problem with ServiceBindingManager and the web server is
the same as the one discussed on
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=128642. In AS
4.x, the TomcatDeployer was a JMX-based service, created via a
-service.xml. Now it's a pojo service and isn't managed via the
ServiceController. ServiceBindingManager integrates with the
ServiceController to do its magic with port 8080. No ServiceController
== no magic.
We need a strategy for Beta4. Long run, as Scott said on the forum,
"ServiceBindingManager has to be replaced with a component that
integrates with the profile service to use the management view." I
don't see that happening this week for beta4. :) So, what to do?
1) Leave it broken for Beta4; do it right for CR1. But do we have the
resources to do that for CR1?
2) Return the jboss.web:service=WebServer service to deployment via
-service.xml. There is discussion of refactoring TomcatDeployer at
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112404 .
Perhaps the piece that will end up in deploy can be made a JMX-based
service again. But, AIUI, that goes against the medium-term goal of
pojo-izing the service.
3) See if we can find a way to make the SBM work if an @JMX annotation
is added to a pojo service. That doesn't work now. Would probably need
Adrian's help to make that happen, if it's possible at all.
Thoughts?
- Brian
Dimitris Andreadis wrote:
> Clebert fixed the ports for the JBoss Messaging connectors, now the
> remaining problem (for the default configuration, at least) is the
> Tomcat connectors. Somehow the override for port 8080 is not working.
>
> Remy (or anyone that understands how the overrides work) can you take
> please a look?
>
> Heiko W.Rupp wrote:
>>
>> Am 28.01.2008 um 13:49 schrieb Luc Texier:
>>
>>> binding server instances to ip addresses is the only meaningful way
>>> of building a cluster, IMO.
>>>
>>
>> Actually I had quite a few customers in the past, where it was a PITA
>> to get more than one IP address per machine - even
>> from the RFC 1918 private space, so that the SBM was the only option
>> to them.
>>
>> Heiko
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 11 months
