This project is read-only.

Coming from the Java world

Nov 1, 2011 at 10:32 PM

As java guy working with open source software and communities I must confess that I have a lot learn on the Microsoft side of the world. I think Visual Studio 2010 is a great IDE, IIS is a strong application server and, SQL Server is value for money. But there are some things I miss when developing and collaborating:

- NuGet is package manager is great to fix your dependencies but I like to build from source code to learn and debug when nessecary. I really miss Maven in that matter, is there an approach or tool that can be used?

- The documentation file is very good and has kick-started our development. But I sucks from a collaboration point of view. I'm used to wiki's (Atlassian's Confluence is my favourite) which makes it easy for everyone to contribute, comment, discuss en enhance articles. I also want to add a proper Issue tracking system (read Jira) to this point.

- Another VCS (Mercurial): can't the world stick to two proven ones? Subversion and Git preferrably?

Probably my points will fade over time when I get more experience but I just couldn't let myselve share these point. And perhaps more will be added to this list ;-)


PS Thanks for the work you've already put in the framework and open sourcing it.

Nov 2, 2011 at 10:01 AM

FYI, Naked Objects has also come from a Java background.  The original Naked Objects framework was written in Java, and we eventually passed over the head rights to the ASF, where it now exists as part of the Apache Isis framework. In 2007 we started a complete re-write of the framework into .NET, taking full advantage of that platform  -  since then Stef Cascarini and I have worked almost exclusively on the .NET platform.

"I really miss Maven".  I can still remember all the swearing at the office from the days of when we moved the Java framework onto Maven!  Yes, it is a very powerful capability  but can be a pig to work with initially.  NuGet seems targetted more at convenience than at full industrial strength.  You have presumably worked out that you can, nonetheless, debug into the source code from a NuGet install, by configuring a symbol server?

"Another VCS (Mercurial): can't the world stick to two proven ones?".  Not really in the spirit of open source, that comment!  People develop new open source tools because they see an advantage.  Naked Objects (Java) was initially developed on CVS, then we moved onto Subversion which was a big improvement, and Naked Objects for .NET was also developed on Subversion.  We were forced to migrate onto Mercurial just recently in order to go open source and  host on CodePlex (we certainly didn't want to use TFS the other option!). That said, Mercurial is a very nice product.  Joel Sporsky makes a very good case for  (c.f. Subversion) here:

"The documentation file is very good and has kick-started our development. But I sucks from a collaboration point of view. I'm used to wiki's".  Yes, the wiki approach facilitates collaboration, but I've yet to see one that results in the quality of documentation that we've produced for Naked Objects.  To me, collaborative discussion and quality documentation are two very different objectives. As you know, we've only just open sourced Naked Objects so, to date, 100% of the development has been in-house.   When we start to get some serious interest from other developers wanting to help develop the framework then we'll certainly be adding more collaborative tools and processes  -  for now the emphasis has all been on making it as easy as possible for people to use the framework, rather than to develop it.

In the shorter term, we do intend to make the documentation more accessible to developers.  FYI, it is actually all written as XML to the DocBook standard (much more common in the Java world than .NET, I believe)  -  the .chm file (which I have never really been happy with) is generated from that.  We do intend to move all the XML source of the documentation into CodePlex soon  -  the only reason we haven't done it yet it that we have a bit of work to do to extracate it from some other documentation projects that we have that share some of the source.  It should then be easier for people (who can work with DocBook)  to submit documentation patches, make their own extracts or customised manuals, and transform into other formats e.g. .html, .pdf, Word. 

Nov 2, 2011 at 11:44 PM

Forgive my biased comments, we have to learn a lot of stuff to bridge the gap between you guys. But we're very happy wit the results we got with Naked Object for .NET so we'l probably stick around! Your comment about Maven is very true, it took me longer to figure it out than delivering a NO.NET prototype. Thanks for pointing us out to Symbol Server too. And after spending a day with Mercurial and reading some stuff I'm giving up resistance. Especially the article where it's comparing McGuyver to James Bond was fun. You can figure out who James Bond is.

Your goal to make an easy to use framework with high quality documentation has succeeded. But even though attracting developers on the project is not your primary target it would benefit if the entry level for participation is low. I've learnt from other projects that I'm involved in that you have to be strict on the direction of the core framework but I can imaging interesting side projects will occur. Giving users a home to collaborate and share is a great asset. There are some plugins for Confluence to produce quality output direclty from the wiki in PDF. There's even a docbook importer/exporter. If you send me the docbook file I gan give it a try on our own Confluence instance and show you the results. I'm willing to help you set up a server if you'de decide to want one. Confluence is free for OS projects and (I knwo you're reading this Dan) Apache projects can request their own instance. Last note: I'm not related to Atlassian ;-)


Nov 4, 2011 at 10:47 AM


As you say, we will probably keep very tight control over the very core of the framework, but we are very keen to encourage more innovation by other people outside that core e.g. new Viewers, new Persistors, alternative programming models and so on.  I will make it a priority to get the XML Docbook documentation into the repository so you can experiment with that.  Hopefully next week. Thanks for your interest, and I look forward to you getting more involved.

Meantime, I have given you editor permission on the project so that you can start some wiki pages here.  Depending on how that goes we can review the need for other capabilities.


Nov 7, 2011 at 2:16 PM


Please note that the XML (DocBook) source for the Developer Manual, has now been added into the repository, within the Documentation folder.


Nov 7, 2011 at 2:26 PM


Thanks for adding me to the editor group. I wil make some time one of the next days to import it into our wiki and produce the output. Will update you on the results.


Nov 14, 2011 at 10:01 PM

I tried to import the documentation into our Confluence instance. We had to upgrade to a newer version because of compatibility issues with the Docbook import plugin but that went smooth. However, importing failed because the importer needs a docbook file with the <book> element as a starting point and as far as I can see that doesn't exist. I'm not a docbook expert so I have to experiment more to make it work. Keep you posted on my progress.

Here's a link to the documentation: