[JBoss AS 7 Development] - Error while deploying jbpm-gwt-console-server-5.1.0.Final.war on Jboss AS7
by Garvit Jain
Garvit Jain [https://community.jboss.org/people/garvitj] created the discussion
"Error while deploying jbpm-gwt-console-server-5.1.0.Final.war on Jboss AS7"
To view the discussion, visit: https://community.jboss.org/message/766202#766202
--------------------------------------------------------------
Hi All, When i am trying to deploy jbpm-gwt-console-server-5.1.0.Final.war on Jboss AS7, i am facing issues the deployment is failing with error ....
10:08:32,151 ERROR [org.hibernate.internal.util.xml.ErrorLogger] (MSC service thread 1-1) HHH000196: Error parsing XML (5) : cvc-complex-type.3.1: Value '1.0' of attribute 'version
' of element 'entity-mappings' is not valid with respect to the corresponding attribute use. Attribute 'version' has a fixed value of '2.0'.
10:08:32,165 WARN [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-1) HHH000144: hibernate.connection.autocommit = false breaks the EJB3 specification
10:08:32,221 INFO [org.hibernate.service.jdbc.connections.internal.DriverManagerConnectionProviderImpl] (MSC service thread 1-1) HHH000402: Using Hibernate built-in connection poo
l (not for production use!)
10:08:32,223 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.persistenceunit."jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.t
ask": org.jboss.msc.service.StartException in service jboss.persistenceunit."jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task": Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_22]
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: org.jbpm.task] Unable to build EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:914)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:889)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:162)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.start(PersistenceUnitServiceImpl.java:85)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
... 3 more
Caused by: org.hibernate.HibernateException: Specified JDBC Driver org.h2.Driver class not found
at org.hibernate.service.jdbc.connections.internal.DriverManagerConnectionProviderImpl.configure(DriverManagerConnectionProviderImpl.java:104)
at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.buildJdbcConnectionAccess(JdbcServicesImpl.java:234)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:91)
at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71)
at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2270)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2266)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1735)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:84)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
... 9 more
Caused by: java.lang.ClassNotFoundException: org.h2.Driver from [Module "org.hibernate:main" from local module loader @fc9944 (roots: C:\jbossAS\modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_22]
at java.lang.Class.forName(Class.java:169) [rt.jar:1.6.0_22]
at org.hibernate.internal.util.ReflectHelper.classForName(ReflectHelper.java:192)
at org.hibernate.service.jdbc.connections.internal.DriverManagerConnectionProviderImpl.configure(DriverManagerConnectionProviderImpl.java:101)
... 23 more
10:08:32,495 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "jbpm-gwt-console-server-5.1.0.Final.war" was rolled back with failure mes
sage {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task\"" => "org.jboss.msc.service.StartException in service jboss.
persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task\": Failed to start service"},"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.web.dep
loyment.default-host./gwt-console-server.realmjboss.security.security-domain.jbpm-consoleMissing[jboss.web.deployment.default-host./gwt-console-server.realmjboss.security.security-
domain.jbpm-console]","jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.persistence.jpa\"jboss.naming.context.java.jboss.java:jdbc.testDS1Missing[jboss.pers
istenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.persistence.jpa\"jboss.naming.context.java.jboss.java:jdbc.testDS1]"]}
10:08:33,052 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment jbpm-gwt-console-server-5.1.0.Final.war in 559ms
10:08:33,054 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jboss.naming.context.java.jboss.java:jdbc.testDS1 (missing) dependents: [service jboss.persistenceunit."jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.persistence.j
pa"]
service jboss.security.security-domain.jbpm-console (missing) dependents: [service jboss.web.deployment.default-host./gwt-console-server.realm]
JBAS014777: Services which failed to start: service jboss.persistenceunit."jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task": org.jboss.msc.service.StartException in se
rvice jboss.persistenceunit."jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task": Failed to start service
10:08:33,063 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"O
peration step-2" => {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task\"" => "org.jboss.msc.service.StartException in
service jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.task\": Failed to start service"},"JBAS014771: Services with missing/unavailable dependencies" =>
["jboss.web.deployment.default-host./gwt-console-server.realmjboss.security.security-domain.jbpm-consoleMissing[jboss.web.deployment.default-host./gwt-console-server.realmjboss.sec
urity.security-domain.jbpm-console]","jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.persistence.jpa\"jboss.naming.context.java.jboss.java:jdbc.testDS1Mis
sing[jboss.persistenceunit.\"jbpm-gwt-console-server-5.1.0.Final.war#org.jbpm.persistence.jpa\"jboss.naming.context.java.jboss.java:jdbc.testDS1]"]}}}
Please let me know how can this error be resolved ..
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/766202#766202]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 4 months
[JBoss Tools Development] - How to Build JBoss Tools with Maven 3
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] modified the document:
"How to Build JBoss Tools with Maven 3"
To view the document, visit: https://community.jboss.org/docs/DOC-16604
--------------------------------------------------------------
**
#Environment_Setup Environment Setup
***
#Prerequisistes Prerequisistes
***
#Maven_and_Java Maven and Java
***
#Maven_settings Maven settings
***
#Maven__Java_Memory_Configuration Maven & Java Memory Configuration
**
#Verify_or_Install_ Verify or Install ?
**
#About_Target_Platform_and_related_profiles About Target Platform and related profiles
***
#Using_published_Target_Platform_definition_Recommanded Using published Target Platform definition (Recommanded)
***
#Or_getting_a_local_copy_of_the_Target_Platform Or, getting a local copy of the Target Platform
****
#Set_up Set up
*****
#_Download_TP_as_a_zip_and_install_it_by_yourself Download TP as a zip and install it by yourself
*****
#OR_use_MavenAnt_to_get_it OR, use Maven+Ant to get it
****
#Use Use
**
#Optional_Build_parent_and_target_platform (Optional) Build parent and target platform
**
#Building_Individual_Components_Locally_Via_Commandline Building Individual Components Locally Via Commandline
***
#Build_a_component_resolving_to_a_recent_aggregation_build_for_other_JBT_dependencies_Recommanded Build a component resolving to a recent aggregation build for other JBT dependencies (Recommanded)
***
#Build_a_component_resolving_to_the_latest_CI_builds_for_other_JBT_dependencies Build a component resolving to the latest CI builds for other JBT dependencies
***
#Build_a_component_along_with_all_its_dependencies_from_sources_bootstrap_build Build a component along with all its dependencies from sources ("bootstrap" build)
**
#Building_Everything_In_One_Build_Locally_Via_Commandline Building Everything In One Build Locally Via Commandline
**
#Building_Locally_In_Eclipse Building Locally In Eclipse
**
#Installation_Testing__making_sure_your_stuff_can_be_installed_ Installation Testing - making sure your stuff can be installed
**
#Adding_a_new_feature_or_plugin_to_an_existing_component Adding a new feature or plugin to an existing component
**
#Dealing_with_timeouts_for_tests Dealing with timeouts for tests
**
#Tips_and_tricks_for_making_BOTH_PDE_UI_and_headless_Maven_builds_happy Tips and tricks for making BOTH PDE UI and headless Maven builds happy
***
#Check_your_buildproperties Check your build.properties
***
#Check_your_manifestmf_dependencies Check your manifest.mf dependencies
+*This article is a replacement for its precursor, https://community.jboss.org/docs/DOC-15513 How to Build JBoss Tools 3.2 with Maven 3.*+
+*Note that this article only discusses building from trunk. If you need to build from a branch, or switch between branches and/or trunk, see* https://community.jboss.org/docs/DOC-17497 How to Build JBoss Tools With Maven3 - Working With Branches+*.*
*+Looking for how to build our documentation? See+ https://community.jboss.org/docs/DOC-13341 Building JBoss Tools Documentation.*
h2. Environment Setup
h3. Prerequisistes
1. Java 1.6 SDK
2. Maven 3.0.3
3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools) - *requires VPN access*
4. subversion client 1.6.X (should work with lower version as well, but newer versions may not work as expected)
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
mvn -version
should print out something like
*Apache Maven 3.0.3* (r1075438; 2011-02-28 12:31:09-0500)
*Java version: 1.6.0_25*, vendor: Sun Microsystems Inc.
*Java home: /usr/java/jdk1.6.0_25/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.42.3-2.fc15.x86_64", arch: "amd64", family: "unix"
h3. Maven settings
Follow https://community.jboss.org/docs/DOC-15170 these instructions to add reference to JBoss Repositories into your settings.xml. You'll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
....
<profiles>
....
<profile>
<id>jboss-default</id>
<repositories>
<!-- To resolve parent artifact -->
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
<repository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<pluginRepositories>
<!-- To resolve parent artifact -->
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</pluginRepository>
<pluginRepository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-default</activeProfile>
...
</activeProfiles>
</settings>
#
*What if Maven can't find the upstream artifacts in Nexus?*
Sometimes, Maven can't find the upstream artifacts - parent pom, tycho plugins, minimum (Juno SR0) or maximum (Juno SR1 or later) target platforms. To work around this, just build them locally:
cd /tmp; svn co http://anonsvn.jboss.org/repos/jbosstools/trunk/build/
mvn install -U -f build/parent/pom.xml
mvn install -U -f build/tycho-plugins/pom.xml
mvn install -U -f build/target-platforms/pom.xml -Pjbosstools-maximum,jbosstools-minimum
h3. Maven & Java Memory Configuration
To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here's how to do so for http://forums.fedoraforum.org/showthread.php?t=262465 Fedora, https://help.ubuntu.com/community/EnvironmentVariables Ubuntu, http://forums.techarena.in/windows-xp-support/1152405.htm Windows, http://www.digitaledgesw.com/node/31 OSX.
{code}
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
{code}
h2. Verify or Install ?
+mvn verify+ will perform all build and test steps, but it won't install the bundles in your local repository. +mvn install+ does install in you local repository. When an eclipse-plugin is installed in your repo, it is always used as default when resolving dependency. It is not possible to roll-back a local installation of a bundle, so in most cases, +mvn verify+ is to be prefered to +mvn install+. However, if you want to build stuff sequentially through several maven invocations, and you want to resolve against just-built stuff, you'll need to use +mvn install+.
In this page, we'll encourage people to use *mvn verify* as much as possible to ensure *isolation*; but you can mvn install the same way if your use-case requires it.
h2. About Target Platform and related profiles
The target platform (TP) lists all dependencies (coming from Eclipse.or and other 3rd-party update sites) that are used by JBoss Tools. This target platform is materialized as an Eclipse p2 repository (formerly update-site) that is used during build to resolve dependencies. Target Platform is managed by JBoss Tools people, and only dependencies from this TP are allowed to be used in code.
If you need a new dependency in the TP, feel free to https://issues.jboss.org/secure/CreateIssueDetails!init.jspa?pid=10020&su... open a ticket to request it.
Here are several ways to build locally using this target platform. It's up to you to choose the one that match your needs:
h3. Using published Target Platform definition (Recommanded)
unified.target refers to the dependency as published in the Target Platfrom repository.
* Pros:* No additional thing to do than invoking Maven
* Always up-to-date
* Cons: Speed - (to evaluate)
Consume it by adding* +-Punified.target+* to you Maven invocation command-line
h3. Or, getting a local copy of the Target Platform
* Pros: Speed +++
* Cons: Step to be repeated whenever https://source.jboss.org/browse/JBossTools/trunk/build/target-platform/un... target platform changes
h4. Set up
h5. Download TP as a zip and install it by yourself
You can either download the TP as a zip and unpack it into some folder on your disk. For convenience, the easiest is to unzip into jbosstools/build/target-platform/REPO/, since that's where the Maven or Ant process will by default operate.
You can get it with a browser or a command line tool such as wget or curl at the following url:
http://download.jboss.org/jbosstools/updates/juno/SR0c/ http://download.jboss.org/jbosstools/updates/juno/SR0c/ http://download.jboss.org/jbosstools/updates/juno/SR0c/e420-wtp340.target... e420-wtp340.target.zip (current minimum TP)
http://download.jboss.org/jbosstools/updates/juno/SR1a/ http://download.jboss.org/jbosstools/updates/juno/SR1a/ http://download.jboss.org/jbosstools/updates/juno/SR1a/e421-wtp341.target... e421-wtp341.target.zip (current maximum TP)
and then unzip it :
unzip *.target.zip -d /path/to/my jbosstools/build/target-platforms/jbosstools-JunoSR0c/local/target/REPO/
or
unzip *.target.zip -d /path/to/my jbosstools/build/target-platforms/jbosstools-JunoSR1a/local/target/REPO/
*(Note that the default path used for <local.site> will change every time a new target platform is released which is a significant change over the previous (eg., SR1, SR2), so if this breaks because the default not points at an empty folder, it's time to get a new TP! Hurray for build-time notification you're using an old target platform!)*
h5. OR, use Maven+Ant to get it
In that case, you also need Ant 1.8.2 or later*.*
cd jbosstools/build/target-platform
mvn clean install -Pget.local.target
The get.local.target profile will resolve the target platform file, multiple.target, as a p2 repository on your local disk in ~/trunk/build/target-platform/REPO/. It may take a while, so you're better off from a speed point-of-view simply fetching the latest zip [5]. However, if you want to see what actually happens to create the TP (as done in Hudson) this is the approach to take.
Since the Maven profile is simply a wrapper call to Ant, you can also use Ant 1.8 or later directly:
cd jbosstools/build/target-platform
ant help # show usage instructions
h4. Use
Just add -*P local.site -Dlocal.site=file:///path/to/target/repository/*
*NOTE:* You must specify a path starting with *file:///* (three or more slashes) to avoid errors such as "+p2.core.ProvisionException URI has an authority component+".
Examples
*LINUX / MAC USERS*
cd build
mvn clean install -U -B -fae -e -*P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/*| tee build.all.log.txt
*WINDOWS USERS*
cd c:\trunk\build
mvn3 clean install -U -B -fae -e -Plocal.site *-Dlocal.site=file:///C:/trunk/build/target-platform/REPO/* > build.all.log.txt
h2. (Optional) Build parent and target platform
This step is only useful if you are actually working on the parent or the target platform and want to test it locally. Otherwise, Maven will simply retrieve parent and TP from *https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/tools/ JBoss Nexus* to perform your build.
This is only necessary when the TP change, prior to 3.3.Beta3
svn co http://svn.jboss.org/repos/jbosstools/trunk jbosstools
cd jbosstools/build/parent
mvn clean install
...
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
[INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
...
*NOTE: You need not fetch the entire JBoss Tools tree from SVN (or Git (http://divby0.blogspot.com/2011/01/howto-partially-clone-svn-repo-to-git....
*Instead, you can just fetch the build/ folder and one or more component folders, then as before,*
*build the parent pom. After that, go into the component folder and run maven there (#runmavenpercomponent).*
mkdir jbosstools
cd jbosstools
svn co http://svn.jboss.org/repos/jbosstools/trunk/ http://svn.jboss.org/repos/jbosstools/trunk/build
svn co http://svn.jboss.org/repos/jbosstools/trunk/ http://svn.jboss.org/repos/jbosstools/trunk/jmx
cd jbosstools/build/parent
mvn clean install
...
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
[INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
...
h2. Building Individual Components Locally Via Commandline
h3. Build a component resolving to a recent aggregation build for other JBT dependencies (Recommanded)
* Pros:* You build only your component
* You only need source for your component
* Speed to resolve deps: +
* You get generally the latest build for you component
* Cons:* Takes some time to resolve dependencies on other component
* Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change. More risk to get out of sync than with the staging site.
Tracked by https://issues.jboss.org/browse/JBIDE-11516 https://issues.jboss.org/browse/JBIDE-11516
example:
*cd jmx*
mvn verify -P unified.target *-Pjbosstools-staging-aggregate*
h3. Build a component resolving to the latest CI builds for other JBT dependencies
* Pros:* You build only your component
* You only need source for your component
* You get generally the latest build for you component
* Cons* Takes some time to resolve dependencies on other component
* Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change
* Speed to resolve deps: -
This profile is the one use for CI builds on Hudson.
*cd jmx*
mvn verify -P unified.target *-Pjbosstools-nightly-staging-composite*
h3. Build a component along with all its dependencies from sources ("bootstrap" build)
This will build exactly what you have locally
* Pros:* You are sure of the version of sources that is used for your JBT dependencies
* You don't loose time in resolving your JBT deps
* Cons:* You need sources for your dependencies too
* You often build more stuff that what you really want to test
cd ~/trunk/build
mvn verify -P unified.target -*P jmx-bootstrap*
h2. Building Everything In One Build Locally Via Commandline
Assuming you have a local copy of the target platform in ${HOME}/trunk/build/target-platform/REPO/ (as explained previously:
*LINUX / MAC USERS*
cd build
mvn clean install -P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/ | tee build.all.log.txt
(tee is a program that pipes console output to BOTH console and a file so you can watch the build AND keep a log.)
*WINDOWS USERS*
cd c:\trunk\build
mvn3 clean verify -P local.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/
or
mvn3 clean verify -Plocal.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/ > build.all.log.txt
If you downloaded the zip and unpacked is somewhere else, use -Dlocal.site=file:///.../ to point at that folder instead
h2. Building Locally In Eclipse
First, you must have installed m2eclipse into your Eclipse (or JBDS). You can install the currently supported version from this update site:
http://download.jboss.org/jbosstools/updates/indigo/ http://download.jboss.org/jbosstools/updates/indigo/
Next, start up Eclipse or JBDS and do *File > Import* to import the project(s) you already checked out from SVN above into your workspace.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Browse to where you have the project(s) checked out, and select a folder to import pom projects. In this case, I'm importing the parent pom (which refers to the target platform pom). Optionally, you can add these new projects to a working set to collect them in your Package Explorer view.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Once the project(s) are imported, you'll want to build them. You can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. The following screenshots show how to configure a build job.
First, on the *Main* tab, set a *Name*, *Goals*, *Profile*(s), and add a *Parameter*. Or, if you prefer, put everything in the *Goals* field for simplicity:
+clean install -U -B -fae -e -Plocal.site -Dlocal.site=file://home/nboldt/tmp/JBT_REPO_Indigo/+
Be sure to check *Resolve Workspace artifacts*, and, if you have a newer version of Maven installed, point your build at that *Maven Runtime* instead of the bundled one that ships with m2eclipse.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *JRE* tab, make sure you're using a 6.0 JDK.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *Refresh* tab, define which workspace resources you want to refresh when the build's done.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
On the *Common* tab, you can store the output of the build in a log file in case it's particularly long and you need to refer back to it.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Click *Run* to run the build.
https://community.jboss.org/servlet/JiveServlet/showImage/102-16604-56-13... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-5...
Now you can repeat the above step to build any other component or plugin or feature or update site from the JBoss Tools repo. Simply import the project(s) and build them as above.
h2. Installation Testing - making sure your stuff can be installed
Each component, when built, produces a update site zip and an unpacked update site which can be used to install your freshly-built features and plugins into a running Eclipse or JBDS instance.
Simply point your Eclipse at that folder or zip, eg., jar:file:/home/rob/code/jbtools/jbosstools/trunk/runtime/site/target/runtime.site.zip! or file:///home/rob/code/jbtools/jbosstools/trunk/runtime/site/target/repository/, and browse the site. If your component requires other upstream components to install, eg., Runtime Detection depends on JBoss Common, you will also need to provide a URL from which Eclipse can resolve these missing dependencies. In order of freshness, you can use:
1. http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ (Nightly Trunk Site - updated every few hours or at least daily - *bleeding edge*)
2. http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ (Composite Staging Site - updated every time a component respins - *bleedinger edge*)
3. http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/local-site/ http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/local-site/ (see the README.txt for how to use this site to refer to things you built locally - *bleedingest edge*)
h2. Adding a new feature or plugin to an existing component
Need to tweak a component to add a new plugin or feature? See https://community.jboss.org/docs/DOC-18373 https://community.jboss.org/wiki/AddingAPluginandorFeatureToAnExistingCom....
h2. Dealing with timeouts for tests
(To be rewritten soon...) http://lists.jboss.org/pipermail/jbosstools-dev/2012-September/005835.html http://lists.jboss.org/pipermail/jbosstools-dev/2012-September/005835.html
h2. Tips and tricks for making BOTH PDE UI and headless Maven builds happy
It's fairly common to have plugins compiling in eclipse while tycho would not work. Basically you could say that tycho is far more picky compared to Eclipse PDE.
h3.
Check your build.properties
Check build.properties in your plugin. If it has warnings in Eclipse, you'll most likely end with tycho failing to compile your sources. You'll have to make sure that you correct all warnings.
Especially check your build.properties to have entries for *source..* and *output..* -- these are needed to *http://wiki.eclipse.org/Minerva#Source generate source plugins and features*.
*
*
source.. = src/
output.. = bin/
src.includes = *
src.excludes = src
bin.includes = <your own,\
list of,\
files for inclusion,\
in the jar>
h3. Check your manifest.mf dependencies
A new issue when building against juno shows that all compilation dependencies MUST be EXPLICITLY mentioned in your manifest.mf list of dependencies. A recent example of how this can cause compilation errors is the archives module, which failed to build due to the org.eclipse.ui.views plugin, and its IPropertySheetPage interface, not being found during the build. After investigation, it was discovered that the archives.ui plugin did not explicitly declare a dependency on org.eclipse.ui.views.
Inside eclipse and during indigo builds, however, the depencency was found and there were no compilation errors. This was because a plugin archives.ui explicitly dependend on (org.eclipse.ui.ide) had an explicit dependency on org.eclipse.ui.views. The IDE was able to see that archives.ui dependended on org.eclipse.ui.ide, and org.eclipse.ui.ide depended on org.eclipse.ui.views.
Resolving nested dependencies no longer seems to be guaranteed, and so anything you have a compilation dependency on must now be explicitly declared in your manifest.mf
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16604]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 4 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching
by Jeff Mesnil
Jeff Mesnil [https://community.jboss.org/people/jmesnil] commented on the document
"Single Installation Patching"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-10927
--------------------------------------------------
>
> Brian Stansberry wrote:
>
> What's in thie previous-cumulative file? Just the name of the applied to version?
Yes, for history purpose, I think it's important to tell the user which version the patch has been applied to (among all the acceptable <applies-to-version> of the patch). He would want to know what will be the resulting version of a rollback prior to perform it.
>
> I think we are going to need to store the patch.xml, which contains that information plus much more. That or something similar. For sure we are going to need to store the hashes of any files changed in a one-off patch, plus data about any misc file changes that the user elected not to have applied. We'll need this information for when we apply a CP on top of a one-off patch.
This contradicts the previous sentence about cumulative patches invalidating all one-off patches.
The way I represent the patches is a stack composed of 3 different parts on top of each others:
+--------------------+
| one-off patches | * always applied at the top of a base version or a cumulative patch
| | * can be empty if no one-off patches have been applied
+--------------------+
| cumulative patches | * stack of applied cumulative patches
| | * can be empty if no cumulative patches have been appplied
+--------------------+
| base version | * the base version of this AS7 installation
+--------------------+ * always present
The stack is ordered by the date at which the patch has been applied, the most recent applied patch is at the top.
This is a correct representation if a CP invalidates one-off patches. eg to patch with a new CP, we must first rollback all the applied one-off patches (whether it's part of the patch procedure or an user intervention is to be determined).
Playing a bit with a show-history command, I'd expect to have an outcome such as:
[standalone@localhost:9999 core-service=patching] :show-history
{
"outcome" => "success",
"result" => {
"one-offs" => [
{
"patchID" => "patch-xyz",
"applied-to" => "7.2.3",
"applied-at" => "YYYY MM DD, HH:mm"
},
{
"patchID" => "patch-abc",
"applied-to" => "7.2.3",
"applied-at" => "YYYY MM DD, HH:mm"
}
],
"cumulatives" => [
{
"patchID" => "patch-YYY",
"resulting-version" => "7.2.3",
"applied-to" => "7.2.1",
"applied-at" => "YYYY MM DD, HH:mm"
},
{
"patchID" => "patch-XXX",
"resulting-version" => "7.2.1",
"applied-to" => "7.2.0",
"applied-at" => "YYYY MM DD, HH:mm"
}
],
"base-version" => "7.2.0.Alpha1-SNAPSHOT"
}
}
what do you think of this "stack" representation of the patches? Is it correct?
--------------------------------------------------
13 years, 4 months
[JBoss Transactions Development] - Narayana Release Process
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] modified the document:
"Narayana Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-17433
--------------------------------------------------------------
This page provides a list of instructions that must be done *in order* when doing a release of Narayana.
h2. Check JIRA
Ensure all issues are resolved. Any outstanding issues must be pushed back or resolved.
h2. Check Hudson
Ensure no test failures in the following group of hudson tests (for the branch you intend to release):
* 4.16 Branch : jbossts-branch416-*
* 4.17 Branch : jbossts-branch417-*
* 5 Branch: jbossts-narayana-*
h2. Do Release
h3. Git Branches (4.17 and 5 only)
Must be done first as the build-release-packages.xml relies on the tag being available
For REPO in (documentation quickstarts narayana); do
REPO=<REPO>
BRANCH=<4.17|master>
CURRENT=<Point version to release>
NEXT=<point version of next release, likely to be $CURRENT+1>
git clone mailto:git@github.com git@github.com:jbosstm/$REPO.git
cd $REPO
git checkout $BRANCH
find . -name \*.java -o -name \*.xml -o -name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | grep -v .idea | xargs sed -i "s/4\([._]\)17\([._]\)$CURRENT\([._]\)Final-SNAPSHOT/4\117\2$CURRENT\3Final/"
git commit -am "Updated to 4.17.$CURRENT.Final"
git tag 4.17.$CURRENT.Final
find . -name \*.java -o -name \*.xml -o -name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | grep -v .idea | xargs sed -i "s/4\([._]\)17\([._]\)$CURRENT\([._]\)Final/4\117\2$NEXT\3Final-SNAPSHOT/"
git commit -am "Updated to 4.17.$NEXT.Final-SNAPSHOT"
git push origin $BRANCH --tags
h3. Update our AS7 fork
#Update the maven version of jbossts in our fork of JBossAS: https://github.com/jbosstm/jboss-as https://github.com/jbosstm/jboss-as
git clone -o jbosstm https://github.com/jbosstm/jboss-as
git checkout 5_BRANCH
sed -i "s/5.0.0.M1-SNAPSHOT/5.0.0.M2-SNAPSHOT/g" pom.xml
git commit -am "Updated to 5.0.0.M2-SNAPSHOT"
git push jbosstm 5_BRANCH
h2. Build and release
#Build and deploy the release to nexus staging:
mkdir ~/narayana/filemgmt.jboss.org/
sshfs mailto:jbosstm@filemgmt.jboss.org jbosstm(a)filemgmt.jboss.org: ~/narayana/filemgmt.jboss.org/
git checkout 4.17.0.Final
ant -f build-release-pkgs.xml dist downloads docs magnolia
h3. svn branches
#Make sure your checkout has no local changes
svn update
svn status
POINT_VERSION=5
NEXT_POINT_VERSION=6
#Update the version in text files
find . -name \*.java -o -name \*.xml -o -name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v target | xargs grep -l "4[._]16" | xargs sed -i "s/4\([._]\)16\([._]\)${POINT_VERSION}\([._]\)Final-SNAPSHOT/4\116\2$POINT_VERSION\3Final/"
svn commit -m "Updated to version 4.16.$POINT_VERSION.Final"
#Tag the release:
svn cp https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_16 https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_16 https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_4_Final/ https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_${POINT_V... -m "4.16.$POINT_VERSION"
#Bump to next version using similar find to above
find . -name \*.java -o -name \*.xml -o -name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v target | xargs grep -l "4[._]16" | xargs sed -i "s/4\([._]\)16\([._]\)${POINT_VERSION}\([._]\)Final/4\116\2${NEXT_POINT_VERSION}\3Final-SNAPSHOT/"
svn commit -m "Updated to version 4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT"
#Update the maven version of jbossts in our fork of JBossAS: https://github.com/jbosstm/jboss-as https://github.com/jbosstm/jboss-as
git checkout 4_16_BRANCH
git pull --rebase --ff-only
#Check no local changes
git status
sed -i "s/4.16.${POINT_VERSION}.Final-SNAPSHOT/4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT/g" pom.xml
git commit -am "Updated to 4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT"
git push
#Build and deploy the release to nexus staging:
mkdir ~/filemgmt.jboss.org/
sshfs mailto:jbosstm@filemgmt.jboss.org jbosstm(a)filemgmt.jboss.org: ~/filemgmt.jboss.org/
svn switch https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_$ https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_${NEXT_PO...
ant -f build-release-pkgs.xml dist mvn-repository downloads magnolia
h3.
h2. Release the artifact through Nexus
1. https://repository.jboss.org/nexus/index.html#welcome https://repository.jboss.org/nexus/index.html#welcome
2. login
3. "Staging Repositories"
4. Click tickbox for your repo
5. Click "Close"
6. Don't worry about a description, just click "Close"
7. Click tickbox after it is closed
8. Click "Release"
9. Again a description doesn't matter
h2. JIRA Release
1. Check all issues resolved.
2. Create next point release version if not exists - this is so you can push issues in step 3 below.
3. Unresolved issues should be resolved or pushed.
4. Close all issues for the release
5. Mark as released (Need admin permissions)
h2. Update Website
Update the Narayana community site:
* Login to Magnolia* https://www.jboss.org/author/.magnolia/pages/adminCentral.html https://www.jboss.org/author/.magnolia/pages/adminCentral.html
* Login with credentials: Tom and Paul know these, ask them.
* Documentation* Browse to 'jbosstm/documentation'
* right click on 'downloads' and select 'import'
* browse to the location of the 'website.jbosstm.documentation.4.16.5.Final.xml' file
* Right click on the new file and click 'move'
* Drag the file to the top of the documentation list.
* Right click on the new page and select 'open page...'
* Check that the page looks right and that the download links work
* Right click on the new page and select 'activate'
* You now need to wait for the page to be moderated before it will appear.
* Downloads* Browse to 'jbosstm/downloads'
* right click on 'downloads' and select 'import'
* browse to the location of the 'website.jbosstm.downloads.4.16.5.Final.xml' file
* Right click on the new file and click 'move'
* Drag the file to the top of the downloads list.
* Right click on the new page and select 'open page...'
* Check that the page looks right and that the download links work
* Right click on the new page and select 'activate'
* You now need to wait for the page to be moderated before it will appear.
* Announcement* Right click on 'jbosstm' and select 'open page...'
* Click edit on the 'announcement' pane
* Update the announcement for this release.
* Right click on 'jbosstm' and select 'activate changes'
* You now need to wait for the page to be moderated before it will appear.
* Release notes* Right click on 'jbosstm' and select 'open page...'
* Click edit on the 'getting started' pane on the right-hand-side
* Edit the release notes url to point to the release notes for this version
* Click save
* Right click on 'jbosstm' and select 'activate changes'
* You now need to wait for the page to be moderated before it will appear.
h2. Push Upstream
If appropriate for this release, create a new 'component update' issue in AS7 JIRA. Ensure the module is set to 'transactions' and select an appropriate 'fix for'.
Assign it to yourself
Resolve the work and raise the pull request
1. https://issues.jboss.org/browse/AS7 https://issues.jboss.org/browse/AS7
2. cd AS source
3. git checkout -b AS7-<JIRANUMBER>
4. sed -i "s/4.16.3.Final/4.16.4.Final/g" pom.xml
5. git commit -am "AS7-<JIRA> Updated to 4.16.4.Final"
6. git push
7. Raise a pull request
h2. Promote
NOTE: It is worth waiting for the merge of the pull request before advertising, or at least wait for the merge build notification first ;)
Promote the release through the following channels:
1. Email jbossts-announce(a)lists.jboss.org (mailto:jbossts-announce@lists.jboss.org)
2. Forum
3. Blog - as appropriate
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17433]
Create a new document in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 5 months
[JBoss AS 7 Development] - Build error
by Filippe Spolti
Filippe Spolti [https://community.jboss.org/people/spolti] created the discussion
"Build error"
To view the discussion, visit: https://community.jboss.org/message/764874#764874
--------------------------------------------------------------
Hello guys,
I'm trying to compile jboss-as-7 in my desktop and i get the follow error:
Results :
Failed tests: testTransformers1_0_0(org.jboss.as.configadmin.parser.ConfigAdminParserTestCase): expected:<org.jboss.as.model.test.ChildFirstClassLoader@777af56e> but was:<sun.misc.Launcher$AppClassLoader@60b99e4c>
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3:39.735s
[INFO] Finished at: Mon Oct 15 14:26:16 BRT 2012
[INFO] Final Memory: 142M/432M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.11:test (default-test) on project jboss-as-configadmin: There are test failures.
[ERROR]
[ERROR] Please refer to /dados/JAVA/jboss-as/jboss-as-7.1-src/jboss-as/configadmin/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :jboss-as-configadmin
Im using maven 3.0.2 and java 7, i try with java 6_35 to...
Some help?
Regards.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/764874#764874]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
[JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] modified the document:
"Design of AS7 multi-JSF feature"
To view the document, visit: https://community.jboss.org/docs/DOC-47689
--------------------------------------------------------------
*About multi-JSF*
Currently, AS7 ships with two JSF implementations, a JSF 2.1 implementation and a JSF 1.2 implementation. A web application can select which implementation is used by including a context param in web.xml. By default, it uses the JSF 2.1 imlementation.
"multi-JSF" allows installation of multiple JSF implementations (and versions) on the same AS7 server. The goal is to allow use of any JSF implementation (MyFaces or Mojarra) and any version of those implementation from JSF 1.1 all the way up to the experimental JSF 2.2 versions. This is far superior to the old WAR_BUNDLES_JSF_IMPL method because JSF jars do not need to be bundled with the webapp. More importantly, "multi-JSF" provides an implementation that is fully integrated with the container. This means more efficient annotation processing, lifecycle handling, and other integration advantages.
*How it works*
The way multi-JSF will work is that for each JSF version, a new slot is created in the modules path under *com.sun.jsf-impl*, *javax.faces.api*, and *org.jboss.as.jsf-injection*. When the jsf-subsystem is started, it scans the module path to find all the installed JSF implementations. When the JSF subsystem deploys a web app containing the specified context param, it adds the slotted modules to the deployment.
Here is an example of the context param for the latest milestone of Mojarra 2.2:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>mojarra-2.2.0-m05</param-value>
</context-param>
*How a JSF implementation is installed*
A single JSF implementation is installed using a https://community.jboss.org/docs/DOC-18945 CLI deployment archive. This archive includes the required jars and module.xml files. It also includes CLI scripts for installing/uninstalling the JSF impls using the https://issues.jboss.org/browse/AS7-4265 CLI module command. You execute the installation archive like this:
> [standalone@localhost:9999 /] deploy <local path to archive>/install-mojarra-2.2.0-m05.cli
The install script inside the archive looks like this:
> module add --name=javax.faces.api --slot=mojarra-2.2.0-m05 --resources=jsf-api-2.2.0-m05.jar --module-xml=mojarra-api-module.xml
> module add --name=com.sun.jsf-impl --slot=mojarra-2.2.0-m05 --resources=jsf-impl-2.2.0-m05.jar --module-xml=mojarra-impl-module.xml
> module add --name=org.jboss.as.jsf-injection --slot=mojarra-2.2.0-m05 --resources=jboss-as-jsf-injection-7.2.0.Alpha1-SNAPSHOT.jar --module-xml=injection-module.xml
*How the CLI deployment archives are created*
A CLI deployment archive for a JSF implementation/version is created using a standalone maven project. To create an archive with the project, you call it like this:
> mvn -Djsf-version=2.2.0-m05 -Pmojarra clean assembly:single
This pulls in the JSF resources and creates the install/uninstall scripts. It is all bundled together in an archive (zip) file that is renamed with a .cli extension.
My current thinking is that we might not need to release the maven project that creates the CLI deployment archives. There is a finite number of JSF implementations and versions. So we could simply create all the possible archives and make them available for download. I suspect that the total number of these is less than 50. However, the current implementation relies on a particular version of the jsf-injection module that ships with AS7. So it really means about 50 archives each time the jsf-injection module changes. I might be able to eliminate the inclusion of jsf-injection in the future.
*Demo*
I've attached a copy of install-mojarra-2.2.0-m05.cli and install-myfaces-2.1.8.cli. You can unzip to take a look at it. You can even deploy it with the latest nightly build of AS7. This will let you see how the modules are installed. I'm not quite done with updates to the jsf-subsystem, so you can't see multi-jsf in action on a webapp yet. If you want to try it out though, let me know. I can upload a working version to my github account.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47689]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 5 months
