Re: time-constrained repository instability

. Especially considering the difficulty related to matching poms with a certain version tag to binaries with another version tag (ie 1.4.2-rc1 and -rc2 vs 1.4.2, etc). Wayne On 5/19/06, Orjan Austvold [EMAIL PROTECTED] wrote: Daniel Kulp wrote: Right. But if an error is detected in a pom

time-constrained repository instability

During the last 8-10 months we have experienced several updates in already released artifacts in the maven repository at Ibiblio. Many of these has been caused by reports to Maven evangelism. For us this has been extremely problematic since the time of download of dependencies causes

Re: time-constrained repository instability

should reflect that the POM is different from what was released initially. Version 1.2.5 of something could then be released as 1.2-5-be-aware-im-fixed-1. Ørjan Wayne On 5/19/06, Orjan Austvold [EMAIL PROTECTED] wrote: During the last 8-10 months we have experienced several updates in already

Re: time-constrained repository instability

Dennis Lundberg wrote: For projects that use Maven for building and releasing your idea is good. But for projects that does not have a POM of their own this doesn't work. Most of the issues in MEV are for projects without POMs. The POMs that get uploaded to these issues are often not made by

Re: time-constrained repository instability

Daniel Kulp wrote: Right. But if an error is detected in a pom, why does the pom have to be updated.For example, if there is a: foo/1.0/foo-1.0.pom why can't we do something like Gentoo Linux and leave that alone and then add a: foo/1.0-R2/foo-1.0-R2.pom It's stilll foo 1.0 as release

Re: Site-deploy or wagon hanging (Maven 2.0.2, Red Hat and SuSe)

Hi, The site:deploy hang situation has been fixed and will be released in maven 2.0.3. See http://jira.codehaus.org/browse/MNG-1938 and http://jira.codehaus.org/browse/WAGONSSH-36 Ørjan Johnson, Jonathan wrote: Hi all, Is anyone aware that the following command mvn clean

Re: [m2] Using the pom version in JavaCode

Maven adds the pom.xml of war/jar artifacts to the archived file. You can retreive it on a running system by using somthing like getClass().getResourceAsStream(/META-INF/maven/groupId/artifactId/pom.xml); Ørjan Fredy wrote: Hi all, is there a library to access the pom Content from Java?

Re: Branch info lost on release [resolved]

for maven/component? Anyhow... It works, but now I can not understand what the tag element in the scm section is good for? :-) Ørjan Orjan Austvold wrote: We're using Maven 2 with CVS on several multi-module projects and we have successfully performed releases in the last 3 months. Yesterday we

Re: [m2] filePermissions not being used on mvn deploy

Hi, Add a filePermissions element in the server element in settings.xml. Mine is filePermissions664/filePermissions We also had to set the sticky group bit on the repository directory to allow for users to overwrite metadata files on which other users previously had released. -- Ørjan

Re: [m2] filePermissions not being used on mvn deploy

Hi again, I forgot to mention that the reason is that most (new) ssh server implementations do not allow for umask changes on scp/sftp. -- Ørjan Orjan Austvold wrote: Hi, Add a filePermissions element in the server element in settings.xml. Mine is filePermissions664/filePermissions We

Re: [m2] project-info-reports plugin fails (doxia-core-1.0-alpha-7 doesn't hold SiteRenderer anymore)

Is it only me who has problems getting the maven-project-info-reports version 2.0-beta-3 on maven 2.0.2 work? Isn't anybody using it on 2.0.2? Ørjan Orjan Austvold wrote: The maven-project-info-reports plugin fails in maven 2.0.2 due to doxia-core no longer holding

[m2] project-info-reports plugin fails (doxia-core-1.0-alpha-7 doesn't hold SiteRenderer anymore)

The maven-project-info-reports plugin fails in maven 2.0.2 due to doxia-core no longer holding the org.codehaus.doxia.site.renderer.SiteRenderer class. I've even tried with a clean local repository. Am I missing something? Thanks, Ørjan java.lang.NoClassDefFoundError:

Re: call for testers: scp wagon

Hi, Excellent! It works! On our local network everything has been running smoothly since early 2.0-beta releases, but we have experienced problems on slow network connections (repo in Oslo, Norway, client in Manila, Philipines). Our repo is on a Linux machine. File permissions have been set

Re: [m2] ActiveProjectArtifact

your own packaging goal, you need to call project.getArtifact().setFile( ... ) to ensure this is used. - Brett On 10/17/05, Orjan Austvold [EMAIL PROTECTED] wrote: Since I got now responses yet I'll try to clarify: A plugin that I wrote loops through the dependencies of an artifact trying

[m2] ActiveProjectArtifact

I have created a plugin which creates a custom distribution of artifacts built within a multi-project. Since maven-2.0-beta-3 I've seen that the file property of an ActiveProjectArtifact has changed from a reference to a jar-file to a reference of the artifacts target/classes directory. How

Re: [m2] ActiveProjectArtifact

? Thanks, Ørjan Orjan Austvold wrote: I have created a plugin which creates a custom distribution of artifacts built within a multi-project. Since maven-2.0-beta-3 I've seen that the file property of an ActiveProjectArtifact has changed from a reference to a jar-file to a reference

Re: [M2] Use key agent to handle SCP authentications

Hi, As far as I know I think you are right. If you are using keys for authentication on a server, you are also required to specify a password phrase for that key. Ørjan Jose Gonzalez Gomez wrote: Hi there, Is there any way to use a SSH key agent (like Pageant in Putty) to handle SCP

Re: [m2] faulty scp protocol handling in wagon?

alternative for you? - Brett On 10/5/05, Orjan Austvold [EMAIL PROTECTED] wrote: I noticed that sch 0.1.22 got released yesterday. Only to bad that that it did not include a fix for the MNG-678 issue. In the meantime I'm forced to continue providing a modified m2-b2 release containing a patched

Re: [m2] faulty scp protocol handling in wagon?

The patch on jsch made by Atsuhiko Yamanaka worked as expected. The intermittent failure with ScpWagon on session is down has vanished. -- Ørjan Brett Porter wrote: great! Thanks, Brett On 10/6/05, Orjan Austvold [EMAIL PROTECTED] wrote: I have discussed the bug fix the author if jsch

Re: [m2] faulty scp protocol handling in wagon?

: This is great. Thanks for your help on this - I'll take a look. - Brett On 9/30/05, Orjan Austvold [EMAIL PROTECTED] wrote: The issue with intermittent failure in ScpWagon seems to have been solved now. To me it seems to be a race condition between the thread running the ScpWagon

Re: [m2] invoking java -jar

Hi, The jar tool is located in the tools.jar archive. Try something like sun.tools.jar.Main jarTool = new sun.tools.jar.Main(System.out, System.err, jar); jarTool.run(new String[]{cfm, new-archive.jar, myManifest.mf}); Ørjan Ashley Williams wrote: Just to give a little more context I'm

Re: [m2] faulty scp protocol handling in wagon?

. I'd welcome any assistance you can provide. Thanks, Brett On 9/21/05, Orjan Austvold [EMAIL PROTECTED] wrote: Often when downloading new artifacts from a scp repository the build fails with Root error: session is down It could be that my the ssh configuration on the scp repository is faulty

Re: Logging/tracing conventions

Instead of having lots of debug statements in your Mojo, you could simply connect a debugger to Maven. I'm doing this with IDEA simply by running maven with MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 m2 install Ørjan

m2-b2?

I saw on Brett Porters blog that m2-b2 was out yesterday! Good news! The m2-sources have been tagged, but I cannot find a binary of m2-b2 for download at http://apache.org/dist/maven/binaries/ yet... Is there some automatic build that has to kick in before the download is made available?

Re: dependency resolution only before compile phase?

Brett Porter wrote: Yes, you should add @requiresDependencyResolution to your tags. On 9/24/05, Orjan Austvold [EMAIL PROTECTED] wrote: I noticed that the artifacts attribute of my plugin configured with parameter expression=${project.artifacts} did not get initialized with current project

dependency resolution only before compile phase?

I noticed that the artifacts attribute of my plugin configured with parameter expression=${project.artifacts} did not get initialized with current project dependencies when the plugin ran in the process-resource phase. When run in the compile phase it got initalized with the expected result.

Re: [m2] range dependencies in (at least) plugins breaks build

Ok. I'll file a bug with an example. Ørjan Brett Porter wrote: It is supported - this should work (and if there is a reason it couldn't find a version, it should report a better message). This is a bug. - Brett On 9/22/05, Orjan Austvold [EMAIL PROTECTED] wrote: In an eager attempt I

[m2] commons-lang and commons-codec includes junit for scope compile

This is probably not the right list to post this message to, but... Both commons-lang (2.1) and commons-codec (1.3) include junit for scope compile. Beside the broader scope warning for maven this breaks one of my plugins which collects dependencies for runtime. I know that adding an

Re: [m2] commons-lang and commons-codec includes junit for scope compile

Ok, I found lots of issues like this one on JIRA. Sorry for not searching Maven JIRA before posting here. -- Ørjan Trygve Laugstøl wrote: On Thu, 2005-09-22 at 23:33 +0200, Orjan Austvold wrote: This is probably not the right list to post this message to, but... Both commons-lang (2.1

[m2] range dependencies in (at least) plugins breaks build

In an eager attempt I came to specify a couple of dependencies in a parent-pom of a plugin as dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version[2.0-beta-1,)/version /dependency