Yet another post on Windchill, GIT and customization management

Question

I've been following the posts of the year's on Windchill development and how folks are managing their customizations and their steps for deployment. Being historically untrained and old school, I had opted for simplicity but these "bad habits" might be preventing me for moving forward. I have completed as restructuring of my Git repo and removed Eclipse compiled class files from its management. Just for context, I develop offline on my laptop pushing changes up to Bitbucket then down to the local repos on Dev, Test or Prod as needed. Feel free to throw stones at any point. I can duck, bob and weave. 
Now, I have been exploring  methods to automate or script build and deploy to the Windchill directory. Ant seems to be what I've chosen to work with for the moment. Historically, I've made use of the wtSafeArea and wtCustom area to stage updates and the "installSiteChanges" to push into codebase.  I also started looking at tools.xml scripts and it seems that these were designed with compilation straight into codebase, even options to delete all .class files (dangerous?). 
Since installSiteChanges pushes files into Windchill home in the relative folders, I've leveraged that siteMod as as the staging area which contains custom properties files, classes, JSP, resource bundles, scripts, xml config files and a static .xconf files. Its a bit of a hop here to hop there but just giving a sense of where I am currently. 
Build process in my head would work something like this:

Update local repo
Compile classes (incremental if possible, only what's changed)
move class and non-class other files to wtSafeArea
installSiteChanges
Optionally update resource bundles if necessary (if changed)

A few questions and observations.

As mentioned, tools.xml assumes you are developing inside of Windchill install. Is this normal? Do you make use of this ant script or roll your own?
Tools.xml seems to compile all, not incremental. So if source has not changed, class files are still re-compiled. Correct observation?
I've been able to get "class" target to accept my repo as source and even change the build output folder. I would like to stage it since I would not proceed if there was a build failure. Good idea?

I will be heading to New Orleans so would chat more in person about this with folks. 
Current repo structure:

codebase has custom code, java source, JSP, properties files etc.
conf contains security labels modified file
src folder is my custom resource bundles
wtCustom is my modified resource bundles (additions and mods from PTC default)
other files would be stuff that appears at Windchill root.

avillanueva · Answer

Ok, some progress that I wanted to document more clearly than PTC documentation. Since my repo exists apart from the Windchill folder, I am taking an approach of moving in changed files and doing full compile of .java files or only differences. For the move, I found rsync to be helpful:

rsync -av --no-times --checksum --exclude '*.java' <repo folder> <staging folder>

My repo mirrors the Windchill structure so these just need to move to the relative folder location. Git timestamps cannot be relied on since it gets impacted by when you did a pull. I opted to compare checksums and sync if different.

For .java compilation, I did many tests with the tools.xml ant script which is included in the Windchill bin folder. The "class" target is what does the recompilation. Depending on options, it can recompile resource bundles as well though I think it does all or nothing. I also was able to provide options to point it to my repo and direct output to a folder of my choosing.

To do a full recompile, I used this command:

ant -f <wt_home>/bin/tools.xml class -Dclass.force=false -Dclass.source=<repo folder>/codebase -Dclass.includes=** -Dbuildroot=<staging folder>

The "class.includes=**" should direct to recurse to all subfolders but you can be specific to call out a certain package if you want.

The "class.force=false" confused me since in the help notes and docs, they show this being set to "true". I found that the mere presence of this attribute was the trigger and the value did not matter. So, removing this caused an incremental build, like this:

ant -f <wt_home>/bin/tools.xml class -Dclass.source=<repo folder>/codebase -Dclass.includes=** -Dbuildroot=<staging folder>

So getting close to being able to script whole process. The tools.xml seems to have a lot of good stuff in it but it seems like it was built with the assumption you were developing inside of the Windchill folder directly, doing database modeling and modifications. Am I correct is stating there is a possibility to run an accidental clean and delete all PTC class files the the codebase? That would be terrible!

 <target name="class.clean" depends="class.init,class.check"
 if="class.force">
 <delete quiet="true">
 <fileset dir="${class.output}" includes="${class.includes}">
 <filename name="**/*.class"/>
 </fileset>
 </delete>
 </target>

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded