[jira] Commented: (SUREFIRE-256) Incoherent data between 'Package List ' and 'Test Cases' items in report
[ http://jira.codehaus.org/browse/SUREFIRE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88534 ] Bernd commented on SUREFIRE-256: When working on this issue please also check the links to the duplicates > Incoherent data between 'Package List ' and 'Test Cases' items in report > > > Key: SUREFIRE-256 > URL: http://jira.codehaus.org/browse/SUREFIRE-256 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin >Reporter: Damien Lecan > Fix For: 2.4 > > Attachments: MSUREFIREREP-26-maven-surefire-plugin.patch, > MSUREFIREREP-26-maven-surefire-plugin.patch, surefire-report.html > > > As it can be seen of the attached file, the ConfigTest has incoherent data > between items 'Package List ' and 'Test Cases' . > In 'Package List ' : > Class Tests Errors FailuresSuccess RateTime > ConfigTest3 0 0100% > 0.585 > ConfigTest has just 3 tests. > But, in 'Test Cases', there are much more than 3 tests (they are duplicated > from the other tested class ManagerTest !) > ConfigTest > testCBEM1 0.039 > testCBEM2 0.001 > testCBEM3 0.001 > testCBEM4 0.001 > testCBEM5 0 > testCBEM6 0 > testCBEM7 0 > testCBEM8 0 > testCBEM9 0 > testCBEM10 0.001 > testCBEM11 0 > testCBEM12 0.001 > testGetBooleanProperty 0.528 > testGetFloatProperty0.029 > testGetIntProperty 0.012 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENENTERPRISE-1) Add real single sign-on
[ http://jira.codehaus.org/browse/MAVENENTERPRISE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88532 ] Archimedes Trajano commented on MAVENENTERPRISE-1: -- How is the sign-on currently implemented? Can't it easily be moved to use JAAS? > Add real single sign-on > --- > > Key: MAVENENTERPRISE-1 > URL: http://jira.codehaus.org/browse/MAVENENTERPRISE-1 > Project: Maven Enterprise > Issue Type: New Feature > Components: Security >Affects Versions: 1.0-alpha-1 >Reporter: Jason van Zyl > Fix For: 1.0-alpha-1 > > > Currently a shared database is being used which is acceptable but SSO would > be nice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-5) Support for Adding Compile-time References from the GAC
[ http://jira.codehaus.org/browse/NMAVEN-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88531 ] Shane Isbell commented on NMAVEN-5: --- The solution in the SI_IDE branch breaks with transitive dependencies. Direct GAC dependencies generally works; if project A has a direct GAC dependency and project B has a dependency on project A, the build fails, however. Directly adding the GAC dependency into project B does not fix the issue. > Support for Adding Compile-time References from the GAC > --- > > Key: NMAVEN-5 > URL: http://jira.codehaus.org/browse/NMAVEN-5 > Project: NMaven > Issue Type: Improvement > Environment: Windows, Linux, Mono, Microsoft >Reporter: Shane Isbell > > NMaven currently supports compile-time reference from the local maven repo on > the file system: these dependencies are specified within the pom build file. > In some circumstances, the artifacts cannot be legally distributed > (Microsoft); so I need a way for adding compile-time references from the GAC > itself. This improvement does not preclude the ability to import the > artifacts from the GAC into the local maven repo, it only extends the types > of dependencies that NMaven recognizes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88529
]
Joakim Erdfelt commented on WAGON-73:
-
The only possible way for this to loop infinitely is to have a cycle in the
mirror list.
A -> B -> C -> A
Instead of tackling this cycle directly, I am pre-initializing the mirror list
on construction of the MirroredWagon to make it clear what is going on for
future developers looking at this code.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
> Assigned To: Joakim Erdfelt
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-293) Possibility to run test with not isolated Classloader
Possibility to run test with not isolated Classloader - Key: SUREFIRE-293 URL: http://jira.codehaus.org/browse/SUREFIRE-293 Project: Maven Surefire Issue Type: Improvement Components: classloading Affects Versions: 2.3 Reporter: Piotr Tabor Attachments: useIsolatedClassLoaderPatch.diff I need a feature to run Maven's test in not isolated classloader. So I implemented it (and I attached patch to add it to maven trunk). I added useIsolatedClassLoader parameter (default to true), which is usefull only when forkMode is "none"/"never". If it's false - the parent classloader is set to the tests classloader. The option of not isolated classloader is important when MVN is run embaded in another program. The use case for the feature is: I have J2EE system with complicated Integration Tests (as Junit test cases). I used them by mvn test -Di-tests (i-tests is my profile to integration tests). Then i found, that i have to be able to test my system with using only Local interfaces of EJB (there are same cases that everythink is ok by "remote" and there are problems by local interaces - so i have to do both tests ). So I need to run's tests on Jboss application server. So I have written a service to run MVN as jboss service. But i couldn't use my test's because of isolated classloader. So please -- apply the patch to next plugin version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88505
]
Eugene Kuleshov commented on WAGON-73:
--
It would make it easier to apply if you provided a proper patch for the
required changes...
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1664) Write mojos w/Groovy
[ http://jira.codehaus.org/browse/MNG-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88502 ] Martin Gilday commented on MNG-1664: I have documented how to use the current groovy-maven-tools to write groovy mojos. Hopefully this will highlight the differences in the two approaches http://www.martingilday.org/articles/Groovy+Maven+Mojos > Write mojos w/Groovy > > > Key: MNG-1664 > URL: http://jira.codehaus.org/browse/MNG-1664 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Affects Versions: 2.0 >Reporter: Jason Dillon > Fix For: 2.2.x > > Attachments: maven2-groovy-mojo-support.tar.gz > > > Attached is an archive containing 3 modules: > * plexus-groovy-factory > * maven-plugin-tools-groovy > * groovytest-maven-plugin > plexus-groovy-factory is a plexus component factory, which allows Groovy > objects to be used as components inside of Plexus. I started with the > existing module of the same name in the plexus project, but most of it > changed, so I just included the entire module instead of providing a patch. > Tests included. > maven-plugin-tools-groovy provides the ability to extract MojoDescriptors > from one or more .groovy sources. This is based off of the beanshell > extractor.sh... its kinda hacky, but functions _well enough_ for now. > groovytest-maven-plugin is used to test. > groovytest-maven-plugin is just a simple maven plugin that uses the new > groovy script support. It shows that a .groovy can use other .groovy sources > inside of the plugin, and shows that the descriptor extractor functions. Its > basically useful for integration testing. > * * * > Someone should check & update the version details for the parent pom of these > modules. I just used whatever I had on my local system to get it working. > This plugin depends on Groovy 1.0 JSR 05, but 04 will sorta work, but will > not function with included classes in the same jar. Since 04 was just > releases yesterday, these modules depend on 05 SNAPSHOT, which should be > available on the codehaus ci repo. When 1.0 is released this dep should be > updated to that version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1664) Write mojos w/Groovy
[ http://jira.codehaus.org/browse/MNG-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88500 ] Jason Dillon commented on MNG-1664: --- I'm going to revisit this again... see whats usable here from my work, as well as whats usable in the current groovy plexus factory and the groovy-maven-tools at the Mojo project. > Write mojos w/Groovy > > > Key: MNG-1664 > URL: http://jira.codehaus.org/browse/MNG-1664 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Affects Versions: 2.0 >Reporter: Jason Dillon > Fix For: 2.2.x > > Attachments: maven2-groovy-mojo-support.tar.gz > > > Attached is an archive containing 3 modules: > * plexus-groovy-factory > * maven-plugin-tools-groovy > * groovytest-maven-plugin > plexus-groovy-factory is a plexus component factory, which allows Groovy > objects to be used as components inside of Plexus. I started with the > existing module of the same name in the plexus project, but most of it > changed, so I just included the entire module instead of providing a patch. > Tests included. > maven-plugin-tools-groovy provides the ability to extract MojoDescriptors > from one or more .groovy sources. This is based off of the beanshell > extractor.sh... its kinda hacky, but functions _well enough_ for now. > groovytest-maven-plugin is used to test. > groovytest-maven-plugin is just a simple maven plugin that uses the new > groovy script support. It shows that a .groovy can use other .groovy sources > inside of the plugin, and shows that the descriptor extractor functions. Its > basically useful for integration testing. > * * * > Someone should check & update the version details for the parent pom of these > modules. I just used whatever I had on my local system to get it working. > This plugin depends on Groovy 1.0 JSR 05, but 04 will sorta work, but will > not function with included classes in the same jar. Since 04 was just > releases yesterday, these modules depend on 05 SNAPSHOT, which should be > available on the codehaus ci repo. When 1.0 is released this dep should be > updated to that version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-292) [archiva-common] Fix BaseFileTest, so it will run on Windows
[ http://jira.codehaus.org/browse/MRM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Beyer (Apache) updated MRM-292: -- Attachment: BaseFileTest.diff Uploading BaseFileTest.diff again. The first upload contained changes out of the scope of this issue, sorry. > [archiva-common] Fix BaseFileTest, so it will run on Windows > > > Key: MRM-292 > URL: http://jira.codehaus.org/browse/MRM-292 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 >Reporter: Nathan Beyer (Apache) > Attachments: BaseFileTest.diff, BaseFileTest.diff > > > The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on > Windows platform, because it doesn't compensate for drive letters being > adding to the absolute paths. I've added some simple utility methods and > tweaked the expected values to compensate for this. I don't have a Linux box > to test on, so I haven't validated that they still work there, so the > committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-293) [archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows
[ http://jira.codehaus.org/browse/MRM-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Beyer (Apache) updated MRM-293: -- Attachment: GenericArtifactConsumerTest.diff GenerifArtifactConsumerTest.diff is a patch to correct this test case. > [archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows > --- > > Key: MRM-293 > URL: http://jira.codehaus.org/browse/MRM-293 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 >Reporter: Nathan Beyer (Apache) > Attachments: GenericArtifactConsumerTest.diff > > > The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on > Windows platform, because it doesn't compensate for drive letters being > adding to the absolute paths. I've added some simple utility methods and > tweaked the expected values to compensate for this. I don't have a Linux box > to test on, so I haven't validated that they still work there, so the > committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-293) [archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows
[ http://jira.codehaus.org/browse/MRM-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88497 ] Nathan Beyer (Apache) commented on MRM-293: --- I cloned MRM-292, because this issue has the same root cause, hardcoded separators in paths of the test cases. This issue is related to the test org.apache.maven.archiva.common.consumers.GenericArtifactConsumerTest. > [archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows > --- > > Key: MRM-293 > URL: http://jira.codehaus.org/browse/MRM-293 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 >Reporter: Nathan Beyer (Apache) > > The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on > Windows platform, because it doesn't compensate for drive letters being > adding to the absolute paths. I've added some simple utility methods and > tweaked the expected values to compensate for this. I don't have a Linux box > to test on, so I haven't validated that they still work there, so the > committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-293) [archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows
[archiva-common] Fix GenericArtifactConsumerTest, so it will run on Windows --- Key: MRM-293 URL: http://jira.codehaus.org/browse/MRM-293 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 Reporter: Nathan Beyer (Apache) The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on Windows platform, because it doesn't compensate for drive letters being adding to the absolute paths. I've added some simple utility methods and tweaked the expected values to compensate for this. I don't have a Linux box to test on, so I haven't validated that they still work there, so the committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-292) [archiva-common] Fix BaseFileTest, so it will run on Windows
[archiva-common] Fix BaseFileTest, so it will run on Windows Key: MRM-292 URL: http://jira.codehaus.org/browse/MRM-292 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 Reporter: Nathan Beyer (Apache) Attachments: BaseFileTest.diff The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on Windows platform, because it doesn't compensate for drive letters being adding to the absolute paths. I've added some simple utility methods and tweaked the expected values to compensate for this. I don't have a Linux box to test on, so I haven't validated that they still work there, so the committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2811) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors'
[ http://jira.codehaus.org/browse/MNG-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88490 ] David J. M. Karlsen commented on MNG-2811: -- and this only happens when calling the site goal > issue description: 'Plugin dependencies override maven core artifacts > causing NoClassDefFoundErrors' > - > > Key: MNG-2811 > URL: http://jira.codehaus.org/browse/MNG-2811 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 > Environment: OS agnostic, maven 2.0.4, jdk1.5 >Reporter: David J. M. Karlsen >Priority: Blocker > Attachments: 17artifactmultibulid.run1.log, 4artifact.filtered.log > > > Usecase: > wipe the local .m2 repo totally away. (rm -rf ~/.m2/repository) > do a: > mvn -X clean deploy site-deploy. > Attached is the output from two different projects (one is a 4 artifact > project - including the top pom, the other is a multibuild of 17 artifacts, > also including top-pom). > If I just re-run the "mvn -X clean deploy site-deploy" the builds will > eventually succeed. > I'll try to narrow down the pom's to pin down the failure with as little > dependencies and plugins in action as possible - but this will take some time. > I can be pinged at [EMAIL PROTECTED] or [EMAIL PROTECTED] for re-running > builds if needed. > The logs are a little anonymized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88489
]
Phillip Webb commented on WAGON-73:
---
Likewise for the connect method
public void connect()
throws ConnectionException, AuthenticationException
{
try
{
// Keep trying with .nextMirror() et al.
while ( true )
{
try
{
this.impl.connect();
}
catch ( ConnectionException e )
{
logger.warn( "Unable to connect to mirror [" +
this.impl.getRepository().getId() + "]" );
nextMirror();
}
catch ( AuthenticationException e )
{
logger.warn( "Unable to authenticate to mirror [" +
this.impl.getRepository().getId() + "]" );
nextMirror();
}
}
}
catch ( ExhaustedMirrorsException e )
{
logger.warn( e.getMessage() );
throw new ConnectionException( e.getMessage(), e );
}
}
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-73) MirroredWagon infinite loop
MirroredWagon infinite loop
---
Key: WAGON-73
URL: http://jira.codehaus.org/browse/WAGON-73
Project: wagon
Issue Type: Bug
Reporter: Phillip Webb
Priority: Critical
The MirroredWagon class includes a get method that runs into an infinite loop.
I think a return is required after this.impl.get( resource, destination );
public void get( String resource, File destination )
throws TransferFailedException, ResourceDoesNotExistException,
AuthorizationException
{
try
{
while ( true )
{
try
{
this.impl.get( resource, destination );
}
catch ( TransferFailedException e )
{
nextMirror();
}
}
}
catch ( ExhaustedMirrorsException e )
{
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2811) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors'
[ http://jira.codehaus.org/browse/MNG-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88485 ] David J. M. Karlsen commented on MNG-2811: -- It should be added that this also happens with maven 2.0.5 - could somebody with edit credentials update the issue? > issue description: 'Plugin dependencies override maven core artifacts > causing NoClassDefFoundErrors' > - > > Key: MNG-2811 > URL: http://jira.codehaus.org/browse/MNG-2811 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 > Environment: OS agnostic, maven 2.0.4, jdk1.5 >Reporter: David J. M. Karlsen >Priority: Blocker > Attachments: 17artifactmultibulid.run1.log, 4artifact.filtered.log > > > Usecase: > wipe the local .m2 repo totally away. (rm -rf ~/.m2/repository) > do a: > mvn -X clean deploy site-deploy. > Attached is the output from two different projects (one is a 4 artifact > project - including the top pom, the other is a multibuild of 17 artifacts, > also including top-pom). > If I just re-run the "mvn -X clean deploy site-deploy" the builds will > eventually succeed. > I'll try to narrow down the pom's to pin down the failure with as little > dependencies and plugins in action as possible - but this will take some time. > I can be pinged at [EMAIL PROTECTED] or [EMAIL PROTECTED] for re-running > builds if needed. > The logs are a little anonymized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
