[jira] Commented: (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[
http://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243393#action_243393
]
Torsten Reinhard commented on MRELEASE-459:
---
I ran into a comparable problem:
I´ve had a 'local' profile, which was activated by default.
At mvn release:perform I want the profile 'release' to be activated - but what
happened was that both profiles ('local' and 'release') were activated, trying
to set the same variable.
My solution was, to remove the 'local' profile, which was activated by default
before.
but then, at mvn release:perform no more profiles got activated:
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -f maven-release-test -D performRelease=true
deploy site-deploy
= So i now added a 'dummy' profile that is activated by default, but does
nothing:
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -f maven-release-test -D performRelease=true -P
dummy,release deploy site-deploy
using this workaround, I got my 'release' profile to work - after spending some
hours with this issuePlease, fix that in one of the next releases or give a
hint in the documentation.
Thanx, Torsten
releaseProfiles has no effect without passing profiles in the command line
---
Key: MRELEASE-459
URL: http://jira.codehaus.org/browse/MRELEASE-459
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0-beta-8, 2.0-beta-9
Reporter: Andreas Christoforides
Attachments: patch.txt
The releaseProfiles parameter on the perform goal is not taken into
consideration when no other profiles are passed in the command line. In other
words, the current code only uses the value of the parameter if you have
additional profiles passed in.
Example:
mvn release:perform -P someProfile (uses releaseProfiles value)
mvn release:perform (does NOT use releaseProfiles value)
The plugin should use the parameter even if no other profiles are passed. It
should actually encourage release profiles configured in your POM as opposed
to arbitrary profiles passed in the command line.
I have included a patch that uses the releaseProfiles parameter regardless of
any profiles passed in the command line.
--
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: (MRELEASE-614) releaseProfiles works only if at least one (default) profile is activated in the same pom.xml
releaseProfiles works only if at least one (default) profile is activated in
the same pom.xml
-
Key: MRELEASE-614
URL: http://jira.codehaus.org/browse/MRELEASE-614
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0
Environment: WindowsXP, Maven-2.2.1
Reporter: Torsten Reinhard
related to MRELEASE-459 I decided to define an empty dummy profile, which is
activated by default instead of passing -P... at the command line at mvn
release:perform.
I´ve put this into our company parent pom.xml, next to the release profile that
might be enabled during mvn release:perform:
profiles
!-- default profile is needed, because otherwise mvn release:perform
will not activate the release profile --
!-- see http://jira.codehaus.org/browse/MRELEASE-459 for details--
profile
iddummy/id
activation
activeByDefaulttrue/activeByDefault
/activation
/profile
profile
idrelease/id
properties
!-- could be used at mvn release:perform --
!-- will set productVersion to the current
(released)project.scm.tag --
productVersion${project.scm.tag}/productVersion
/properties
/profile
Than, in one child module I configured the maven-release-plugin as:
configuration
workingDirectoryc:\LocalViewsRelease\${project.artifactId}-${project.version}/workingDirectory
preparationGoalsclean install/preparationGoals
releaseProfilesrelease/releaseProfiles
/configuration
= this should activate the dummy profile (which is activated by default) and
the release profile - but it does NOT !
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -D performRelease=true deploy site-deploy
I could only get this to work copying the dummy profile again into the child
pom.xml.
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -D performRelease=true -P dummy,release deploy
site-deploy
The fix should:
- fix MRELEASE-459 first, so no more default profile is needed to get
releaseProfiles to work
- fix the inheritance of (default) profiles during mvn release:perform
--
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: (SCM-469) Auto-generated config spec during release:perform contains line element * null
Auto-generated config spec during release:perform contains line element * null -- Key: SCM-469 URL: http://jira.codehaus.org/browse/SCM-469 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-clearcase Affects Versions: 1.2 Environment: Maven 2.0.9, Windows XP, Maven-Release-Plugin 2.0-beta-9 Reporter: Torsten Reinhard Priority: Critical When trying to release a module after migrating from maven-release-plugin 2.0-beta-8 to 2.0-beta-9 I got the following error during mvn release:perform: [INFO] [release:perform] [INFO] Checking out the project to perform the release ... [INFO] Executing: c:\LocalViewsReleasecmd.exe /X /C cleartool mkview -snapshot -tag reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT -vws \\d167961\kmdata\reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT.vws C:\LocalViewsRelease\gi [INFO] Created config spec for view 'reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT': element * CHECKEDOUT element * gide-parent-2.3-alpha-1 element * null load /GDCAMS/GDCAMS/src/gide-parent [INFO] Executing: c:\LocalViewsRelease\gide-parent-2.3-alpha-2-SNAPSHOTcmd.exe /X /C cleartool setcs -tag reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT C:\DOKUME~1\reinhart\LOKALE~1\Temp\configspec-reinhart-d167961-maven-gide-parent-2. [INFO] Executing goals 'deploy site-deploy'... [WARNING] Base directory is a file. Using base directory as POM location. [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing Maven. Working directory C:\LocalViewsRelease\gide-parent-2.3-alpha-2-SNAPSHOT\GDCAMS\GDCAMS\src\gide-parent does not exist! [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error executing Maven. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing Maven. at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Error executing Maven. at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89) at org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.java:67) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:336) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:282) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:262) at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129) ... 18 more Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
[jira] Created: (SUREFIRE-504) own classes and test-classes at the end of test classpath
own classes and test-classes at the end of test classpath
-
Key: SUREFIRE-504
URL: http://jira.codehaus.org/browse/SUREFIRE-504
Project: Maven Surefire
Issue Type: Bug
Components: plugin
Affects Versions: 2.4
Environment: Maven 2.0.9, Windows XP
Reporter: Torsten Reinhard
Own classes and test-classes may be added to the end of the classpath:
[DEBUG] Adding to surefire test classpath:
s:\mavenrepo\org\apache\maven\surefire\surefire-api\2.4\surefire-api-2.4.jar
[DEBUG] Test Classpath :
[DEBUG] s:\mavenrepo\log4j\log4j\1.2.13\log4j-1.2.13.jar
...
[DEBUG] s:\mavenrepo\org\apache\xmlsec\1.4.1\xmlsec-1.4.1.jar
[DEBUG] S:\pdv_cms\GDCAMS\src\pip\gdcams-pip-itest\target\classes
[DEBUG] S:\pdv_cms\GDCAMS\src\pip\gdcams-pip-itest\target\test-classes
This may happen, when you add the following terms to a parent pom.xml:
properties
target.dirtarget/target.dir
/properties
build
!-- special (output)Directory for Eclipse --
!-- see
http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-HowtoconfigureMavenprojecttouseseparateoutputfoldersinEclipse--
outputDirectory${project.basedir}/${target.dir}/classes/outputDirectory
testOutputDirectory${project.basedir}/${target.dir}/test-classes/testOutputDirectory
/build
profiles
profile
ideclipse-folders/id
properties
target.dirtarget-eclipse/target.dir
/properties
/profile
/profiles
The reason for that is:
SurefirePlugin#constructSurefireBooter changes the classpath by doing:
...
getLog().debug( Test Classpath : );
// Check if we need to add configured classes/test classes directories
here.
// If they are configured, we should remove the default to avoid
conflicts.
if ( !project.getBuild().getOutputDirectory().equals(
classesDirectory.getAbsolutePath() ) )
{
classpathElements.remove( project.getBuild().getOutputDirectory() );
classpathElements.add( classesDirectory.getAbsolutePath() );
}
if ( !project.getBuild().getTestOutputDirectory().equals(
testClassesDirectory.getAbsolutePath() ) )
{
classpathElements.remove(
project.getBuild().getTestOutputDirectory() );
classpathElements.add( testClassesDirectory.getAbsolutePath() );
}
...
project.getBuild().getOutputDirectory() is like ${basedir}/target/classes
classesDirectory.getAbsolutePath() is: ${basedir}\target\classes
So i think here a 2 bugs:
(1) files/directories shouldn´t be compared just as String.equals() - using
File.compareTo may be a better solution
(2) an Element of classpathElements shouldn´t be removed and added to the end
of the ArrayList, it should be replaced at the same position.
--
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: (MCHANGES-116) FileNotFoundException and NullPointerException if src/changes/changes.xml is missing
FileNotFoundException and NullPointerException if src/changes/changes.xml is missing Key: MCHANGES-116 URL: http://jira.codehaus.org/browse/MCHANGES-116 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: announcement Affects Versions: 2.0-beta-2 Environment: Maven-2.0.9, Windows XP Reporter: Torsten Reinhard If a changes.xml file is not found, the plugin terminates with an exception, see below. Maybe this could better be done with just a message? What about multi-module Builds? Is there a src/changes/changes.xml file expected in each module? I think it would be more stable, if a missing changes.xml will just be skipped. java.io.FileNotFoundException: C:\LocalViewsRelease\pip-2.7.1-SNAPSHOT\pdv_cms\GDCAMS\src\pip\gdcams-pip-common\src\changes\changes.xml (Das System kann den angegebenen Pfad nicht finden) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) at org.apache.maven.plugin.changes.ChangesXML.init(ChangesXML.java:65) at org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:232) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:931) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:767) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:529) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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) [INFO] Creating announcement file from changes.xml... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.announcement.AnnouncementMojo.getLatestRelease(AnnouncementMojo.java:367) at org.apache.maven.plugin.announcement.AnnouncementMojo.doGenerate(AnnouncementMojo.java:276) at
[jira] Created: (SCM-388) scm:clearcase:load ..... should support more than one loadrule
scm:clearcase:load . should support more than one loadrule
--
Key: SCM-388
URL: http://jira.codehaus.org/browse/SCM-388
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-clearcase
Affects Versions: 1.0-beta-3
Environment: Windows XP, Maven 2.0.9
Reporter: Torsten Reinhard
With auto-generated configSpecs actually there is a limitation:
...
Specify one load rule for the project you want to check out within the SCM URL
...
In many cases, more than one loadRule would be very useful - this will also
prevent from moving modules from one directory to another, just for having them
all under one parent-directory for scm:goal purposes.
Therefore specifying
scm:clearcase:load /MY_VOB/my/project/dir, load /MY_VOB/my/project/dir2, load
/MY_VOB/my/project/dir3
could be an idea?
The fix for that is just a StringTokenizer in the method
protected String createConfigSpec( String loadDirectory, ScmVersion version
)
{
// TODO replace this with a StringTokenizer
configSpec.append( load + loadDirectory + \n );
return configSpec.toString();
}
at
org.apache.maven.scm.provider.clearcase.command.checkout.ClearCaseCheckOutCommand
Can anyone do that little enhancement?
--
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: (MEAR-82) From version 2.3 on, resources are not always copied to the EAR structure
[
http://jira.codehaus.org/browse/MEAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126732
]
Torsten Reinhard commented on MEAR-82:
--
I just wondered, why I was missing resources in my ear, too.
Have you tried to configure
resourcesDir${project.build.outputDirectory}/resourcesDir ?
Don´t know, why this is not a default...
From version 2.3 on, resources are not always copied to the EAR structure
-
Key: MEAR-82
URL: http://jira.codehaus.org/browse/MEAR-82
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3, 2.3.1
Reporter: Emmanuel
Attachments: dummyProject.zip
I had a EAR project that copied resources from a higher-level folder (see
../ below). It worked perfectly with maven-ear-plugin version 2.2
With versions 2.3 and 2.3.1, it seems to have stopped working that way.
However, I see nowhere an indication on whether it is a new feature /
impovement or a bug. Or is it that I'm not using it the right way? But if so,
how do you explain the change of behaviour between versions 2.2 and 2.3 ?
Here above is a part of a Ear POM that shows the problem.
And attached is a complete simple project to help reproduce the problem.
packagingear/packaging
[...]
resources
resource
directory../myResources/directory
targetPathtargResources/targetPath
includes
include*.properties/include
/includes
/resource
/resources
plugins
plugin
artifactIdmaven-ear-plugin/artifactId
!-- From Version 2.3 on, resources are no longer
copied properly. Bug or evolution? --
!--version2.3.1/version--
version2.2/version
/plugin
/plugins
[...]
Hope this helps make a better (world?) plugin.
--
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: (MDEP-154) dependency:copy always creates new timestamp, when copying from Repository to local filesystem
dependency:copy always creates new timestamp, when copying from Repository to local filesystem -- Key: MDEP-154 URL: http://jira.codehaus.org/browse/MDEP-154 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: copy, copy-dependencies Affects Versions: 2.1 Environment: Windows XP version2.0-alpha-5-20080115.230021-25/version Reporter: Torsten Reinhard Assignee: Brian Fox Priority: Minor From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2008 7:00 AM To: [EMAIL PROTECTED] Subject: dependency:copy always creates new timestamp Hi, to create the delivery version of our whole system, I use dependency:copy and dependency:copy-dependencies to copy the jars, ears, wars and so on from our internal repository into a defined directory structure. productVersion Install Module-A xyz.war Module-B xyz.ear Documentation *.doc Every time I start the delivery build, the copied artifacts get new timestamps - although the version hasn´t changed in between. I couldn´t find any property keep original timestamp to set for the goals copy or copy-dependencies. Is there a way? Thanx, Torsten -- 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: (MASSEMBLY-293) fileSets not filtered in multimodule build, but files are
fileSets not filtered in multimodule build, but files are - Key: MASSEMBLY-293 URL: http://jira.codehaus.org/browse/MASSEMBLY-293 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Windows XP Reporter: Torsten Reinhard Attachments: install.xml, update-db2.sh Filtering doesn´t work in a multimodule build if I use fileSet instead of files - if I build the module separately, it works Shouldn´t the behaviour be the same? I have not looked into the code, but I expect one thing is collection the files (however the filelist is expressed), the other is filtering them. It seems, as the separation of functionality is mixed in here? See the attached file(s) as example. -- 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: (MWAR-126) It is not possible to package empty war.
[
http://jira.codehaus.org/browse/MWAR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125187
]
Torsten Reinhard commented on MWAR-126:
---
I´ve been running into the same problem, here´s a part of my pom.xml:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
classifier${typeClassifier}/classifier
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
/configuration
/plugin
/plugins
/build
profiles
profile
idservice-remote-spring/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
typeClassifier/typeClassifier
/properties
...
/profile
profile
idservice-local-mock/id
properties
typeClassifiermock/typeClassifier
/properties
...
/profile
The build without any classifier works fine,
The build with the classifier mock only works, when I have a target\classes
directory which may be empty !
It is not possible to package empty war.
Key: MWAR-126
URL: http://jira.codehaus.org/browse/MWAR-126
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Libor Kramolis
Attachments: war-bug.txt
If there is no java sources and no resources (src/main/java and
src/main/resources does not exist) it is not possible to package war
application.
But if I do NOT user classifier of war plugin there is no problem while
war:war goal.
--
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifact: File
d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing
artifact: File
d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
at
org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
Error installing artifact: File
d:\work\tutor\development\tutorialproject-war_ws\target\classes does not exist
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:87)
