OC,
Many thanks for the explanation. For now, I’m sticking with Eclipse. I don’t earn a living from WO development, so I can live with any problems, should they arise. ;) Cheers, Flavio > On 28/03/2016, at 14:52, OC <[email protected]> wrote: > > Flavio, > > On 28. 3. 2016, at 16:08, Flavio Donadio <[email protected]> wrote: > >>> […] I am building my apps in Xcode […] >> >> Could you elaborate on this? Are you telling us you use XCode to do Java >> development? How well does it work? > > Short answer: I do (essentially, see below re Java), and it works much better > than Eclipse for me. > > Nevertheless, there are _very_ serious drawbacks; if Eclipse works reasonably > well for you, you probably won't want to switch to Xcode. I develop lots of > things for Mac OS X and for iOS, too; this is why I stick with Xcode, for I > prefer having the same source system and editor for all my projects. If you > don't, you would do better with another IDE, better suited to customizations > (AppCode is said to be pretty good, though I haven't tested it myself). > > First thing, I still use Xcode 5.1; I did not get to test newer ones yet, it > might work well, it might not. Note that I parted with pure Java long ago; > myself, I consider it a terrible language. Therefore, I use Groovy, which > allows me e.g., instead of this contraption > > === this is what Java forces us to write, business logic lost in heaps of > boilerplate === > NSArray validOfferItems() { > NSMutableArray ma=null; > if (auction!=null) { > NSArray all=auction.orderedPriceOffers(); > if (all!=null) { > ma=new NSMutableArray(); > for (Enumeration en=all.objectEnumerator();en.hasMoreElements();) { > DBPriceOffer po=(DBPriceOffer)en.nextElement(); > if (po.validOffer()) ma.addObject(po); > } > } > } > return ma; > } > === > > to write this code > > === this is what Groovy allows, all business logic, no boilerplate === > NSArray validOfferItems { > auction.orderedPriceOffers.findAll { it.validOffer } > } > === > > Besides, Groovy adds dynamic services which remind one of ObjC (e.g., I do > not need the ugly mess of _EOWhatever superclasses; my enterprise objects > install accessors based on the model automatically at runtime, just like it > was intended to work from the very beginning -- similar way it works today > with Core Data). > > Nevertheless, it is not easy to teach Xcode to work with Groovy sources > properly. There is essentially no syntax-based auto-completion (in Eclipse > there is one, but it never worked for me; whenever I tried, it simply shown > the rainbow disc for a couple of minutes and then auto-completed nothing > anyway). Xcode, at least, can reliably auto-complete strings used before in > the same source. I have added my own xctemplate for .wos, too; they can > easily be edited in Xcode's assistant editor, but -- unlike Eclipse -- they > will not open this way automatically, alas. > > For building, I use an “external build system” target with my own build > script. Again, if you use Eclipse/Java, you might get better; Eclipse/Groovy > was a disaster though: the incremental build 50 % of time simply did not > work, running some old classes along with some new ones, ick. My scripts work > 95 % of time, and I know precisely what causes the 5 % of problems (outdated > .class files not removed) and can dodge it. One of worst current problems > for me is no typechecking; this can be cured and I know how to make a > typechecking system essentialy same as ObjC's for Groovy (its native one is > seriously lacking), but so far, I did not found the time to do that. > > Similarly for testing I use my own run script. There's only one drawback, but > it's pretty serious one: no debugger (I've played with jdb, but did not > suceed to integrate it into Xcode). Again, if Eclipse debugger works all > right for you, you are _much_ better with it; for me (with Groovy) it never > worked reliably, so I lose nothing, am down to log-based-testing anyway. > > I don't mind sharing those scripts and tools > (http://www.ocs.cz/CD/ocswobuildxcode.zip), but be VERY wary with them! They > are hand-tuned to my own specific needs (e.g, they hard-code building a > shared code from a separate OCShared project; there's a half-baked > not-working support for the Groovy typechecking, and worse), and very > definitely they CANNOT be used as-are -- at best, you might start with them > and prepare your own build system based on the ideas. > > Whilst I do intend to make those scripts generic enough, alas, so far I had > no time for that :( > > All the best, > OC > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
