Re: Installation

Tor Norbye wrote:

>On Wed, 2003-06-18 at 09:47, Tim Lebedkov wrote:
>  
>
>>Hello Tor,
>>
>>I have some questions:
>>1.  There is a pmd-netbeans.nbm on http://sourceforge.net/projects/pmd. 
>>Shouldn't we
>>    define a dependency from tasklist-pmd to it?
>>    
>>
>
>What do you mean by define a dependency? Document it somewhere?
>tasklist-pmd's manifest already declares a dependency on it:
>
>OpenIDE-Module-Module-Dependencies: pmd > 0.70, ...
>
>  
>
>>2. What do you think about the integration of 
>>http://checkstyle.sourceforge.net/
>>    
>>
>
>That would be interesting. Last time I looked at it, there was a
>lot of overlap between pmd and checkstyle, and pmd seemed like
>a more active project.
>
>Are there rules implemented by checkstyle that are not in pmd?
>The only ones I noticed earlier were for things like indentation
>which I didn't find all that compelling.
>  
>
I readed on java.net a blog about checkstyle 3.1 and they say that at a 
given moment they though to stop checkstyle and continue with PMD.
But they reject that idea and as argument was the fact that checkstyle 
3.1 has a better response time than PMD. Another argument is that they 
provide
somethings to help external people to add their own role, without having 
to modify the checkstyle code.
And that can be very interresting for us/you. It can permits to each one 
to create own rules.
And why not encourage the community by share their rules and integrate 
them in a next release of tasklist module.

Do you think it will cost you much time to create a bridge for the 
checkstyle module ?

It permits then to the user to choose his prefered module between both.
So you are not forcing others to have to follow your choice (pmd) but 
you permits others to choose between the both product.

The only problem I see is that the netbeans module for checkstyle has 
not been updated for checkstyle 3.1 But I have no idea if you need the 
netbeans module of checkstyle ot checkstyle itself.

>>3. Wouldn't it be better to place nbm files instead of jar files on
>>    http://tasklist.netbeans.org/servlets/ProjectDownloadList?
>>    
>>
>
>The problem with that is that a nbm can only contain a single
>module! (Yes, I was very surprised to discover that.)
>
Is a issue introduced to permit to have one nbm containing more than one 
module ?

>So the download page would have 10 nbm files for each version
>(3.4, 3.5 stable, 3.5 dev, 4.0 dev)
>
>>4. Why is jtidy not a part of tasklist download?
>>    
>>
>It's a bug I guess. I just need to go update the tarballs. Do
>you know which of the downloads are not including it?
>
The update center for 3.5 is not offering the jtidy.

>>5. Could you please explain the way how you build files for TaskList 
>>Download page
>>    and for the Update Server (How often do you do this, which branches 
>>do you use, ...)
>>
>
>It's very haphazard.  For the Update Server, only the 3.5 stable
>set is contributed. I build it by hand whenever a critical bug
>has been fixed, and send it to Robert Novak.
>
>The 4.0 dev modules (the alpha center) is built automatically
>from the tasklist cluster defined in nbbuild/build.properties.
>
>For the download page, I update the modules occasionally (haven't
>lately, since I've been really busy). I have a tree (which is
>exactly the tree you get when you unzip one of the download
>pages; I update my build, copy the modules into the tree, and
>zip it up, then upload it.
>
>  
>
>>6. Is it possible to make the tasklist-compiler available through Alpha 
>>Update Server and what
>>    should be done to move it to the Beta/Final?
>>    
>>
>
>Yes, to get it through alpha update you need to get it added
>to nbbuild/build.properties's tasklist cluster.
>
>Before you go to final I really think you should negotiate an
>API change in 4.0 so that you can depend on official APIs instead
>of reimplementing/code-duplicating the compiler engine.
>
>  
>
>>7. What about making dev35 branch content available through the Beta 
>>Update Server?
>>    
>>
>
>That's a good idea - do you think it's possible for the update center
>to contain two different versions of the same module? And they
>would have to be labelled differently in some way so people knew
>why they would download version 1.2 instead of 1.0.5 for example.
>
I suppose it's feasable because it's what is has been done for the Ant 
Documentation. At a certain moment, it was possible to install 
documentation for Ant 1.4.1 or 1.5.1.
And you can also have one version available on the stable update center, 
another one on the beta update center and a third one on the alpha 
update center.

>-- Tor
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
>
>
>  
>