[jira] (SUREFIRE-843) Unable to run 'mvn test' with Java 7
[
https://jira.codehaus.org/browse/SUREFIRE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293708#comment-293708
]
Sneha commented on SUREFIRE-843:
Hi Niraj ,
How did you fix this problem.
i am also facing the same issue
Tests run: 175, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error occurred in starting fork, check output in log
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Fri Mar 09 00:16:19 PST 2012
[INFO] Final Memory: 28M/61M
[INFO]
[snehaa@qa4 components]$ java -version
I am running 1.6,
[snehaa@qa4 components]$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode)
[snehaa@qa4 components]$
Any help in this regard will be greatly helpful as this is blocking me from
finishing some task.
Thx,
Sneha
> Unable to run 'mvn test' with Java 7
>
>
> Key: SUREFIRE-843
> URL: https://jira.codehaus.org/browse/SUREFIRE-843
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Mac OS X
> java version "1.7.0_04-ea"
> Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15, mixed mode)
>Reporter: Niraj Tolia
>
> I am trying to run mvn test and it always fails at some arbitrary time with
> the message 'Error occurred in starting fork'. See the output below. Note
> that it does not execute all tests but fails in between the test run. The
> number of tests surefire finishes executing is random but it has never
> completed the entire test run. I am using Java7u4 Build b13 with Maven 3.0.3
> and surefire v2.12.
> Any clue what might be going wrong? This is a blocker for me.
> {noformat}
> Results :
> Tests run: 230, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 41.204s
> [INFO] Finished at: Thu Feb 23 17:40:55 PST 2012
> [INFO] Final Memory: 17M/212M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
> project test-project: Error occurred in starting fork, check output in log ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test)
> on project test-project: Error occurred in starting fork, check output in log
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launche
[jira] (DOXIA-373) Macro snippet with file option in a multi-pom project
[
https://jira.codehaus.org/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293713#comment-293713
]
Andreas Veithen commented on DOXIA-373:
---
A workaround for this issue is to use (assuming that the file is a Velocity
templete, i.e. has suffix .apt.vm instead of .apt):
%{snippet|id=deployment|file=${project.basedir}/src/test/resources/client-config.wsdd}
> Macro snippet with file option in a multi-pom project
> -
>
> Key: DOXIA-373
> URL: https://jira.codehaus.org/browse/DOXIA-373
> Project: Maven Doxia
> Issue Type: Bug
> Environment: Window XP
>Reporter: poulfich
>
> The project is a multi pom project. In the main pom project, I declare the
> other pom like this :
>
> ../moduleA
> ../moduleB
>...
>
> To avoid duplicate code,I use the macro snippet in my documentation in
> modules A, B and Main. For convenient, the following syntax :
> %{snippet|id=myid|file=src/main/java/mypackage/File.java}.
> When I build the site from each module A or B, all work fine. But when the
> site was generated from the main module, the snippet seem not work : All the
> pages who include a snippet's macros in A or B are not generated. I obtain
> the same problem if i do a simple site or a site:stage
>
> The maven site work fine work include pictures and schemas of local
> documentation (in A et B). I try to use
> the velocity macro and transform MyFile.apt to MyFile.apt.vm like these :
> MyFile.apt.vm
> %{snippet|id=myid|file=${basedir}/src/main/java/mypackage/File.java}.
> It's fail too.
> I use maven 2.1.0
> Sorry for my poor english
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-632) from child module ignored
[
https://jira.codehaus.org/browse/MSITE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293723#comment-293723
]
Vincent Latombe commented on MSITE-632:
---
Hi,
I tried with the last 3.1-SNAPSHOT, which doesn't work (it still picks up the
url from the parent). With Kohsuke's proposed change, the url that is declared
in the current project is taken, as expected.
> from child module ignored
>
>
> Key: MSITE-632
> URL: https://jira.codehaus.org/browse/MSITE-632
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
>Reporter: Kohsuke Kawaguchi
>
> In trying to deploy
> https://github.com/kohsuke/windows-package-checker/tree/4658075119d6ce9e4d6b9975342bbbef477d5f50
> , I noticed that the I specified in this POM is ignored and the one
> specified in the parent is used instead. The same site deploys as expected
> with Maven2 with the site plugin 2.0-beta-7.
> Looking at the source code, I see that
> {{SiteDeployMojo.getDeployRepositoryURL()}} uses {{getRootSite}} to determine
> the site to deploy, which explains why my definition is getting
> ignored.
> I believe the fix is to use the nearest site definition, not the one that's
> closest to the root of the inheritance chain. That is, the {{getRootSite()}}
> should be changed from:
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
> to
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( site ==null && parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-843) Unable to run 'mvn test' with Java 7
[
https://jira.codehaus.org/browse/SUREFIRE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293730#comment-293730
]
Niraj Tolia commented on SUREFIRE-843:
--
Sneha: Try these steps to narrow down your problem:
1. Configure surefire to fork unit tests and then run mvn -X test.
2. Grab the surefire startup line from the debug output (should start with
/bin/bash).
3. Execute that command directly and when it fails, run 'echo $?' to get the
status.
4. Then grep all your code or any external code that might be calling
System.exit() with that status.
> Unable to run 'mvn test' with Java 7
>
>
> Key: SUREFIRE-843
> URL: https://jira.codehaus.org/browse/SUREFIRE-843
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Mac OS X
> java version "1.7.0_04-ea"
> Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15, mixed mode)
>Reporter: Niraj Tolia
>
> I am trying to run mvn test and it always fails at some arbitrary time with
> the message 'Error occurred in starting fork'. See the output below. Note
> that it does not execute all tests but fails in between the test run. The
> number of tests surefire finishes executing is random but it has never
> completed the entire test run. I am using Java7u4 Build b13 with Maven 3.0.3
> and surefire v2.12.
> Any clue what might be going wrong? This is a blocker for me.
> {noformat}
> Results :
> Tests run: 230, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 41.204s
> [INFO] Finished at: Thu Feb 23 17:40:55 PST 2012
> [INFO] Final Memory: 17M/212M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
> project test-project: Error occurred in starting fork, check output in log ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test)
> on project test-project: Error occurred in starting fork, check output in log
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error occurred in
> starting fork, check output in log
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:656)
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:645)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeM
[jira] (MRELEASE-602) Repositories defined in a profile are ignored while processing dependency management pom imports in a pom resolved from the repository
[
https://jira.codehaus.org/browse/MRELEASE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-602:
Description:
We define the repositories in a profile.
The dependency management resolution fails to resolve a pom import if the
import occurs
in an imported pom not found in the reactor.
The following code fragment shows the problem:
While merging managed dependencies of a dependency resolved from the
repository,
the {{ProjectBuilderConfiguration}} that is used do not contain the
{{ProfileManager}}.
{code:title=org.apache.maven.project.DefaultMavenProjectBuilder.java}
mergeManagedDependencies(...)
...
if ( dep.getType().equals( "pom" )
&& Artifact.SCOPE_IMPORT.equals( dep.getScope() ) )
{
Artifact artifact =
artifactFactory.createProjectArtifact( dep.getGroupId(), dep.getArtifactId(),
dep.getVersion(), dep.getScope() );
MavenProject project = buildFromRepository(artifact,
parentSearchRepositories, localRepository, false);
DependencyManagement depMgmt =
project.getDependencyManagement();
...
buildFromRepository(...)
...
Model model = findModelFromRepository( artifact,
remoteArtifactRepositories, localRepository, allowStubModel );
ProjectBuilderConfiguration config = new
DefaultProjectBuilderConfiguration().setLocalRepository( localRepository );
return buildInternal( "Artifact [" + artifact + "]", model, config,
remoteArtifactRepositories,
null, false );
buildInternal( ... )
...
ProfileManager externalProfileManager =
config.getGlobalProfileManager();
...
Set aggregatedRemoteWagonRepositories = new LinkedHashSet();
List activeExternalProfiles;
if ( externalProfileManager != null )
{
activeExternalProfiles =
externalProfileManager.getActiveProfiles();
}
else
{
activeExternalProfiles = Collections.EMPTY_LIST;
}
for ( Iterator i = activeExternalProfiles.iterator(); i.hasNext(); )
{
Profile externalProfile = (Profile) i.next();
for ( Iterator repoIterator =
externalProfile.getRepositories().iterator(); repoIterator.hasNext(); )
{
Repository mavenRepo = (Repository) repoIterator.next();
ArtifactRepository artifactRepo = artifactRepo =
ProjectUtils.buildArtifactRepository( mavenRepo,
artifactRepositoryFactory, container );
aggregatedRemoteWagonRepositories.add( artifactRepo );
}
}
{code}
Because the {{GlobalProfileManager}} was not specified in the
{{DefaultProjectBuilderConfiguration}},
the activeExternalProfiles list is empty and all "remote repositories" are
ignored.
In general, the {{ProjectBuilderConfiguration}} is created with a factory
method which correctly set the {{GlobalProfileManager}}.
{code:title=org.apache.maven.execution.DefaultMavenExecutionRequest.java}
public ProjectBuilderConfiguration getProjectBuilderConfiguration()
{
ProjectBuilderConfiguration config = new
DefaultProjectBuilderConfiguration();
config.setLocalRepository( getLocalRepository() )
.setGlobalProfileManager( getGlobalProfileManager() )
.setExecutionProperties( getExecutionProperties() )
.setUserProperties( getUserProperties() )
.setBuildStartTime( startTime );
return config;
}
{code}
was:
We define the repositories in a profile.
The dependency management resolution fails to resolve a pom import if the
import occurs
in an imported pom not found in the reactor.
The following code fragment shows the problem:
While merging managed dependencies of a dependency resolved from the
repository,
the ProjectBuilderConfiguration that is used do not contain the
ProfileManager.
Class: org.apache.maven.project.DefaultMavenProjectBuilder
mergeManagedDependencies(...)
...
if ( dep.getType().equals( "pom" )
&& Artifact.SCOPE_IMPORT.equals( dep.getScope() ) )
{
Artifact artifact =
artifactFactory.createProjectArtifact( dep.getGroupId(), dep.getArtifactId(),
dep.getVersion(), dep.getScope() );
MavenProject project = buildFromRepository(artifact,
parentSearchRepositories, localRepository, false);
DependencyManagement depMgmt =
project.getDependencyManagement();
...
buildFromReposito
[jira] (MRELEASE-464) snapshot dependencies are not resolved for items inside tag using release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-464:
Description:
release:prepare does not resolve snapshot dependencies for extensions. when
runing the command we see this prompt:
{quote}
"specify the selection number ( 0:All 1:Project Dependencies 2:Plugins
3:Reports 4:Extensions ): 1"
{quote}
Option 4 does not work at all. Using Option 0 or 1 will ask us to resolve the
dependency, but we always recieve an exception saying that the dependency has
not been resolved.
Here is an example of our POM:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
shared
pom
Visualization-Shared
Axway Visualization Shared
http://scm.axway.corp.sopra/sites
com.axway.visualization
parent
1.0.0-SNAPSHOT
PMDRules-server
model
security
scm:svn:http://anonymous@${project.scm-root}/shared/trunk
scm:svn:http://${project.scm-root}/shared/trunk
http://anonymous@${project.scm-root}/shared/trunk
hudson
${project.ciManagement-root}/shared_trunk
commons-io
commons-io
${commons-io.version}
junit
junit
${junit.version}
test
true
org.mockito
mockito-all
${mockito.version}
test
org.apache.maven.plugins
maven-pmd-plugin
1.6
${pmd.ruleset}.xml
true
utf-8
100
com.axway.visualization.parent
pmd-rules
1.0.0-SNAPSHOT
{code}
was:
release:prepare does not resolve snapshot dependencies for extensions. when
runing the command we see this prompt:
"specify the selection number ( 0:All 1:Project Dependencies 2:Plugins
3:Reports 4:Extensions ): 1"
Option 4 does not work at all. Using Option 0 or 1 will ask us to resolve the
dependency, but we always recieve an exception saying that the dependency has
not been resolved.
Here is an example of our POM:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
shared
pom
Visualization-Shared
Axway Visualization Shared
http://scm.axway.corp.sopra/sites
com.axway.visualization
parent
1.0.0-SNAPSHOT
PMDRules-server
model
security
scm:svn:http://anonymous@${project.scm-root}/shared/trunk
scm:svn:http://${project.scm-root}/shared/trunk
http://anonymous@${project.scm-root}/shared/trunk
hudson
${project.ciManagement-root}/shared_trunk
commons-io
commons-io
[jira] (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[
https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293731#comment-293731
]
Robert Scholte commented on MRELEASE-239:
-
I think we need to add the tab-character too.
Also: the {{InvokerMavenExecutor}} still splits on spaces only. This is valid
according to the javadoc, which states that {{goals}} is a space-delimited
String. Maybe it is better add an overloaded method to the
{{AbstractExecutor}}, which already translates the String to an array of goals,
so there's no doubt about its content.
> release:perform and release:prepare should accept multi-line
> goals/preparationGoals configurations
> --
>
> Key: MRELEASE-239
> URL: https://jira.codehaus.org/browse/MRELEASE-239
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0-beta-6
>Reporter: Steve Rowe
>Assignee: Stephen Connolly
>Priority: Minor
> Fix For: 2.2.1
>
> Attachments: ForkedMavenExecutor.patch
>
>
> When I specify a list of goals in my POM that span multiple lines (see an
> example below), only those goals before the newline are executed when I run
> "mvn release:perform".
> I have only noticed this for release:perform, but given what the code looks
> like, I assume it's an issue for release:prepare too.
> This is a minor problem, but an irritating one, because release:peform claims
> to successfully complete without actually executing all specified goals.
> I attach a patch to ForkedMavenExecutor.java that splits the goals list on
> newlines and carriage returns, in addition to the comma and space split
> characters that were there already.
> Here's an example configuration that will trigger the problem:
>
> maven-release-plugin
>
> ...
>
> package group:first-goal group:second-goal group:third-goal
> site-deploy changes:announcement-generate
> changes:announcement-mail
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
SebbASF created MNGSITE-152: --- Summary: Maven websites don't follow ASF rules on License Key: MNGSITE-152 URL: https://jira.codehaus.org/browse/MNGSITE-152 Project: Maven Project Web Site Issue Type: Bug Reporter: SebbASF ASF projects are supposed to provide a prominent link [0] to the ASF licenses page [1] AIUI, websites are not supposed to provide their own license pages. [0] http://apache.org/foundation/marks/pmcs.html#navigation [1] http://www.apache.org/licenses/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293734#comment-293734 ] Yoel Kazareski commented on MNG-5162: - It may be a bug between Java 7 and Windows 64bit. > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293734#comment-293734 ] Yoel Kazareski edited comment on MNG-5162 at 3/9/12 2:04 PM: - It may be a bug between Java 7 and Windows 64bit. Found this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-socket.html was (Author: yo_el_yoel): It may be a bug between Java 7 and Windows 64bit. > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-420) Prepare and Perform should use profile server settings
[
https://jira.codehaus.org/browse/MRELEASE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293739#comment-293739
]
Robert Scholte commented on MRELEASE-420:
-
What we're actually missing as an scm-id (just like every repository-section
has)
I think we can do the same trick as for sourceEncoding: introduce
${project.scm.id} which can be bound to a server-entry in the {{settings.xml}}
> Prepare and Perform should use profile server settings
> --
>
> Key: MRELEASE-420
> URL: https://jira.codehaus.org/browse/MRELEASE-420
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare
> Environment: latest in central as of this issue
>Reporter: Brill Pappin
>Priority: Critical
>
> The release plugin for some reason requires -Dusername= and -Dpassword= on
> the command line.
> The plugin should be using the standard profile server definitions instead
> (or as well as).
> Forcing the properties onto the command line is a security risk that doesn't
> need to be there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-722) release plugin must verify if tag exists and must failed in such case.
[ https://jira.codehaus.org/browse/MRELEASE-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-722: Fix Version/s: (was: 2.3) > release plugin must verify if tag exists and must failed in such case. > -- > > Key: MRELEASE-722 > URL: https://jira.codehaus.org/browse/MRELEASE-722 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > with svn, if tag already exists, the plugin doesn't fail but the result is > strange as sources are copying as subfolder on the existing tag. > BTW in this case the perform goal is executed on the previous tagged sources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-736) Add dryRun flag to release:perform
[
https://jira.codehaus.org/browse/MRELEASE-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293745#comment-293745
]
Robert Scholte commented on MRELEASE-736:
-
Fixed in [rev. 1299068|http://svn.apache.org/viewvc?rev=1299068&view=rev] for
the plugin, the manager has already been prepared in previous commits.
There's only one thing which I'm not sure about: the perform-goals will be
executed against the original project instead of the checked out project
(that's good). But this also means that it will {{deploy}} (and often
{{site-deploy}}) this SNAPSHOT-project. Should we try to catch these goals and
replace it with {{verify}} and {{site}} respectively? Or add another option so
you can choose? Prompt for it? Don't execute the goals, just say that it
normally would? Or just leave it like this?
> Add dryRun flag to release:perform
> --
>
> Key: MRELEASE-736
> URL: https://jira.codehaus.org/browse/MRELEASE-736
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform
>Affects Versions: 2.2.2
> Environment: mvn 3.0.3
>Reporter: Dominik Bartholdi
>Assignee: Robert Scholte
>
> Please consider to add the "dryRun" flag from the "release:prepare" to the
> "release:perform" goal too.
> I have the following use case:
> Jenkins/Hudson has a plugin called m2release which basically is there to help
> the user to trigger a maven release. This plugin allows to define a
> commandline which should be executed in case of a release build. The common
> configuration of this arguments are:
> "-Dresume=false release:prepare release:perform"
> the next version of the plugin would like to add a "dryRun" option when
> triggering a build and in this case it would just add "-DdryRun=true" to the
> configured arguments and thats it.
> Unfortunately this will not work, as the "release:perform" still gets
> executed and will fail.
> Of course I could also change the Jenkins/Hudson plugin, but this would mean
> I have to remove "release:perform" from the passed argument, which is relay
> ugly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-111) minimizeJar should not remove classes specifically included by filters
Shane StClair created MSHADE-111: Summary: minimizeJar should not remove classes specifically included by filters Key: MSHADE-111 URL: https://jira.codehaus.org/browse/MSHADE-111 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.5 Reporter: Shane StClair Currently there is no way to specify classes that should not be removed by minimizeJar. This means that projects using dynamically loaded classes (log4j, for instance) cannot use minimizeJar. This patch prevents minimizeJar from removing classes that were specified for inclusion in a filter. The patch also fixes a test in ComponentsXmlResourceTransformerTest that was failing on Windows due to different line breaks in a string comparison. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-111) minimizeJar should not remove classes specifically included by filters
[ https://jira.codehaus.org/browse/MSHADE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane StClair updated MSHADE-111: - Attachment: mshade-111.patch This is a patch file with test case. > minimizeJar should not remove classes specifically included by filters > -- > > Key: MSHADE-111 > URL: https://jira.codehaus.org/browse/MSHADE-111 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Shane StClair > Attachments: mshade-111.patch > > > Currently there is no way to specify classes that should not be removed by > minimizeJar. This means that projects using dynamically loaded classes > (log4j, for instance) cannot use minimizeJar. This patch prevents minimizeJar > from removing classes that were specified for inclusion in a filter. > The patch also fixes a test in ComponentsXmlResourceTransformerTest that was > failing on Windows due to different line breaks in a string comparison. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-111) minimizeJar should not remove classes specifically included by filters
[ https://jira.codehaus.org/browse/MSHADE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane StClair updated MSHADE-111: - Attachment: mshade-111-fixed.patch This is the fixed patch. Integration tests weren't included in the previous version. > minimizeJar should not remove classes specifically included by filters > -- > > Key: MSHADE-111 > URL: https://jira.codehaus.org/browse/MSHADE-111 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Shane StClair > Attachments: mshade-111-fixed.patch, mshade-111.patch > > > Currently there is no way to specify classes that should not be removed by > minimizeJar. This means that projects using dynamically loaded classes > (log4j, for instance) cannot use minimizeJar. This patch prevents minimizeJar > from removing classes that were specified for inclusion in a filter. > The patch also fixes a test in ComponentsXmlResourceTransformerTest that was > failing on Windows due to different line breaks in a string comparison. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293764#comment-293764 ] Dan Tran commented on MRELEASE-719: --- I ran into the same issue where I forgot the remove the bad svn tag, release:perpare went thru without error, and therefor release:perform picks up the wrong source > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: 2.3 > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2971) Variables are not replaced into installed pom file
[
https://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293765#comment-293765
]
Seth Call commented on MNG-2971:
Since this issue is 6 years old, maybe it's useful to give use-cases as to why
one would want to do this.
This thread discusses why myself and others would like to variablize the
version field (summary; to create a scheme where the SCM is the primary source
of version info)
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: https://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>Assignee: Ralph Goers
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: pom.xml
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-111) minimizeJar should not remove classes specifically included by filters
[ https://jira.codehaus.org/browse/MSHADE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293766#comment-293766 ] Shane StClair commented on MSHADE-111: -- Actually this patch isn't quite complete, as filter include patterns affect classes outside of the specified artifact (** on any filter will currently prevent any classes from being removed). > minimizeJar should not remove classes specifically included by filters > -- > > Key: MSHADE-111 > URL: https://jira.codehaus.org/browse/MSHADE-111 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Shane StClair > Attachments: mshade-111-fixed.patch, mshade-111.patch > > > Currently there is no way to specify classes that should not be removed by > minimizeJar. This means that projects using dynamically loaded classes > (log4j, for instance) cannot use minimizeJar. This patch prevents minimizeJar > from removing classes that were specified for inclusion in a filter. > The patch also fixes a test in ComponentsXmlResourceTransformerTest that was > failing on Windows due to different line breaks in a string comparison. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
