vaadin 6.3 ant build target

The vaadin source web page still has out-dated build instructions.
I tried:

vaadin/6.3/build>$ ant package-linux                                                                                                         
Buildfile: build.xml                                                                                                        

BUILD FAILED
Target "package-linux" does not exist in the project "Vaadin". 

Total time: 0 seconds

Looking at the following I realised that things have changed a bit:

$ ant -p
Buildfile: build.xml

Main targets:

 build              Build package required files, without packing them.
 compile-widgetset  Compiles the widgetset given as the first parameter
 package-all        Build public packages.                             
 package-jar        Create vaadin-x.y.z.jar file.                      
 package-jar-quick  Create vaadin-x.y.z.jar file quick.                
 test-build         used for testing build.xml                         
 test-package       used for testing build.xml                         
Default target: package-all                                            

So I tried the following starting building like crazy:

$ ant package-all                                                      
Buildfile: build.xml
...

But it got stuck on:

manual-checkout:
     [echo] Checking out manual from repository http://dev.vaadin.com/svn/doc/trunk
    [mkdir] Created dir: /stf/prj/fs/vaadin/6.3/build/checkout  

Finally I did:

$ ant package-jar

and the jar finally got built!

BUILD SUCCESSFUL
Total time: 10 minutes 49 seconds

Will try out package-jar-quick next...

This made me shout out complaints about ant (ask my co-workers) and fall in love with maven all over again.

How to make Archiva less paranoid about passwords

After just 3 login attempts a user's account is locked by Archiva, which is quite bad if a whole team and continuous integration servers uses the same account.

I think you should just add an exponentially growing timeout to when the user can log in (maybe per source ip) or at least make it configurable from the frontend. But anyways, for our internal/firewalled archiva this sort of thing is a bit of over kill.

I finally found out how to convince it to be more lenient.
Just add the following content:

security.policy.password.expiration.days=999999
security.policy.password.expiration.enabled=false
security.policy.allowed.login.attempt=300
security.policy.password.previous.count=1
security.policy.password.rule.reuse.enabled=false

to the equivalent file to your system:

glassfish_2.1/domains/archiva/lib/classes/org/apache/maven/archiva/security.properties

http://osdir.com/ml/users-archiva-apache/2009-02/msg00031.html