New topics: Your Pet, IOU, Baby IQ, The Poisons, Birther II, Games, Future Power

Trying out the documentation theme?

Skip to end of metadata
Go to start of metadata

Questions For Confluence Developers

  • When does deeper programming than a plugin have to be done? (i.e. What are the ramifications of the no ability of an event listener to veto an event, for example a quota violation to block additional page creation, or a URL rewriter.)
    • Is it better to do deep programming directly, or should work in core mainly be limited to creating new plugin types?
    • Could a new plugin type be added for quota events, and for complete url rewriting?
  • If I made changes deep in Confluence source code, how would I ship those changes to others who don't have source code, or aren't prepared to recompile the sources?
  • Is there a convention for adding db fields to Confluence db to avoid conflict with future revisions? Are upgrade scripts done in a way that is agnostic to the presence of extra db fields, or are the upgrade scripts likely to abort ("not our database format" type error)?
  • Precedent for Confluence accepting code from third parties to include within core of Confluence?
    • For example, I may need to work in the core of Confluence to develop the support for a quota plugin. How could I get this code accepted into Confluence so that Confluence installations could easily use my new plugins that depend on that support?
    • E.K. - says this could involve legal issues, and perhaps has not been done before.
Labels:
plugins plugins Delete
development development Delete
wiki wiki Delete
java java Delete
macros macros Delete
confluence confluence Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

2 Comments

comments.show.hide

  1. Apr 24, 2007

    jnolen

    1. Actually, we encourage folks to do their development entirely within the plugin architecture. Other sourcecode modifcations, while certianly possible, raise the risk that they will not be upgrade-safe.
    1.A. It depends on the particular problem at hand. Where possible, new plugin types would most likely be preferrable.
    1.B. It's hard to say without more investigation.
    2. Unfortunately, there is no good way. People without a source license cannot recompile the product, and you are not allow to share source-code with someone who does not already have a license to it. That's another reason we strongly encourage development to happen in the plugin realm.
    3. No – we encourage people not to manipulate the database directly, to ensure that future versions of Confluence will be able to upgrade the data as needed. For data storage, we suggest that you use a separate datasource, Bandana (XML serialization library) or Lucene, as appropriate.
    4. We will definitely consider patches that add functionality we want. Any legal issues would need to be worked out on a case by case basis.

    Hope this helps,
    Jonathan

    1. Apr 25, 2007

      Garnet Chaney

      Jonathan,
      OK, you confirmed a lot of things that I suspected.

      For (2) I was wondering if my changes could be shipped like Atlassian ships patches: A zip file with some jars in it that overwrite a few of the already existing jars. For example, the tangersol patch to the first version that had Massive support. So I wouldn't be giving source code to anyone else. The drawback is I'd have to merge my changes with every relevant source version, and have separate versions of my jar for each of those versions.

      The other thing I was wondering if you would say is that there is a way for my Java objects to override and extend your java objects, without my having to replace your objects. I don't know Java well enough to know if that is possible or just a pipe dream, or just a dim memory of how things were done back in the days of Virtual Method Tables and object oriented extensions to Turbo Assembler, and Pascal with Objects.

Add Comment