Pour évoluer, tu approfondiras toujours !

The Living Hell of GreenPepper Confluence plugin

I don’t give any clever solution for managing a confluence plugin in this post. I just express how difficult it is.

Dear all, for my second blog publication I will share with you the feeling that I have on refactoring the configuration pages of the GreenPepper plugin.

My first idea was to reskin the configuration pages of the Greenpepper plugin to be more integrated with Confluence 5. My target release was 4.0. I happened to learn and use AUI , the Atlassian UI framework which is very fine.

However how to test my modifications is another story.

Testing the CSS

I didn’t want to start a full confluence server in development mode just to do some CSS styling. I used some dirty tricks that involves:

  • taking a Skeleton 
    <html>
    <head>
       <meta http-equiv="refresh" content="5" >
        <title>Little Hack page to use to skin for confluence 5</title>
        <link rel="stylesheet" href="aui/css/aui.min.css" media="all">
        <script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
        <script src="aui/js/aui.min.js"></script>
    </head>
    <body>
        <form class="aui long-label">
<!-- Put your VM content here --> 
<!-- END -->
         </form>
    </body>
</html>
  • copying the content of a VM (Velocity template) page inside
  • skinning the page
  • put the result back into the VM. page

Ok, not a clever solution but the job gets done. Now time to correct the JavaScript.

JavaScript Correction

At the start, this work was supposed to be painless (in my little naive head) and fast. I was hugely mistaking .

Just a note on how I could adapt the plugin for confluence 5. I didn’t go so far as reviewing the entire plugin but the real pain was that the plugin was using Prototype.js and was aliasing it with $ and $$. On confluence 5, there is an embeddedJQuery using also the alias $. So I did some search/replace to change prototype.js aliases to something else.

Here I wanted to do the same, as before. No refactoring but some adaptation.

How to test my changes :

Naturally I went for a deployment of the plugin after my changes. After 3 or 4 deployments, I started looking for a way to test my changes faster.

Should I create a testing framework by mocking the backends ? … Too much of a hassle.

How do I manage the Velocity templating without being on Server ? 

… Hum, Let’s  see how Attlassian wants us to do that.

I followed the QuickStart, set my project up like for the HelloWorld project in the tutorial, launched the following command (using a JDK 6)

atlas-run -u 5.0.3 -v 5.0.3

Now see the superb ClassNotfound on a greenpepper-server module class.

Should I manage somehow the dependencies differently? I went to Managing Dependencies in the Doc … Still not working (triste)

On the bottom of the page, I found a link on managing multiple dependencies. OMG !! The headache.

…

Let’s go back to redeploying manually (triste)

…

Hum, Seeing the time I am spending on these changes, I started to wonder : What do I gain by doing them ?

  • They are cosmetic and not functional
  • They will certainly not work for another wiki integration
  • They are not fun.

So I dropped them with the creation of a new Issue on Github.

 

Laisser un commentaire