jboss common maven build

[dimitris]

I need some help here. I have a checkout of jboss common:

build
common-core
common-logging-jdk
common-logging-log4j
common-logging-spi

Made some changes to common-logging-log4j, including the upgrade of log4j from 1.2.8 to 1.2.14.

Going back to the build directory, I'm getting:

X:\cvs\jboss-public\common\build>mvn install
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/jboss/jboss-common/2.0.4-beta/jboss-c
ommon-2.0.4-beta.pom
[WARNING] Unable to get resource from repository central (http://repo1.maven.org
/maven2)
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

GroupId: jboss
ArtifactId: jboss-common
Version: 2.0.4-beta

Reason: Unable to download the artifact from any repository

jboss:jboss-common:pom:2.0.4-beta

from the specified remote repositories:
central (http://repo1.maven.org/maven2)


[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: jboss:jbos
s-common for project: null:jboss-common-core:jar:2.0.4-beta
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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.project.ProjectBuildingException: Cannot find parent
: jboss:jboss-common for project: null:jboss-common-core:jar:2.0.4-beta
at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
efaultMavenProjectBuilder.java:1161)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def
aultMavenProjectBuilder.java:674)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi
leInternal(DefaultMavenProjectBuilder.java:416)
at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave
nProjectBuilder.java:192)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM 'jboss:jboss-c
ommon' not found in repository: Unable to download the artifact from any reposit
ory

jboss:jboss-common:pom:2.0.4-beta

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo
sitory(DefaultMavenProjectBuilder.java:513)
at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
efaultMavenProjectBuilder.java:1157)
... 18 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
to download the artifact from any repository

jboss:jboss-common:pom:2.0.4-beta

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:136)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:63)
at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo
sitory(DefaultMavenProjectBuilder.java:467)
... 19 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl
oad the artifact from any repository
at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def
aultWagonManager.java:260)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:124)
... 21 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Mar 29 14:07:51 EEST 2007
[INFO] Final Memory: 1M/2M
[INFO] ------------------------------------------------------------------------

[adrian.brock]

That's because the parent and child poms don't match on the version.

The child has
http://anonsvn.jboss.org/repos/common/common-core/trunk/pom.xml

<parent>
 <groupId>jboss</groupId>
 <artifactId>jboss-common</artifactId>
 <version>2.0.4-beta</version>
 <relativePath>../build/pom.xml</relativePath>
 </parent>

the parent has
https://svn.jboss.org/repos/common/build/trunk/pom.xml

<version>2.0.4-SNAPSHOT</version>
<artifactId>jboss-common</artifactId>

[dimitris]

Thanks. After switching locally to 2.0.4-SNAPSHOT, I still get errors, it goes to http://repo1.maven.org/maven2 rather than repository.jboss.com/maven2, but even then, I don't see us having there any SNAPSHOT version stored.

I'd expect the build to work out of the box? (or it's just broken)

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

GroupId: jboss
ArtifactId: jboss-common
Version: 2.0.4-SNAPSHOT

Reason: Unable to download the artifact from any repository

jboss:jboss-common:pom:2.0.4-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

[adrian.brock]

I've fixed the pom to get past this problem.

The problem I'm seeing is this:

[INFO] [retro] Compiling classes for jdk14
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Parameter 'directory' is not a directory
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalArgumentException: Parameter 'directory' is not a directory
 at org.apache.commons.io.FileUtils.listFiles(FileUtils.java:207)
 at org.apache.commons.io.FileUtils.listFiles(FileUtils.java:292)
 at org.jboss.maven.plugins.retro.RetroMojo.createJarEntries(RetroMojo.java:210)
 at org.jboss.maven.plugins.retro.RetroMojo.execute(RetroMojo.java:200)
 at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
 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:585)
 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)

[adrian.brock]

And if I comment out the retro build, I then see this error

[INFO] ----------------------------------------------------------------------------
[INFO] Building JBoss Logging Log4j
[INFO] task-segment: [package]
[INFO] ----------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: http://repository.jboss.com/maven2//apache-log4j/log4j/1.2.14/log4j-1.2.14.pom
[WARNING] Unable to get resource from repository jboss (http://repository.jboss.com/maven2/)
Downloading: http://repo1.maven.org/maven2/apache-log4j/log4j/1.2.14/log4j-1.2.14.pom
[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)
Downloading: http://repository.jboss.com/maven2//jboss/jboss-logging-spi/2.0.3.GA/jboss-logging-spi-2.0.3.GA.jar
7K downloaded
Downloading: http://repository.jboss.com/maven2//apache-log4j/log4j/1.2.14/log4j-1.2.14.jar
[WARNING] Unable to get resource from repository jboss (http://repository.jboss.com/maven2/)
Downloading: http://repo1.maven.org/maven2/apache-log4j/log4j/1.2.14/log4j-1.2.14.jar
[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) apache-log4j:log4j:jar:1.2.14

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=apache-log4j -DartifactId=log4j \
 -Dversion=1.2.14 -Dpackaging=jar -Dfile=/path/to/file

 Path to dependency:
 1) jboss:jboss-common-logging-log4j:jar:2.0.4-SNAPSHOT
 2) apache-log4j:log4j:jar:1.2.14

----------
1 required artifact is missing.

for artifact:
 jboss:jboss-common-logging-log4j:jar:2.0.4-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 jboss (http://repository.jboss.com/maven2/)

[dimitris]

That's my latest change (log4j.jar 1.2.8 -> 1.2.14) but how to upload the log4j. jar on the maven repository?

I tried this and it will just store it on the local filesystem.

X:\cvs\jboss-public\common\build>mvn install:install-file -DgroupId=apache-log4j
-DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=log4j.jar

[pgier]

I think the problem is fixed now. I changed the log4j dependency to point to the correct path. Log4j 1.2.14 was not in our repository, but it is in the central maven repository under /log4j/log4j.

I fixed the retro plugin and pointed the common build to version 0.5-SNAPSHOT version. For some reason jbossretro is not creating the classes-retro directory, and when the maven plugin couldn't find this folder it didn't fail gracefully. I will look into why the retro classes weren't created for logging-spi.

Note: you may have to do a "mvn -U" to get the updated version.

[pgier]

That's my latest change (log4j.jar 1.2.8 -> 1.2.14) but how to upload the log4j. jar on the maven repository?

To upload to our repository you will have to commit the files to cvs under "repository.jboss.com". The files are already in the central maven repo though, so you don't have to worry about it for now. I'm working on an easier way to upload thirdparty artifacts like this, but for now it's just a cvs commit of the required jar and pom.

[adrian.brock]

"pgier" wrote:
I think the problem is fixed now. I changed the log4j dependency to point to the correct path. Log4j 1.2.14 was not in our repository, but it is in the central maven repository under /log4j/log4j.

That's not a fix. We should be downloading everything from our repository.

We need to guarantee that we have control over the bytes we ship.
Which is just healthy paranoia.

Not to mention that in my limited use of Maven so far, I've personally
had at least three problems with stuff getting upgraded automatically inside
maven that just doesn't work and breaks the build.

This includes artifacts disappearing so it is impossible to even reproduce
an earlier build.

I'd prefer it if the maven repository (or any other) wasn't even checked when
we download stuff for JBoss projects.

We should be using a version of Maven from the jboss repository
that we know works and more importantly in two years time, we can download the
same version of Maven again to reproduce an old jboss project down to the exact byte.

[pgier]

I agree with you, our releases should be built entirely from our own repository. Right now we just don't have an easy way to copy things from the central repo when dependencies are updated. I will work on a new maven plugin (if I can't find an existing one) that can be used to copy a project dependency hierarchy from the central repository to our repository so that we have everything we need.

I can set up version 3 of the jboss-parent pom so that it will only use the jboss repository when doing a release. This should be part of our release process.

I would also like to have a new jboss repository just for third party dependencies. So we will have a releases repository, third party repository, and snapshot repository (for use during development).

[starksm64]

So let's get the first step of never looking to external repositories. Is this something that can be enforced at the project pom level, or does the user settings always allow for an override of the repo?

A feature request we had from the start was to go a step further and allow a project to only load from signed repositories. I know Ruel brought this up in the maven dev lists and there was some interest, but I don't think any progress has been made.

[starksm64]

That's my latest change (log4j.jar 1.2.8 -> 1.2.14) but how to upload the log4j. jar on the maven repository?

I tried this and it will just store it on the local filesystem.

X:\cvs\jboss-public\common\build>mvn install:install-file -DgroupId=apache-log4j
-DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=log4j.jar

To effectively use the repos as a local store and the path to push content into the repository, you need to setup your local repository to point to the cvs checkout of the repository.jboss.com/maven2 cvs module. This is done in your local ~/.m2/settings.xml or the mvn install conf/settings.xml. My settings.xml looks like:

[starksm@succubus Bios]$ cat ~/.m2/settings.xml
<settings>
 <!-- This could point to the cvs checkout of the
 repository.jboss.com/maven2 contents, or a separate local
 maven repo
 -->
 <localRepository>/usr/Repository/repository.jboss.com/maven2</localRepository>
 <profiles>
 <profile>
 <id>local-properties</id>
 <properties>
 <!-- This must point to the cvs or svn checkout of the jboss repository -->
 <jboss.repository.root>/usr/Repository/repository.jboss.com</jboss.repository.root>
 <!-- This must point to the cvs checkout of the
 repository.jboss.com/maven2 contents
 -->
 <maven.cvs.root>/usr/Repository/repository.jboss.com/maven2</maven.cvs.root>
 </properties>
 </profile>
 </profiles>

 <activeProfiles>
 <activeProfile>local-properties</activeProfile>
 </activeProfiles>
</settings>

where the /usr/Repository/repository.jboss.com path is where I have checked out the repository.jboss.com contents.

[pgier]

So let's get the first step of never looking to external repositories. Is this something that can be enforced at the project pom level, or does the user settings always allow for an override of the repo?

The central maven repo is defined in the super pom that all poms inherit from.

This repository can be disabled or overridden by defining a repository with the id "central" in your pom. I can change the jboss-parent pom so that the central repository is not used when performing a release. I would prefer to still allow the central repository during development builds, because this will allow us to download dependencies using the dependency plugin . The copy-dependencies goal can be used to copy all required dependencies for a project to a location on the file system. For example, a local checkout of the cvs repository.

I would like to have a separate thirdparty repository for this, because we might want the behaviour to be different between the jboss releases repo and the thirdparty repo, but for now we can just check in deps to the current repository (repository.jboss.org).

Does this sound ok?

[starksm64]

I don't see a problem with a separate tp repo. Most will not be updating this.