Val Vakar (CSDT Architect/Lead Engineer) was so kind to comment my "review" (let's call it a review - it is not) of CSDT. He raised a number of interesting point that I am going to discuss here.
I am going to compare actually CSDT with my own FatStart/ElementDeployer. Of course I am biased here since FatStart is my brainchild. However, I would be happy to drop it and use CSDT instead if it was addressing all my development concerns. Since it does not, yet, I am going to keep it and instead I ask Val to improve CSDT to the point I can drop FatStart.
I have been looking for a valid Fatwire development environment for ages, and I do not count CSE as a development environment! At the moment I am still using the development environment I built by myself.
Let's see what Val says:
Ciao Fatcoders!
Pleased to meet you, Val.
Just a couple of comments on your CSDT review:
1. You’re right that the fundamental difference between CSDT and Fatclipse is that CSDT works locally whereas Fatclipse works with a central server. This was a deliberate decision to bring FatWire development in line with normal J2EE practices where there’s distinct separation between development and deployment so that developers never deploy code directly from their system (even to test environments). For example, consider deploying a JSP to a remote WebLogic or Tomcat instance (and no folder sharing) – see what I mean? This approach is necessary to be able to maintain structure during concurrent development – more than one developer in a team, possibly editing the same JSP at the same time.
Well, however to test a JSP you still have to publish it back to the origin server, as far as I know.
Does CSDT provide protection when 2 developers upload the same JSP? Does CSDT allow for a merge of concurrent modifications? If it does not, we really need it.
My understanding is that if one developer check out a jsp, and another developer checkout the same jsp from the same server, when they publish their changes they can still overwrite their work each other.
Am I wrong here?
It would be very useful if I could publish my jsp on a separate server (a local jumpstart for example) for testing. But in current incarnation of CSDT, I cannot, since it is limited to one server.
To address those development issues, using my home grown Element Deployer I can assign a jumpstart to each developer. Each developer checkout the jsp from the repository (not from a centralized fatwire), merge his changes the codebase, using standard version control techniques, and then deploy all the code in his local jumpstart for testing.
It is easy. It simple. It works. And it does what everyone else in the J2EE world takes for granted: you work in your own local server for testing.
CSDT instead assumes you have only one, centralized server, from where you get and where you put your code. Not very standard J2ee in my view (although it is a standard Fatwire CS practice, unfortunately)
2. As to your question “(you wonder: why???)”, the answer is simple: CSDT is primarily an export/import tool; the Eclipse part is just a small part of it, and is not even required. Furthermore, CSDT is designed to be portable between IDE’s.
Fine, but here you are saying "CSDT is not really integrated in Eclipse, is is just hosted in it".
This means you cannot use your IDE version control tools, defeating the whole point of using the IDE. Furthermore the directory layout where CSDT stores his content is "opaque" and you have to do reverse engineering to discover where is it. Also file names are generated by CSDT.
I do not feel confident I can safely version controls files that I do not manage (it is the tool who decide where things go and their names, not me).
Using my basic "ElementDeployer" I just create files in Eclipse, that can be edited as normal JSP files, I can version control them with the IDE.
I really do not see the point of treating Fatwire JSP as special. They are not, and they can be edited as normal JSP (provided you tell eclipse where jar and tld are, and this is just a matter of creating a link).
In this matter, the old FatClipse was doing a better job, and I just using his technique: edit Fatwire JSP as normal JSP (just adding some jars and tlds to eclipse via a link).
3. Finally, regarding seeing changes immediately upon save – CSDT actually does that in your local environment (you can also use the embedded browser in eclipse refreshed using Ctrl+R, which some people find extremely convenient).
I think you are missing the point here: what I mean is that with my ElementDeployer I just save a jsp, and the result is immediately DEPLOYED on ContentServer (but I am assuming it is deployed in my local jump start, please note, not a shared CS)
Instead, deploying with CSDT is a long sequence of click. When you are working on fixing templates, you need to deploy the code very often . With CSDT I have to deploy the code, with ElementDeployer I have not. It is immediately deployed on the server.
I am talking of using my local jumpstart server, again. Of course, I agree that using ElementDeployer with a shared server is very dangerous.
Of course, this is within the J2EE development guidelines of separating development from deployment, so your target system will not be updated until you deploy. People use CI frameworks like Hudson for that sort of work, btw.
If you work in a small team it is understandable that you would like more direct methods of working with the test server. However, hopefully we can agree that after bringing in a few more developers things are bound to become messy.
First, I work with a team of 3, and we have to share code and merge our changes all the time. 3 or 30 do not change too much in this respect: you have to merge your changes with others. I do concurrent modifications.
For this reason, I am saying that you have to work on your local jump start, then commit your code to a code repository. You have to rebuild your QA server with code taken from the repository. Here you can use Jenkins for the task (ex-Hudson).
Anyway, I hope this didn’t sound like I was preaching or anything. I very much appreciate it when people bring up issues with CSDT. This is what helps us make things better in the future.
I am happy you are explaining your point of view. Honestly I am not sure I understood everything of CSDT and I may using it incorrectly.
I am writing here my opinions. I will happily publish your answers and correct my misunderstanding.
However...
Shameless plug! So far, I still prefer working with ElementDeployer and my FatStart.
Here is why.
You just need a single java class I call the ElementDeployer, and a bunch of html/javascript files. All of this is the FatStart project. Benefits:
Of course there are a number of assumptions.
The more important is that you Fatwire code is stored in a shared code repository (I use git) but each developer has his own local jump start.
Every developer need to build a complete copy of the environment, including content model and sample content in his jumpstart.
Well, you do this using FatStart, that is basically a Fatwire Project deployer.
So: you create your content model with FatStart, edit it with element deployer, distribute to others using a version control system. A QA system is built from sources and scripts, and from there everything is published to preproduction and/or production.
