Showing posts with label archiva. Show all posts
Showing posts with label archiva. Show all posts

Monday, 23 August 2010

Archiva gives the maven site plugin an invalid site_en.xml

I got the following nasty error since friday:

$ mvn -U -e -X clean site
...
[DEBUG] Reading site descriptor from /home/amanica/.m2/repository/za/co/my_company/super-pom/1.0.3/super-pom-1.0.3-site_en.xml
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] SiteToolException: Error parsing site descriptor

Expected root element 'project' but found 'html' (position: START_TAG seen ... Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\r\n<html>... @8:7)
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException: Error parsing site descriptor
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException: Error parsing site descriptor
at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:232)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:137)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:120)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.doxia.tools.SiteToolException: Error parsing site descriptor
at org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(DefaultSiteTool.java:1298)
at org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1252)
at org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1260)
at org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:511)
at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:225)
... 21 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Expected root element 'project' but found 'html' (position: START_TAG seen ... Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\r\n<html>... @8:7)
at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Reader.parseDecorationModel(DecorationXpp3Reader.java:619)
at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Reader.read(DecorationXpp3Reader.java:1387)
at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Reader.read(DecorationXpp3Reader.java:1401)
at org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(DefaultSiteTool.java:1294)

It turns out that maven looks for a site_en.xml for my parent project on archiva and archiva seems to generate a return file which is actually an error message.
The maven site plugin then tries to parse it and fails horribly :(
I worked around this by just adding the following content to src/site/site_en.xml in my parent project and everything was well!

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/DECORATION/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0 http://maven.apache.org/xsd/decoration-1.0.0.xsd">
<body>
</body>
</project>


I got really frustrated by this cryptic error message. I wanted to bash my head against the table and throw my laptop against the wall. Instead I cried out to God and not long after that I figured it out. Some would say thats just coincidence, I say: "Thank God", "Praise God" and "Why didn't I ask You sooner?".

Tuesday, 2 March 2010

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

Friday, 1 August 2008

maven repository manager

After struggling for a couple of days, I finally managed to set up a local maven repository behind a proxy.
  • I first tried nexus, but it's configuration is very buggy and despite the fact that it don't work for me, it keeps on forgetting my settings if I open on it again.
  • Then I tried artifactory, ant it too looked promising, but for some reason I could not get it to download stuff through a proxy either. To be fair after I figured out that my real problem as that my maven clean plugin was broken, I managed to get artifactory working through a proxy (but I think I like archiva the most at the moment).
  • Then I tried apache archiva, which looked even more promising since it actually had the concept of a network proxy on its configuration screen. After a lot of googling, I found out that its a known (and fixed but un-released) bug in archiva 1.1. (http://jira.codehaus.org/browse/MRM-884). So I installed version 1.0.2 and my downloads began to work!!
The only problem was that as part of testing if this works, I deleted the org directory in my maven repository (as described in the nexus section of the maven difinitve guide).
This caused my `mvn clean` to stop working:
"org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not exist or no valid version could be found"
After a bit of googling I found out that deleting my repository (~/.m2/repository) fixes this problem!
(http://www.mail-archive.com/users@maven.apache.org/msg68288.html)

A last note is that the different repository mangers are surprisingly similar as to how they work and configured. It must be something to with where they all come from.