Date: Tue, 19 Mar 2024 06:18:21 +0000 (UTC) Message-ID: <1732274632.54519.1710829101226@cwiki-he-fi.apache.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_54518_753353911.1710829101226" ------=_Part_54518_753353911.1710829101226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Setting up an Eclipse project to build CXF is pr= etty easy. There are three parts to it:
We use several Eclipse plugins to make building CXF a bit easier
While ther= e exist Maven plug-ins for Eclipse, team developer experience has found usi= ng them with CXF problematic at best. We recommend importing the CXF sourc= e code as Eclipse projects as shown below and/or using Maven externally (i.= e., from a command-line window) as discussed on the CXF build page.
Go to
Help -> Eclipse Marketplace
Some of us are starting to experiment with using M2Eclipse. See this page for instructions.<= /p>
First check out CXF from Subversion.
To create a workspace, just run from the root directory of the CXF proje= ct (see the build page for more detailed information):
> mvn -Pfastinstall > mvn -Psetup.eclipse =20
OR
> mvn install -Pfastinstall -Psetup.eclipse
This creates a new workspace in "../workspace" for use with CXF.
If you don't want the workspace there, you can run:
"mvn -Psetup.eclipse -Declipse.workspace.dir=3Dpath/to/workspace"
If you don't want the eclipse projects' output directory to be ./target = directory (by default) but ./eclipse-classes, you can run:
"mvn -Psetup.eclipse -Pset.eclipse.output"
What this does is create a workspace and imports our checkstyle rules, t= he maven 2 repository, code format rules, import order rules, etc... into t= hat workspace. It also goes through each sub-project and creates the .proje= ct and .classpath files. This process will take some time. It will down loa= d source jars for most of the dependencies and hook them up in the .classpa= th file as well. Thus, while coding/debugging, you can trace right into the= dependent libraries. While running, you WILL see= a bunch of warnings and such flying by. There are a bunch of jars on ibibl= io that do NOT have source jars with them. Thus, you will see warning about= those. Those warnings are safely ignorable. As long as it says "BUILD SUCC= ESSFUL" at the end, you should be OK.
Go To:
File -> Import....
That's all there is to it. From eclipse, all the unit tests and system t= ests should be runnable. However, to build kits/jars and stuff, you still n= eed to use the command line "mvn" stuff.
With the latest version (2.5) of the maven-eclipse-plugin, when you run = "mvn eclipse:eclipse" on a project, if it knows where your workspace is, it= will see what projects are already defined and wire them in to the new pro= ject instead of pointing at the jars in your ~/.m2/repository dir. Thus, de= bugging is a lot easier. There are two ways to get it to know where your wo= rkspace is:
Update your Maven ~/.m2/settings.xml to have a active profile that a= lways sets these variables. Thus, whenever the eclipse plugin looks for it,= it know where the workspace is. In settings.xml, do:
... <activeProfiles> <activeProfile>extra</activeProfile> </activeProfiles> <profiles> <profile> <id>extra</id> <properties> <eclipse.workspace>/home/dkulp/working/workspace</= eclipse.workspace> <eclipse.workspace.dir>/home/dkulp/working/workspace&= lt;/eclipse.workspace.dir> </properties> </profile> </profiles> ...
By doing that, you can pretty much run eclipse:eclipse (or -Psetup= .eclipse for cxf projects) at any point and it will always wire the new pro= ject to depend on the existing projects.
If you are wondering about how all this manages to make Eclipse, Maven, =
Checkstyle, and PMD
cooperate, see Connecting Maven, Eclipse, Checkstyle, and PMD=
.