VFSJFileChooser and XPontus are unmaintained

  Both VFSJFileChooser and XPontus XML Editor are currently "very inactive", I just needed to make it "very official"!

  Surprisingly, as soon as I stopped working on those projects, I started getting tons of emails related to features requests, bugs or general questions.

 It was a nice run...

 While I may still work on Open Source projects, they will always be small to medium. Nowadays, I focus pretty much all my energy on my Consulting company, Rimero Solutions.

 Below is the short story of XPontus and VFSJFilechooser.

XPontus
  XPontus is probably my most successful project in terms of downloads and interest. Sadly the code was written very late at night without "much love" from an API perspective.
   Beer was often around to ease the pain, that's the poor man's truth! I was awake and coding almost all the time...

Audience and expectations
  The first release introduced a basic text editor with syntax highlighting, as well as few features for validating and transforming XML. The program was fast and simple.
  I started getting feedback quickly as well as many requests about code completion and other missing features.

  Around the last release, I realized that editor was widely used. On Sourceforge there was about 30 000 downloads. I would estimate about the same number of combined downloads  from many other sites such as Freshmeat(now freecode it seems), Softpedia, etc.

  XPontus was then expected to reach quickly the same level of functionality than Altova XML Spy and others. One Open Source Developer against many dedicated Corporate developers...

Planning
  It took me a while to get comfortable with Sourceforge. Between research and related coding activities, I kinda rushed things.

  With too many users' requests, I felt like 24h wasn't enough, especially with a full-time on-site job.

  I was still learning some parts of Java Swing while writing the software and I never could perform a full cleanup. I just kept adding new features to please users at the expense of maintenance issues and additional bugs...

Failure to involve other developers
  Maven is often an issue among Java Developers. In real life, not that many people are comfortable with it, especially when it's a multi-project module.

  Because the API was a bit crappy and not very flexible, people got discouraged. I also had to answer tons of questions related to design and the various technologies that I was using.


Support, later on
 Initially, I generated all the installers manually, more control, but time consuming for testing on many platforms. Later on, ej-technologies gave me a free license of Install4j while I received a free copy of IntelliJ by JetBrains. Apama designed the new XPontus logo.


Last effort
  I attempted a rewrite in late 2009 using OSGI but I had the impression that it would become a bit like Eclipse Framework, but for Swing.

  The new rewrite was better designed, higher quality but it was too time consuming. I thought about making the project commercial after ensuring that I was using only Apache Licensed libraries.

  I wish that I had the same programming abilities few years ago...

VFSJFileChooser 

Audience
  I always expected VFSJFileChooser to draw interest but not that much. It was a product by a developer and for developers. The library was meant to provide a file dialog component with out-of-the-box remote browsing features. The project was not much advertised.

  VFSJFileChooser was originally supposed to complement XPontus XML Editor by providing a filesystem abstraction layer. The component was then extracted to make it generic.

General planning
  Because it was my second Open Source project, I came prepared.

  I was both organized and I knew my entire Open Source workflow well. My growing Swing experience also helped a lot.

  The scope of the project allowed to be more focused in general. I was more disciplined in terms of programming habits and time allocation.

Community involvement
  As it was a relatively small project that used Ant (and not the evil Maven), I received lots of valuable contributions very quickly.

  Some new members joined the team and were were able to get along very quickly. I didn't have to provide any explanations, nor did I answer more than few technical questions.

  We did two releases together, if I recall correctly, and I was really happy about it. I also didn't feel "alone" anymore.

  My life was getting very unbalanced and I was also exploring new career opportunities, so that was pretty much the end of  it.

Other alternatives

• otrosvfsbrowser is a File browser for Apache Commons VFS version 2. It was created as alternative to "VFS JFileChooser" and "Commons VFS - UI".
• vfsjfilechooser2 is a mavenized fork of the dormant vfsjfilechooser project on sf.net.

Drinking a huge cup of Java

I am working again on XPontus XML Editor. I believe that I'm ready to go for another round.

I am happy to see that there are so many people using the software. Since the intial XPontus release, there are about 10 000 official downloads from Sourceforge and probably 12 000 from other sites grabbing the files directly by HTTP. I didn't expect such a thing at all and it gives me energy to work again on the application.

Here are the main things that I learned since the XPontus inception:

• Provide a project roadmap even if it's ambiguous or you won't do anything listed :-)
  
• Don't use build tools such as Maven if you expect lots of people to contribute to a project, use a simpler but powerful tool such as Ant.
  
• If the component is has a public API, finish writing all the documentation before releasing: 20 bugs+good documentation is better than 5 bugs + no documentation, there will be bugs anyway.
• Advertise a project enough but not too much, people will expect the application to be at the best commercial level even if there are only 2 or 3 people working on the project.
  
• Don't assume you know what you're writing because you do code similar things often, read books or articles about the subject whenever you can.
  
• Don't try to make a big application without taking time to do it well, or as well as possible
  
• Try to think more like a user or a client of an API, rather than a programmer. The application is for users at the moment you distribute it.
  
• Make it look good and then make it work : you love what you see and then you love what's inside.
  
• Don't necessarily provide many features, few working features are better than a zillion of unstable features.

My goals are simple for the next release:

• The application will probably be lighter and faster (java reflection abuses, bad programming, race conditions, etc.)
  
• Partial rewrite and more use of design patterns(without trying to recognize them everywhere though! ).
• Fix the current bugs, usability/stability issues. No new features except maybe XPath2, XQuery. VFSJFileChooser will be introduced in the release as an optional plugin.
  
• New, simple but powerful API : If you explain the components relationships and the logic of the application, it should almost sounds like common sense, not magic or absurd.
  
• One should be able to reassemble, disassemble or extend XPontus without much effort. It looks difficult though, how can someone integrate very easily an application that uses a plugin system?? Last time I integrated parts of JEdit into an application I won't say it was too tough but it wasn't that simple even if I believe that JEdit modules are well written most of the time.