[JBoss Tools Development] - JBoss Tools Target Platform Provisioning (or, how to resolve missing dependencies when compiling JBoss Tools)
by Brian Fitzpatrick
Brian Fitzpatrick [http://community.jboss.org/people/bfitzpat] modified the document:
"JBoss Tools Target Platform Provisioning (or, how to resolve missing dependencies when compiling JBoss Tools)"
To view the document, visit: http://community.jboss.org/docs/DOC-15755
--------------------------------------------------------------
*+This document is a work in progress and subject to change.+*
In order to build JBoss Tools in your workspace (or on your local machine, if not in Eclipse), you need to have its dependencies available. There are a number of ways to accomplish this, depending on your needs and how much manual effort you'd like to expend.
First, you'll need the JBoss Tools sources on disk. Fetch sources from trunk (or another branch) into ~/tru (or another location on disk).
svn co http://anonsvn.jboss.org/repos/jbosstools/trunk/ http://anonsvn.jboss.org/repos/jbosstools/trunk/ ~/tru
Next, you can either install the target platform update site into your Eclipse install, or simply let Tycho fetch all the dependencies into a local m2 cached repository.
*------------------------------*
*
*
*OPTION 1: Install Target Platform Update Site into Eclipse*
Point the latest Eclipse 3.6.x build at the http://download.jboss.org/jbosstools/updates/target-platform/latest/ Target Platform update site (generated from this http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36... e361-wtp322.target file). Be sure to show uncategorized features, then install everything.
http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
After restarting Eclipse, you should have all the dependencies installed to develop JBoss Tools; however, if you want to use this Eclipse as the target platform against which to build using Tycho, you need to also unzip the latest http://http//download.eclipse.org/eclipse/downloads/drops/R-3.6.1-2010090... deltapack (eg., eclipse-M20101020-0925-delta-pack.zip) into your Eclipse root folder. Once you've done that, you can use the following commands to tell Maven (and Tycho) to use that Eclipse instead of doing its own resolution.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Build parent + target platform poms (should only take a few mins; includes 18M of downloaded artifacts into your local Maven cache, eg., ~/.m2).
cd ~/tru/build; mvn3 clean install -f http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml
b) Build all components or use the bootstrap profiles in http://anonsvn.jboss.org/repos/jbosstools/trunk/build/pom.xml build/pom.xml to build a stack of components, such as Seam:
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-Dtycho.targetPlatform=/path/to/your/eclipse*
*or*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+* -Dtycho.targetPlatform=/path/to/your/eclipse* *+-P seam-bootstrap+*
Note that if you install http://m2eclipse.sonatype.org/ m2eclipse, you can also start mvn3 builds from within Eclipse.
*------------------------------*
*
*
*OPTION 2: Let Tycho Resolve Dependencies From Remote Repo Into Local Cache
*
In this case, you don't even need Eclipse installed - you just need the sources on disk.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Build parent + target platform poms (should only take a few mins; includes 18M of downloaded artifacts into your local Maven cache, eg., ~/.m2).
cd ~/tru/build; mvn3 clean install -f http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml
b) Build one or more components (when done, ~/.m2 will be 1.1G in size):
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P \!helios,helios-remote-target*
*or*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+** *-P \!helios,helios-remote-target* *+-P seam-bootstrap+*
The 'helios-remote-target' will fetch all dependencies from this update site:
http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
*------------------------------*
*
*
*OPTION 3: Let Tycho Resolve Dependencies From Local Repo Into Local Cache*
*
*
** If have a local Target Platform repo already mirrored on disk (for example, you http://download.jboss.org/jbosstools/updates/target-platform/ downloaded a zip of the above update site and unpacked it somewhere, you can use the 'helios-local-target' profile.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Edit the http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml to point to the correct path on disk, and rebuild it. (The default path is the one that Hudson uses.)
vi parent/pom.xml # search for 'helios-local-target'
mvn3 clean install -f parent/pom.xml
b) Build using the 'helios-local-target' profile you modified to point to the correct location on your disk.
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P \!helios,helios-local-target *
*or+
+*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P \!helios,helios-local-target +-P seam-bootstrap+*
This is how the Hudson builds run: compile the parent & target platform pom.xml files, then build the desired component(s) against a locally available update site.
*------------------------------*
Note that if you install http://m2eclipse.sonatype.org/ m2eclipse, you can also start mvn3 builds from within Eclipse.
For other ways to build, see http://community.jboss.org/docs/DOC-15513 http://community.jboss.org/wiki/HowtoBuildJBossToolswithMaven3
h2.
Checking the Target Platform To See What's There
There are three ways to see what's already in the Target Platform. (This can be useful if you're checking to see if something's already there or needs to be added.)
Option 1:
1. In Eclipse, go to Help->Install New Software...
2. Provide the URL: http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
3. Click Add and give it a useful name such as "Current JBoss Tools Target Platform"
4. Browse the list of features. Note that you may have to uncheck the "Group Items By Category" checkbox.
Option 2:
Explore the file: http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36... in an XML editor or Eclipse's Target Platform editor
Option 3:
Explore the file: http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36.... This file is the same as the .target file but as an Ant script --does not contain feature/plugin versions, just repo URLs and a list of IUs (feature.group == feature + contained plugins)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15755]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Tools Development] - Eclipse Summit 2010 Mini-Agenda
by Nick Boldt
Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document:
"Eclipse Summit 2010 Mini-Agenda"
To view the document, visit: http://community.jboss.org/docs/DOC-16029
--------------------------------------------------------------
This doc outlines the items Nick and Max will be working on during Eclipse Summit:
(currently just random issues)
== Parent Pom & Target Platform Building ==
Why is helios-remote-target not the default one for our builds ?
* It is enabled by default, along with the "helios" profile which includes all the Eclipse.org and google.com sites against which the helios-remote-target's site is built. So... maybe we no longer need the "helios" one to be enabled by default? ~Nick
Why does our pom not have relative path references so you don't have to install parent first ?
i.e. <relativePath>../../../build/parent/pom.xml</relativePath>
* If we use relative pom's shouldn't we make the aggregator pom for "modules" a parent pom that references to the uber-pom ? (avoids the need to update too much the children and allow each module to adjust for their needs - i.e. run tests non-ui harness)
== Testing ==
We should use two surefire runs to seperate (fast) unit tests from (slow) integration tests, i.e. use failsafe plugin or simply use IT* as the pattern for integration tests. -- Agreed. Can have different profiles w/ different classname filters in the parent/pom.xml. I was thinking more like http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing where its split in same profile via mvn test and mvn integration-test goals.
We should find out how we can run some plugins with uiharness and others without, even within same plugin.
== Source Bundles ==
Can we generate source bundles so we get source features ? (see egit for example of this)
(note: source features != sdk features since these doesn't include the binary) -- Apparently yes, but @d_a_carver says the egit stuff doesn't work. Yes, but git://github.com/pieceoftheloaf/tycho-examples.git for some reason do (at least I get sources plugin built).
== Maven depoy ==
At least our pom's should be deployed to repository.org
Need to start actually use versioning.
== Dependencies ==
We have an issue with javax.soap 1.2 vs. javax.soap 1.3 we haven't been able to resolve - JBIDE-6450 - need some idea on how to resolve it.
Teiid/Savara extraneous dependencies (on datatools.enablement.sdk.feature (JBIDE-7443) or osgi package (instead of containing bundle/plugin/feature - SAVARA-141)
Decide contents of [JBDS Target Platform + 3rd Party Site] vs. [JBT TP] (ie., where to put things like m2eclipse, gwt, springide, testng and how to clearly state level of support)
Can we use tycho's "semi" support for maven dependencies for 3rd party jars, i.e. modeshape, drools and others have these jars in the system.
Check if upper/lower bound of plugins can be checked/applied so we get consistent p2/update behavior.
== Documentation & Auditing ==
Tracking contents of JBT/JBDS when built as aggregation - JBIDE-7444
Create new HTML generator for both jboss.org and standalone index.html page (JBIDE-6958, JBIDE-7045)
Create new tool to diff between releases "sanity checker" - JBIDE-6343
Update docs re: building, testing, provisioning:
* http://community.jboss.org/docs/DOC-15755 http://community.jboss.org/wiki/JBossToolsTargetPlatformProvisioningorhow...
* http://www.jboss.org/tools/docs/building http://www.jboss.org/tools/docs/building
* http://www.jboss.org/tools/docs/testing http://www.jboss.org/tools/docs/testing
* ...?
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16029]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Tools Development] - Eclipse Summit 2010 Mini-Agenda
by Nick Boldt
Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document:
"Eclipse Summit 2010 Mini-Agenda"
To view the document, visit: http://community.jboss.org/docs/DOC-16029
--------------------------------------------------------------
This doc outlines the items Nick and Max will be working on during Eclipse Summit:
(currently just random issues)
== Parent Pom & Target Platform Building ==
Why is helios-remote-target not the default one for our builds ?
* It is enabled by default, along with the "helios" profile which includes all the Eclipse.org and google.com sites against which the helios-remote-target's site is built. So... maybe we no longer need the "helios" one to be enabled by default? ~Nick
Why does our pom not have relative path references so you don't have to install parent first ?
i.e. <relativePath>../../../build/parent/pom.xml</relativePath>
* If we use relative pom's shouldn't we make the aggregator pom for "modules" a parent pom that references to the uber-pom ? (avoids the need to update too much the children and allow each module to adjust for their needs - i.e. run tests non-ui harness)
== Testing ==
We should use two surefire runs to seperate (fast) unit tests from (slow) integration tests, i.e. use failsafe plugin or simply use IT* as the pattern for integration tests. -- Agreed. Can have different profiles w/ different classname filters in the parent/pom.xml
We should find out how we can run some plugins with uiharness and others without.
== Source Bundles ==
Can we generate source bundles so we get source features ? (see egit for example of this)
(note: source features != sdk features since these doesn't include the binary) -- Apparently yes, but @d_a_carver says the egit stuff doesn't work.
== Dependencies ==
We have an issue with javax.soap 1.2 vs. javax.soap 1.3 we haven't been able to resolve - JBIDE-6450 - need some idea on how to resolve it.
Teiid/Savara extraneous dependencies (on datatools.enablement.sdk.feature (JBIDE-7443) or osgi package (instead of containing bundle/plugin/feature - SAVARA-141)
Decide contents of [JBDS Target Platform + 3rd Party Site] vs. [JBT TP] (ie., where to put things like m2eclipse, gwt, springide, testng and how to clearly state level of support)
== Documentation & Auditing ==
Tracking contents of JBT/JBDS when built as aggregation - JBIDE-7444
Create new HTML generator for both jboss.org and standalone index.html page (JBIDE-6958, JBIDE-7045)
Create new tool to diff between releases "sanity checker" - JBIDE-6343
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16029]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Tools Development] - Eclipse Summit 2010 Mini-Agenda
by Nick Boldt
Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document:
"Eclipse Summit 2010 Mini-Agenda"
To view the document, visit: http://community.jboss.org/docs/DOC-16029
--------------------------------------------------------------
This doc outlines the items Nick and Max will be working on during Eclipse Summit:
(currently just random issues)
Why is helios-remote-target not the default one for our builds ?
Why does our pom not have relative path references so you don't have to install parent first ?
i.e. <relativePath>../../../build/parent/pom.xml</relativePath>
If we use relative pom's shouldn't we make the aggregator pom for "modules" a parent pom that references to the uber-pom ? (avoids the need to update too much the children and allow each module to adjust for their needs - i.e. run tests non-ui harness)
We should use two surefire runs to seperate (fast) unit tests from (slow) integration tests, i.e. use failsafe plugin or simply use IT* as the pattern for integration tests. -- Agreed. Can have different profiles w/ different classname filters in the parent/pom.xml
We should find out how we can run some plugins with uiharness and others without.
Can we generate source bundles so we get source features ? (see egit for example of this)
(note: source features != sdk features since these doesn't include the binary) -- Apparently yes, but @d_a_carver says the egit stuff doesn't work.
We have an issue with javax.soap 1.2 vs. javax.soap 1.3 we haven't been able to resolve - JBIDE-6450 - need some idea on how to resolve it.
Teiid/Savara extraneous dependencies (on datatools.enablement.sdk.feature (JBIDE-7443) or osgi package (instead of containing bundle/plugin/feature - SAVARA-141)
Decide contents of [JBDS Target Platform + 3rd Party Site] vs. [JBT TP] (ie., where to put things like m2eclipse, gwt, springide, testng and how to clearly state level of support)
Tracking contents of JBT/JBDS when built as aggregation - JBIDE-7444
Create new HTML generator for both jboss.org and standalone index.html page (JBIDE-6958, JBIDE-7045)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16029]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Tools Development] - Eclipse Summit 2010 Mini-Agenda
by Brian Fitzpatrick
Brian Fitzpatrick [http://community.jboss.org/people/bfitzpat] modified the document:
"Eclipse Summit 2010 Mini-Agenda"
To view the document, visit: http://community.jboss.org/docs/DOC-16029
--------------------------------------------------------------
This doc outlines the items Nick and Max will be working on during Eclipse Summit:
(currently just random issues)
Why is helios-remote-target not the default one for our builds ?
Why does our pom not have relative path references so you don't have to install parent first ?
i.e. <relativePath>../../../build/parent/pom.xml</relativePath>
If we use relative pom's shouldn't we make the aggregator pom for "modules" a parent pom that references to the uber-pom ? (avoids the need to update too much the children and allow each module to adjust for their needs - i.e. run tests non-ui harness)
We should use two surefire runs to seperate (fast) unit tests from (slow) integration tests, i.e. use failsafe plugin or simply use IT* as the pattern for integration tests.
We should find out how we can run some plugins with uiharness and others without.
Can we generate source bundles so we get source features ? (see egit for example of this)
(note: source features != sdk features since these doesn't include the binary)
We have an issue with javax.soap 1.2 vs. javax.soap 1.3 we haven't been able to resolve - https://jira.jboss.org/browse/JBIDE-6450 https://jira.jboss.org/browse/JBIDE-6450 - need some idea on how to resolve it.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16029]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Tools Development] - Eclipse Summit 2010 Mini-Agenda
by Max Andersen
Max Andersen [http://community.jboss.org/people/max.andersen%40jboss.com] modified the document:
"Eclipse Summit 2010 Mini-Agenda"
To view the document, visit: http://community.jboss.org/docs/DOC-16029
--------------------------------------------------------------
This doc outlines the items Nick and Max will be working on during Eclipse Summit:
(currently just random issues)
Why is helios-remote-target not the default one for our builds ?
Why does our pom not have relative path references so you don't have to install parent first ?
i.e. <relativePath>../../../build/parent/pom.xml</relativePath>
If we use relative pom's shouldn't we make the aggregator pom for "modules" a parent pom that references to the uber-pom ? (avoids the need to update too much the children and allow each module to adjust for their needs - i.e. run tests non-ui harness)
We should use two surefire runs to seperate (fast) unit tests from (slow) integration tests, i.e. use failsafe plugin or simply use IT* as the pattern for integration tests.
We should find out how we can run some plugins with uiharness and others without.
Can we generate source bundles so we get source features ? (see egit for example of this)
(note: source features != sdk features since these doesn't include the binary)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16029]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss AS7 Development] - Hacking on AS7
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically put move commits, if you have any, on top of the latest master, you can leave it off if you do not). Please note that --rebase is very important if you have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words - the branch gets all messed up :) and rebasing against latest master (see point 12) will be a lot of pain. To don't forget --rebase option you may want to create an alias*
*
*
$ git config --global alias.up "pull --rebase"
*and then just use the new alias instead of pull*
*
* $ git up upstream master
h4. 7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
*You might need to say -f to force the changes. Read the note on 12 though before you do it.*
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss AS7 Development] - Hacking on AS7
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically put move commits, if you have any, on top of the latest master, you can leave it off if you do not)*
h4. 7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
*You might need to say -f to force the changes. Read the note on 12 though before you do it.*
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months