[JBoss Tools Development] - How to Build JBoss Tools with Maven 3
by Nick Boldt
Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document:
"How to Build JBoss Tools with Maven 3"
To view the document, visit: http://community.jboss.org/docs/DOC-16604
--------------------------------------------------------------
+*This article is a replacement for its precursor, http://community.jboss.org/docs/DOC-15513 How to Build JBoss Tools 3.2 with Maven 3.*+
h2. Prerequisites
1. Java 1.6 SDK
2. Maven 3
3. Ant 1.7.1 or later
4. 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*
5. subversion client 1.6.X (should work with lower version as well)
h2. Environment Setup
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.2* (r1056850; 2011-01-08 19:58:10-0500)
*Java version: 1.6.0_20*, vendor: Sun Microsystems Inc.
*Java home: /usr/java/jdk1.6.0_20/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32.23-170.fc12.i686", arch: "i386", family: "unix"
h2.
h2. Building Locally Via Commandline
To run a local build of JBoss Tools 3.3 against the new Eclipse 3.7-based Target Platform, I suggest a three-step approach:
a) build the parent & target platform poms (v0.0.2-SNAPSHOT) *[ONLY NEEDED WHEN THESE CHANGE]*
b) resolve the target platform to your local disk *[ONLY NEEDED WHEN THESE CHANGE]*
c) build against your local copy of the target platform [every time you change sources and want to rebuild]
Once (a) and (b) are done, you need only perform (c) iteratively until you're happy (that is, until everything compiles). This lets you test changes locally before committing back to SVN.
*(a) and (b) need only be done when the parent pom and Target Platform (TP) change.* Of course if we get these published to nexus then you may not need those first bootstrapping steps. Stay tuned - work in progress.
*a) build the parent & target platform poms (v0.0.2-SNAPSHOT)*
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/build
svn co 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]
...
*b) resolve the target platform to your local disk*
There are two ways to do this:
i) Download and unpack the latest TP zip, *OR*
ii) Resolve the TP using Maven or Ant
+i) Download and unpack the latest TP zip+
You can either download the TP as a zip [5] 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 do that with any browser or on a command line with curl or similar:
curl -C - -O http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 606M 100 606M 0 0 164k 0 1:02:54 1:02:54 --:--:-- 172k
and then unzip it:
mkdir jbosstools/build/target-platform/REPO
unzip e37M7-wtp33M7.target.zip -d jbosstools/build/target-platform/REPO
[5] http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e... http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
*OR*
*
*
+ii) Resolve the TP using Maven or Ant with wget
+
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 ~/3.3.indigo/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.7.1 or later directly:
cd jbosstools/build/target-platform
ant
*c) build against your local copy of the target platform*
*LINUX / MAC USERS*
cd build
mvn clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/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:\3.3.indigo\build
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:///C:/3.3.indigo/build/target-platform/REPO/
or
mvn3 clean install -U -B -fae -e -Plocal.site -Dlocal.site=file:///C:/3.3.indigo/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.
#
If you would rather build a single component (or even just a single plugin), go into that folder and run Maven there:
cd ~/3.3.indigo/build/jmx
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | tee build.jmx.log.txt
+-- OR, if you prefer to use the "bootstrap profiles": --+
cd ~/3.3.indigo/build
mvn3 clean install -U -B -fae -e -P local.site,jmx-bootstrap -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | teebuild.jmx.log.txt
++
#
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.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
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.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
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.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
On the *JRE* tab, make sure you're using a 6.0 JDK.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
On the *Refresh* tab, define which workspace resources you want to refresh when the build's done.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
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.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
Click *Run* to run the build.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-17-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-17...
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. 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..*
*
*
source.. = src/
output.. = bin/
h2.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16604]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 8 months
[PicketBox Development] - JBoss AS7 : Security Domain Model
by Anil Saldhana
Anil Saldhana [http://community.jboss.org/people/anil.saldhana] created the document:
"JBoss AS7 : Security Domain Model"
To view the document, visit: http://community.jboss.org/docs/DOC-16811
--------------------------------------------------------------
+*ARTICLE In PROGRESS*+
JBoss AS 7.0 and beyond come with a new domain model where the configuration for the entire Application Server is centralized. This article will highlight the domain model settings for Security.
h2.
h2. Locations of the domain model
h3.
h3. Standalone Configuration
standalone/configuration/standalone.xml
Example of the security domain model
<subsystem xmlns="urn:jboss:domain:security:1.0">
<security-domains>
<security-domain name="other">
<authentication>
<login-module code="UsersRoles" flag="required" />
</authentication>
</security-domain>
</security-domains>
<security-properties>
<property name="a" value="b" />
<property name="c" value="d" />
</security-properties>
</subsystem>
In the above example, we are defining a block for Security Domains. In this case, we define a security domain "other". Underneath, we define the login module (UsersRolesLoginModule). Remember, we do not need to specify the fully qualified name of the login module.
We also define a block for properties that are set on +*java.security.Security*+.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16811]
Create a new document in PicketBox Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS7 Deployment Terms
by Stan Silvert
Stan Silvert [http://community.jboss.org/people/ssilvert] commented on the document
"AS7 Deployment Terms"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16804#comment-6419
--------------------------------------------------
> Jim Crossley wrote:
>
>
>
> +1 for "add/upload/provide/stage/supply". And, for convenience, deploy implies an add and remove implies an undeploy.
>
Actually, add doesn't imply deploy. It will only deploy if it is also enabled. In the case of a domain, it must be enabled and assigned to a server group with at least one running host.
This is why I want to stay away from "deploy" as a user command. Deploy is what happens when all the right conditions are met.
I do agree that remove definitely implies undeploy. The undeploy has to happen first. But like "deploy", "undeploy" should not be a user command. It is just a thing that happens under certain conditions.
--------------------------------------------------
14 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS7 Deployment Terms
by Stan Silvert
Stan Silvert [http://community.jboss.org/people/ssilvert] commented on the document
"AS7 Deployment Terms"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16804#comment-6414
--------------------------------------------------
> Bob McWhirter wrote:
>
>
>
> Also, dunno if I'd say that the currently CLI "deploy" should be "upload", since it seems to both upload AND deploy. I did spent a few moments looking for an add-content or other verb to able to populate the content repo w/o triggering a deployment.
>
That's something I've been talking about with Alexey. The CLI commands are not set in stone yet. I personally think that in a domain it would be very useful to upload without assigning to a server group. I'm changing the console to work that way. You shouldn't be forced to choose a server group right away because you might not be sure which server group(s) you want and/or the one you want might not be fully configured.
My preference would be for the CLI to have an "upload" command with arguments that allow you to assign and enable in one shot if that's what you want. But don't force the user to do the assignment.
On standalone, you should be able to upload without enable. Just because you upload the bits doesn't mean you are ready for the app to go live.
--------------------------------------------------
14 years, 8 months
