Emil Ivov wrote:
Incidentally, I was wondering how we should proceed with the Netbeans and Eclipse tutorials on sip-communicator.org. Time has shown that maintaining tutorials on how to create projects from scratch are often outdated and it takes a long time (if at all) to update them.
The project was so active at the end of last year that I decided to keep away and wait for it to stabilise. By the time I returned to building the project, I'd forgotten quite a lot of practical things such as how to run an individual test suite and how to setup the account.properties file.
I used the online documentation and came to the conclusion that most of the facts were present and still correct, but the headings and links didn't make it easy for me to find out what I wanted.
I was therefore thinking that we should probably only have tutorials that are based on the meta data in sip-communicator/ide/idename and only explain (possibly with screenshots) how to make the corresponding ide work with the project files available in that directory and skip the whole part about retrieving the project from CVS configuring ant targets, et cetera.
Well, I'm not convinced you are correct. In my experience, I've always hit snags when trying to use cvs (or subversion) from the command line and then trying to create a working project under an IDE. Both Eclipse and Netbeans have integrated source control features that don't play well unless you've created the sandbox with an IDE checkout operation.
Even using the IDE to do the original checkout is error-prone and difficult, but is more likely to succeed than trying to turn a standalone checkout into a working project. In my experience with both these ide's, it isn't too hard to get the project to build, but all the pain starts when you want to debug the code and/or commit a change.
I HATE SCREEN SCRAPER TUTORIALS! They always assume there is only one case - the one in the screen print. They are usually full of "click this" and "choose that" meaningless comments. No help at all if anything has changed recently or your particular environment is different.
I much prefer a descriptive approach that explains what you are supposed to be trying to do and how to decide what to choose... it is more flexible and resistant to changing situations. However, I realise that newcomers to a project who don't have English as their first language are likely to have more trouble than by simplistically following a pictorial recipe that fortuitously works first time.
1. We need a very basic tutorial for someone who just wants to get the latest source and build/test/run the project. They might as well use simple command-line tools - cvs and ant. We already have most of that documented. (I don't think anyone should seriously try debugging without an IDE).
2. We also need tutorials for the most popular IDE's (presumably just eclipse and netbeans these days). Doing the initial checkout and getting the project to build and debug needs MORE than just the metadata in /ide/ide_name/, so that is why we need the words to explain what you should be trying to do and why it matters.
To summarise, we need to be clear who constitutes our target audience. I don't think it is the regular project developers... they already have their IDE's setup the way they want and seldom need to start from scratch.
The audience has to be someone who's just taken interest in the project and has found the standard distribution doesn't work in the way he or she hoped. They need to get and build the latest source (at minimum) and probably want to debug, fix and even develop additional logic. I don't think we want to lose these people by letting them get frustrated by difficulties setting up their preferred IDE.
Lastly, a warning to any Eclipse users... I noticed that the sample .classpath file for eclipse is out of date. It still uses oscar.jar and joscar-0.9.4-cvs-bin.jar, although these jars are no longer present in (sandbox)/lib. I decided to leave the change to someone who uses eclipse regularly and can test the change properly.
No takers yet... Emil, could you ask someone who uses eclipse to make the update?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com