[jira] Created: (MNG-4963) Parent Artifact ist not downloaded from repository with certain settings
Parent Artifact ist not downloaded from repository with certain settings
Key: MNG-4963
URL: http://jira.codehaus.org/browse/MNG-4963
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories, POM
Affects Versions: 3.0.1, 3.0
Reporter: Stephan Pauxberger
Attachments: parent-projects.zip
Given the following two projects:
{{parent}}, released as organization POM
{{child}}, uses parent as its parent
parent pom is *NOT* in the local repository (i.e. new developer machine or
build node of the CI)
settings.xml defines:
a) a global mirror for all repositories
(http://local-nexus.srv/content/groups/public)
{{
Nexus
Coporate Nexus
http://local-nexus.srv/content/groups/public
*
}}
b) a profile "repos" including a snapshot repository and an active-profiles
entry activating this profile
{{
repos
nexus-snapshots
Projektserver Snapshots
http://local-nexus.srv/content/repositories/snapshots
false
true
fail
always
repos
}}
This is a fairly standard setup for copporate development.
now, when trying to compile the project, the following error is thrown:
{{
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project de.eucodos.bugs.maven:child:0.1-SNAPSHOT
(X:\ACM\test\child\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
de.eucodos.bugs.maven:parent:pom:0.1 and 'parent.relative
Path' points at wrong local POM @ line 3, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
}}
Without maven trying to download the parent from the corp-repo.
Sidenote: with Maven 2.x, this works without problems.
If an additional *release*-repository is included in profile "repos",
everything works as expected:
{{
repos
nexus
Projektserver
http://msgs722i.msg.de:8080/nexus/content/groups/public
true
nexus-snapshots
...
}}
--
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: (MNG-4964) build properties not resolved in profiles
build properties not resolved in profiles
-
Key: MNG-4964
URL: http://jira.codehaus.org/browse/MNG-4964
Project: Maven 2 & 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0.1
Environment: MacOSX Snow Leopard
Reporter: Kabhal
project.build.sourceDirectory is not resolved in the profile :
...
wscompile
${project.build.sourceDirectory}/com/company/directory
...
...
--
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-633) release:prepare on CVS flat multi-module project breaks at tagging
release:prepare on CVS flat multi-module project breaks at tagging
--
Key: MRELEASE-633
URL: http://jira.codehaus.org/browse/MRELEASE-633
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.1, 2.2
Environment: - Maven 3.0.1
- Tested with relase-plugin 2.1 and 2.2-SNAPSHOT
Reporter: Michael Glauche
When running "mvn release:prepare -DcommitByProject=true" on a simple flat
multi-module (parent and module are in the same directory) project the goal
does exit with:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on
project test-main: The scm url is invalid.
[ERROR] - The connection string contains too few tokens.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on
project test-main: The scm url is invalid.
- The connection string contains too few tokens.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
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:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
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:597)
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.MojoFailureException: The scm url is invalid.
- The connection string contains too few tokens.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
... 19 more
Caused by: org.apache.maven.shared.release.scm.ReleaseScmRepositoryException:
The scm url is invalid.
- The connection string contains too few tokens.
at
org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:87)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
... 22 more
However, the cvs commits earlier do work fine :
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "cvs -z3 -f -q commit -R -F
C:\Users\mglauche\AppData\Local\Temp\scm-commit-message1543133116513199803.txt
pom.xml"
[INFO] Working directory: C:\work\workspaces\maven\test-main
...
test-main pom.xml:
scm:cvs:pserver:${maven.scm.userna...@cvsserver:/home/cvs/repository/test:test-main
../module1
module1 pom.xml:
test-main
somegroup
0.0.2-SNAPSHOT
../test-main
somegroup
module1
0.0.2-SNAPSHOT
scm:cvs:pserver:${maven.scm.userna...@cvsserver:/home/cvs/repository/test:module1
${maven.scm.username} is set to the correct user with a settings.xml parameter.
The interesting thing is, the SCM provider does think the pom is valid:
$ mvn scm:validate
[INFO] --- mave
[jira] Closed: (MNG-4964) build properties not resolved in profiles
[
http://jira.codehaus.org/browse/MNG-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4964.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
This is known limitation. From [Introduction to
Profiles|http://maven.apache.org/guides/introduction/introduction-to-profiles.html]:
bq. As of Maven 2.0.9, the tags and could be interpolated.
Supported variables are system properties like ${user.home} and environment
variables like ${env.HOME}. Please note that properties defined in the POM
itself are not available for interpolation here.
> build properties not resolved in profiles
> -
>
> Key: MNG-4964
> URL: http://jira.codehaus.org/browse/MNG-4964
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.1
> Environment: MacOSX Snow Leopard
>Reporter: Kabhal
>Assignee: Benjamin Bentmann
>
> project.build.sourceDirectory is not resolved in the profile :
>
> ...
>
>
> wscompile
>
>
>
> ${project.build.sourceDirectory}/com/company/directory
>
>
> ...
>
>
> ...
>
--
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: (ARCHETYPE-358) Following mirror configuration from settings.xml
Following mirror configuration from settings.xml
Key: ARCHETYPE-358
URL: http://jira.codehaus.org/browse/ARCHETYPE-358
Project: Maven Archetype
Issue Type: Bug
Components: Generator, Plugin
Affects Versions: 2.1
Reporter: Grégory Joseph
It looks like the current snapshot of the plugin does not follow the mirror
configuration from my settings.xml when I do {{mvn archetype:generate}}. I
would expect it to grab the catalog from
{{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
instead of the central one.
--
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-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version
[ http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250780#action_250780 ] John Casey commented on MNG-4962: - Digging into this a bit further, it seems that DefaultModelBuilder.importDependencyManagement(..) is called twice when running release:prepare. The first time is as a result of the DefaultMaven.collectProjects(..) execution, where the complete list of project files is used to build up an effective reactor model cache. The second time is a result of MavenProject.getParent(), which uses the ProjectBuildingRequest stored in the MavenProject instance, and has no notion of other models available in the reactor. It seems like this is a special problem when it comes to loading import-scoped dependencies, since they have no relative path attached to them. With no relative path to use in reconstructing a reactor path, and no cached model for the BOM, parent POMs referencing BOMs in the same reactor will fail to build. Another symptom of this problem is that the failure to build the parent MavenProject instance on-demand will be visible only in the great wash of output that is the debug log-level. In other words, it will not prevent the build from progressing, in spite of the fact that an explicit call has to be made requesting this information in order to trigger the failure...which IMO by default we should assume is critical to the build's progress. If this call is made and the parent-project construction fails, the caller should be given the opportunity to handle the exception. > release:prepare with reactor BOM referenced from reactor parent POM results > in child with unchanged parent version > -- > > Key: MNG-4962 > URL: http://jira.codehaus.org/browse/MNG-4962 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0, 3.0.1, 3.0.2 >Reporter: John Casey > Attachments: release-parent-adjustment.zip, test.git.zip > > > I'm attaching a sample project that displays the behavior. > Essentially, the project structure is a multimodule project with two levels > of parent POMs, not unlike the structure found in maven-scm or similar. There > is also a top-level submodule that is just a Bill-of-Materials POM, named - > 'bom'. The second-level parent POM, named 'children' imports 'bom', and is > inherited by the 'child1' submodule. > When release:prepare is run, the POMs are transformed on disk, it seems to > trigger a re-resolution of the 'child1' parent reference - the > MavenProject.getParent() call triggers the ProjectBuilder.build(...) to > retrieve the 'children' POM. When this happens, the process of building the > 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this > point there is no reactor cache at all, much less one that contains the > proper coordinate for the transformed BOM. This means the > project-construction for 'children' fails, and the parent reference in the > 'child1' MavenProject instance is null...which means the release plugin's > check of MavenProject.hasParent() returns false, and the reference > doesn't get updated. > I haven't dug deeper than this, so I'm not sure how the reactor cache is > lost, or how it was ever preserved so that the MavenProject.getParent() call > could succeed under normal circumstances. > I know that the update works in this scenario when using Maven > 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing > it's taking advantage of a higher-level cache within the MavenProjectBuilder > itself to avoid losing track of the parents. I also know that it eagerly > builds/resolves/associates parent MavenProject instances, so maybe that has > something to do with it. -- 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-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version
[ http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250782#action_250782 ] John Casey commented on MNG-4962: - Thinking about this a little more, the root of this problem seems to be the change from 2.x -> 3.x to stop creating hard references between a MavenProject and it's parent MavenProject instance. In 2.2.1, the getParent() method made sense, since we were materializing the whole project set before we started...the philosophy was geared around the CLI and not long-running processes. In 3.x, having MavenProject.getParent() doesn't make sense. In 3.x, it requires storing a reference to the ProjectBuilder, which isn't a model object, it's a component. Also, it separates the use of the ProjectBuilder from the larger build context, what we're calling the reactor. The list of other files available in the reactor - and the models, coordinates, etc. available from those files - is lost to this ProjectBuilder usage. Maybe it'd be better to require callers to @Require their own reference to the ProjectBuilder and request the parent MavenProject instance through that, rather than allowing MavenProject.getParent(). Although, this currently shares some of the context issues, namely that the original reactor model cache seems to be discarded once the projects are constructed the first time by DefaultMaven.collectProjects()... > release:prepare with reactor BOM referenced from reactor parent POM results > in child with unchanged parent version > -- > > Key: MNG-4962 > URL: http://jira.codehaus.org/browse/MNG-4962 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0, 3.0.1, 3.0.2 >Reporter: John Casey > Attachments: release-parent-adjustment.zip, test.git.zip > > > I'm attaching a sample project that displays the behavior. > Essentially, the project structure is a multimodule project with two levels > of parent POMs, not unlike the structure found in maven-scm or similar. There > is also a top-level submodule that is just a Bill-of-Materials POM, named - > 'bom'. The second-level parent POM, named 'children' imports 'bom', and is > inherited by the 'child1' submodule. > When release:prepare is run, the POMs are transformed on disk, it seems to > trigger a re-resolution of the 'child1' parent reference - the > MavenProject.getParent() call triggers the ProjectBuilder.build(...) to > retrieve the 'children' POM. When this happens, the process of building the > 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this > point there is no reactor cache at all, much less one that contains the > proper coordinate for the transformed BOM. This means the > project-construction for 'children' fails, and the parent reference in the > 'child1' MavenProject instance is null...which means the release plugin's > check of MavenProject.hasParent() returns false, and the reference > doesn't get updated. > I haven't dug deeper than this, so I'm not sure how the reactor cache is > lost, or how it was ever preserved so that the MavenProject.getParent() call > could succeed under normal circumstances. > I know that the update works in this scenario when using Maven > 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing > it's taking advantage of a higher-level cache within the MavenProjectBuilder > itself to avoid losing track of the parents. I also know that it eagerly > builds/resolves/associates parent MavenProject instances, so maybe that has > something to do with it. -- 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-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version
[ http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250785#action_250785 ] John Casey commented on MNG-4962: - It would be nice to have the option to specify a durable "working memory" of sorts for Maven, with the default for long-running callers being an on-demand cache instead. This might give workflow executions like release:prepare or any normal build the opportunity to track things like BOMs present and used in the same reactor, while still allowing non-workflow usages like m2eclipse to function without too much overhead or risk of staleness. > release:prepare with reactor BOM referenced from reactor parent POM results > in child with unchanged parent version > -- > > Key: MNG-4962 > URL: http://jira.codehaus.org/browse/MNG-4962 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0, 3.0.1, 3.0.2 >Reporter: John Casey > Attachments: release-parent-adjustment.zip, test.git.zip > > > I'm attaching a sample project that displays the behavior. > Essentially, the project structure is a multimodule project with two levels > of parent POMs, not unlike the structure found in maven-scm or similar. There > is also a top-level submodule that is just a Bill-of-Materials POM, named - > 'bom'. The second-level parent POM, named 'children' imports 'bom', and is > inherited by the 'child1' submodule. > When release:prepare is run, the POMs are transformed on disk, it seems to > trigger a re-resolution of the 'child1' parent reference - the > MavenProject.getParent() call triggers the ProjectBuilder.build(...) to > retrieve the 'children' POM. When this happens, the process of building the > 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this > point there is no reactor cache at all, much less one that contains the > proper coordinate for the transformed BOM. This means the > project-construction for 'children' fails, and the parent reference in the > 'child1' MavenProject instance is null...which means the release plugin's > check of MavenProject.hasParent() returns false, and the reference > doesn't get updated. > I haven't dug deeper than this, so I'm not sure how the reactor cache is > lost, or how it was ever preserved so that the MavenProject.getParent() call > could succeed under normal circumstances. > I know that the update works in this scenario when using Maven > 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing > it's taking advantage of a higher-level cache within the MavenProjectBuilder > itself to avoid losing track of the parents. I also know that it eagerly > builds/resolves/associates parent MavenProject instances, so maybe that has > something to do with it. -- 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: (MNG-4962) MavenProject.getParent fails to build when parent POM, in reactor, references BOM also in reactor
[ http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4962: Summary: MavenProject.getParent fails to build when parent POM, in reactor, references BOM also in reactor (was: release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version) > MavenProject.getParent fails to build when parent POM, in reactor, references > BOM also in reactor > - > > Key: MNG-4962 > URL: http://jira.codehaus.org/browse/MNG-4962 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0, 3.0.1, 3.0.2 >Reporter: John Casey > Attachments: release-parent-adjustment.zip, test.git.zip > > > I'm attaching a sample project that displays the behavior. > Essentially, the project structure is a multimodule project with two levels > of parent POMs, not unlike the structure found in maven-scm or similar. There > is also a top-level submodule that is just a Bill-of-Materials POM, named - > 'bom'. The second-level parent POM, named 'children' imports 'bom', and is > inherited by the 'child1' submodule. > When release:prepare is run, the POMs are transformed on disk, it seems to > trigger a re-resolution of the 'child1' parent reference - the > MavenProject.getParent() call triggers the ProjectBuilder.build(...) to > retrieve the 'children' POM. When this happens, the process of building the > 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this > point there is no reactor cache at all, much less one that contains the > proper coordinate for the transformed BOM. This means the > project-construction for 'children' fails, and the parent reference in the > 'child1' MavenProject instance is null...which means the release plugin's > check of MavenProject.hasParent() returns false, and the reference > doesn't get updated. > I haven't dug deeper than this, so I'm not sure how the reactor cache is > lost, or how it was ever preserved so that the MavenProject.getParent() call > could succeed under normal circumstances. > I know that the update works in this scenario when using Maven > 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing > it's taking advantage of a higher-level cache within the MavenProjectBuilder > itself to avoid losing track of the parents. I also know that it eagerly > builds/resolves/associates parent MavenProject instances, so maybe that has > something to do with it. -- 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] Closed: (MPIR-217) Generating Dependency management report prints "Unable to create Maven project from repository." warning with ugly stacktrace
[
http://jira.codehaus.org/browse/MPIR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MPIR-217.
--
Resolution: Duplicate
Assignee: Lukas Theussl
> Generating Dependency management report prints "Unable to create Maven
> project from repository." warning with ugly stacktrace
> -
>
> Key: MPIR-217
> URL: http://jira.codehaus.org/browse/MPIR-217
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.3.1
> Environment: maven 3.0.1
> maven site plugin 3.0-beta-3
> java 1.6 u23
> windows 7 x64
>Reporter: Stevo Slavic
>Assignee: Lukas Theussl
>
> Generating Dependency management report results in [1] stack traces printed
> while generating site for a project. Btw, dependencies for which this stack
> trace gets printed, are not available on repository printed in the output
> messages. [2] is relevant pom.xml fragment.
> [1] Project build output fragment
> {code}
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find org.springframework
> .webflow:spring-binding:pom:${org.springframework.webflow.version} in
> https://repo.foo.bar.com/content/groups/foo-bar-
> group was cached in the local repository, resolution will not be reattempted
> until the update interval of foo-bar ha
> s elapsed or updates are forced for project
> org.springframework.webflow:spring-binding:pom:${org.springframework.webflow
> .version}
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:260)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtil
> s.java:332)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(Depen
> dencyManagementRenderer.java:219)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForS
> cope(DependencyManagementRenderer.java:198)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForA
> llScopes(DependencyManagementRenderer.java:147)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDe
> pendencies(DependencyManagementRenderer.java:140)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyM
> anagementRenderer.java:126)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:
> 115)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:165)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:159)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> 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:316)
> at org.apache.maven.DefaultMaven
[jira] Updated: (MCOMPILER-62) Allow multiple options to be passed to compiler for options not supported by the compiler mojo
[
http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Melentyev updated MCOMPILER-62:
-
Attachment: MCOMPILER-62-2.3.2.patch
here is updated MCOMPILER-62.patch for 2.3.2 version.
Also if you tired to wait, you can use my repo:
{code}
am
https://bitbucket.org/amelentev/mvnrepo/raw/tip/
{code}
And use 2.3.2-fix62 of maven-compiler-plugin
> Allow multiple options to be passed to compiler for options not supported by
> the compiler mojo
> --
>
> Key: MCOMPILER-62
> URL: http://jira.codehaus.org/browse/MCOMPILER-62
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
> Environment: Maven version: 2.0.7
>Reporter: Sanjeeb Sahoo
> Attachments: MCOMPILER-62-2.3.2.patch, MCOMPILER-62.patch
>
>
> Look at the mail thread in maven user group:
> http://www.nabble.com/Not-able-to-pass-multiple-arguments-to-javac-tf4857909s177.html
> User may have to pass options to the underlying compiler that are not yet
> supported by the mojo. Current implementation of the maven-compiler-plugin
> allows user to specify only one option. Neither of the following techniques
> work:
>
>-proc:none
>-implicit
>
> or
>
> -proc:none -impicit
>
> In the first approach, only one of the compilerArgument is considered, in the
> second approach since maven quotes the argument, it ends up as a single
> argument to javac and hence becomes an invalid option.
> The best suggestion is to allow multiple compilerArgument -- may be something
> like:
>
>
>
>
--
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: (MCOMPILER-62) Allow multiple options to be passed to compiler for options not supported by the compiler mojo
[ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Melentyev updated MCOMPILER-62: - Attachment: MCOMPILER-62-2.3.2.patch update patch to use StringUtils.split. support all whitespace chars. > Allow multiple options to be passed to compiler for options not supported by > the compiler mojo > -- > > Key: MCOMPILER-62 > URL: http://jira.codehaus.org/browse/MCOMPILER-62 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 >Reporter: Sanjeeb Sahoo > Attachments: MCOMPILER-62-2.3.2.patch, MCOMPILER-62-2.3.2.patch, > MCOMPILER-62.patch > > > Look at the mail thread in maven user group: > http://www.nabble.com/Not-able-to-pass-multiple-arguments-to-javac-tf4857909s177.html > User may have to pass options to the underlying compiler that are not yet > supported by the mojo. Current implementation of the maven-compiler-plugin > allows user to specify only one option. Neither of the following techniques > work: > >-proc:none >-implicit > > or > > -proc:none -impicit > > In the first approach, only one of the compilerArgument is considered, in the > second approach since maven quotes the argument, it ends up as a single > argument to javac and hence becomes an invalid option. > The best suggestion is to allow multiple compilerArgument -- may be something > like: > > > > -- 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: (MSITE-41) Add a list of available language in site plugin
[ http://jira.codehaus.org/browse/MSITE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yevgeny Nyden updated MSITE-41: --- Attachment: MSITE-41-maven-site-plugin.patch MSITE-41-doxia-sitetools.patch I added all available position options: left, right, navigation-top, navigation-bottom, bottom, so that the same positioning is avalable for i18nBanner, version, and release date. UI test is available here: http://sandbox.curre.net/mvn-site/0 (replace 0 with 1, 2... 5 to see other layout versions). Tested it on FF, Chrome, Safari, and IE7, 8. Is there an official statement on supported browsers? Btw, I wouldn't care about IE6 at this point. Note to self (and just so you know): I indent to do more work on this: 1) internationalize the title string on the i18nBannerLink; 2) add an image to i18nBannerLink; 3) refactor the publishDate template (it's a mess right now), which will probably remove all IE7 hacks I added; 4) make sure skins support the new i18nBanner; 5) write site documentation/example on how to configure i18n; 6) add unit tests to test the new feature. Anything else I missed? Is there somebody who can help me with some of these (e.g. documentation)? > Add a list of available language in site plugin > --- > > Key: MSITE-41 > URL: http://jira.codehaus.org/browse/MSITE-41 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: New Feature > Components: internationalization >Reporter: Vincent Siveton > Fix For: 2.3 > > Attachments: language_menu.jpg, language_menu.jpg, language_menu.jpg, > language_menu_as_select.jpg, MSITE-41-doxia-sitetools.patch, > MSITE-41-maven-site-plugin.patch > > > Please see the attached screenshots > This preference menu could be a list of links or a tag. > The site descriptor needs to be updated: > * for , by adding asSelect attribute in the menu element. > * for links list, by adding nostrong attribute in the menu element (to not > display as strong the current language and the current page) -- 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: (MINSTALL-80) Errors installing very minimal war
[ http://jira.codehaus.org/browse/MINSTALL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250824#action_250824 ] Mike Calmus commented on MINSTALL-80: - The attached pom was a simplified test case to illustrate the issue. The actual pom is copying an applet jar and its dependencies into a directory. This war is then merged into a larger war. > Errors installing very minimal war > -- > > Key: MINSTALL-80 > URL: http://jira.codehaus.org/browse/MINSTALL-80 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.2, 2.3, 2.3.1 >Reporter: Mike Calmus >Assignee: Benjamin Bentmann > Attachments: pom.xml > > > When certain directories don't exist in a war project, install fails. The > failure is somewhat different depending upon the maven-install-plugin version > used. The included pom.xml illustrates the behavior with version 2.3.1 which > gives the error: > The packaging for this project did not assign a file to the build artifact > org.apache.maven.lifecycle.LifecycleExecutionException: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > 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: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:124) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > With version 2.2 of the plugin the error says: > Error installing artifact: File D:\mydir\Test\target\classes does not exist > org.apache.maven.lifecycle.LifecycleExecutionException: Error installing > artifact: File D:\mydir\Test\target\classes does not exist > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Sourc
[jira] Commented: (MINSTALL-80) Errors installing very minimal war
[
http://jira.codehaus.org/browse/MINSTALL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250825#action_250825
]
Mike Calmus commented on MINSTALL-80:
-
Here is the plugin piece that is used.
org.apache.maven.plugins
maven-dependency-plugin
process-resources
copy-dependencies
${applet.directory}
true
> Errors installing very minimal war
> --
>
> Key: MINSTALL-80
> URL: http://jira.codehaus.org/browse/MINSTALL-80
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.2, 2.3, 2.3.1
>Reporter: Mike Calmus
>Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> When certain directories don't exist in a war project, install fails. The
> failure is somewhat different depending upon the maven-install-plugin version
> used. The included pom.xml illustrates the behavior with version 2.3.1 which
> gives the error:
> The packaging for this project did not assign a file to the build artifact
> org.apache.maven.lifecycle.LifecycleExecutionException: The packaging for
> this project did not assign a file to the build artifact
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> 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: The packaging for
> this project did not assign a file to the build artifact
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:124)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> With version 2.2 of the plugin the error says:
> Error installing artifact: File D:\mydir\Test\target\classes does not exist
> org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
> artifact: File D:\mydir\Test\target\classes does not exist
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>
[jira] Reopened: (MINSTALL-80) Errors installing very minimal war
[ http://jira.codehaus.org/browse/MINSTALL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Calmus reopened MINSTALL-80: - Please take a look at the additional information posted. This is still causing an issue for us. > Errors installing very minimal war > -- > > Key: MINSTALL-80 > URL: http://jira.codehaus.org/browse/MINSTALL-80 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.2, 2.3, 2.3.1 >Reporter: Mike Calmus >Assignee: Benjamin Bentmann > Attachments: pom.xml > > > When certain directories don't exist in a war project, install fails. The > failure is somewhat different depending upon the maven-install-plugin version > used. The included pom.xml illustrates the behavior with version 2.3.1 which > gives the error: > The packaging for this project did not assign a file to the build artifact > org.apache.maven.lifecycle.LifecycleExecutionException: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > 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: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:124) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > With version 2.2 of the plugin the error says: > Error installing artifact: File D:\mydir\Test\target\classes does not exist > org.apache.maven.lifecycle.LifecycleExecutionException: Error installing > artifact: File D:\mydir\Test\target\classes does not exist > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.
[jira] Closed: (MINSTALL-80) Errors installing very minimal war
[ http://jira.codehaus.org/browse/MINSTALL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MINSTALL-80. - Resolution: Not A Bug >From the provided information, the resolution is "wrong plugin configuration >by user", the project didn't get its main artifact set by any packaging >plugin, nor are there attached artifacts, so the Install Plugin fails as >expected during install. > Errors installing very minimal war > -- > > Key: MINSTALL-80 > URL: http://jira.codehaus.org/browse/MINSTALL-80 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.2, 2.3, 2.3.1 >Reporter: Mike Calmus >Assignee: Benjamin Bentmann > Attachments: pom.xml > > > When certain directories don't exist in a war project, install fails. The > failure is somewhat different depending upon the maven-install-plugin version > used. The included pom.xml illustrates the behavior with version 2.3.1 which > gives the error: > The packaging for this project did not assign a file to the build artifact > org.apache.maven.lifecycle.LifecycleExecutionException: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > 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: The packaging for > this project did not assign a file to the build artifact > at > org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:124) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > With version 2.2 of the plugin the error says: > Error installing artifact: File D:\mydir\Test\target\classes does not exist > org.apache.maven.lifecycle.LifecycleExecutionException: Error installing > artifact: File D:\mydir\Test\target\classes does not exist > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at j
[jira] Created: (DOXIASITETOOLS-45) assembleModelInheritance modifies parent DecorationModel
assembleModelInheritance modifies parent DecorationModel Key: DOXIASITETOOLS-45 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-45 Project: Maven Doxia Sitetools Issue Type: Bug Components: Decoration model Affects Versions: 1.1.4 Reporter: Lukas Theussl After calling DefaultDecorationModelInheritanceAssembler.assembleModelInheritance, the parent DecorationModel is usually different from the original. In particular paths get relativized because MenuItems, Links, etc. get referenced instead of copied into the merged model. I think that only the child should be modified after the method returns, as otherwise it is impossible to resolve another child against the same parent. I am not sure if this has any practical consequences, as the DefaultSiteTool does not use the parent anymore after assemblance, but it could well be the source of some subtle bugs. -- 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] Closed: (DOXIASITETOOLS-45) assembleModelInheritance modifies parent DecorationModel
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIASITETOOLS-45. --- Resolution: Fixed Fix Version/s: 1.1.5 Assignee: Lukas Theussl Fixed in [r1056527|http://svn.apache.org/viewvc?rev=1056527&view=rev] > assembleModelInheritance modifies parent DecorationModel > > > Key: DOXIASITETOOLS-45 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-45 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Decoration model >Affects Versions: 1.1.4 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1.5 > > > After calling > DefaultDecorationModelInheritanceAssembler.assembleModelInheritance, the > parent DecorationModel is usually different from the original. In particular > paths get relativized because MenuItems, Links, etc. get referenced instead > of copied into the merged model. I think that only the child should be > modified after the method returns, as otherwise it is impossible to resolve > another child against the same parent. I am not sure if this has any > practical consequences, as the DefaultSiteTool does not use the parent > anymore after assemblance, but it could well be the source of some subtle > bugs. -- 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: (MCOMPILER-62) Allow multiple options to be passed to compiler for options not supported by the compiler mojo
[ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250835#action_250835 ] Jesse Glick commented on MCOMPILER-62: -- "It won't break any existing pom files." - if you intentionally had -Akey=value with spaces that would be broken, if I understand the intent of the patch correctly. > Allow multiple options to be passed to compiler for options not supported by > the compiler mojo > -- > > Key: MCOMPILER-62 > URL: http://jira.codehaus.org/browse/MCOMPILER-62 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 >Reporter: Sanjeeb Sahoo > Attachments: MCOMPILER-62-2.3.2.patch, MCOMPILER-62-2.3.2.patch, > MCOMPILER-62.patch > > > Look at the mail thread in maven user group: > http://www.nabble.com/Not-able-to-pass-multiple-arguments-to-javac-tf4857909s177.html > User may have to pass options to the underlying compiler that are not yet > supported by the mojo. Current implementation of the maven-compiler-plugin > allows user to specify only one option. Neither of the following techniques > work: > >-proc:none >-implicit > > or > > -proc:none -impicit > > In the first approach, only one of the compilerArgument is considered, in the > second approach since maven quotes the argument, it ends up as a single > argument to javac and hence becomes an invalid option. > The best suggestion is to allow multiple compilerArgument -- may be something > like: > > > > -- 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-221) Deprecate the values used in the columnNames parameter for the Trac Report
Deprecate the values used in the columnNames parameter for the Trac Report -- Key: MCHANGES-221 URL: http://jira.codehaus.org/browse/MCHANGES-221 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: trac Affects Versions: 2.3 Reporter: Dennis Lundberg In order to create a common interface for issue management systems, both for developers and end users, we need to create a terminology that is used through out this plugin. One piece of that puzzle is the columnNames parameter that is used by both the JIRA and Trac mojos. I've started to collect info about different issue management systems here: http://docs.codehaus.org/display/MAVENUSER/Issue+Management+Systems I want us to use the "generic names" listed on that page, for all issue management systems. The first step is to introduce the new names in the Trac mojo. The old deprecated column names must work during a transition period, and the user should be warned if they use the deprecated ones. -- 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: (MPIR-216) Report on dependency-management throws Exceptions using version range for dependency
[
http://jira.codehaus.org/browse/MPIR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250848#action_250848
]
André Fügenschuh commented on MPIR-216:
---
According to Benjamin, is this issue correctly targeted here?
Or should I have to proceed as Vincent suggested?
> Report on dependency-management throws Exceptions using version range for
> dependency
>
>
> Key: MPIR-216
> URL: http://jira.codehaus.org/browse/MPIR-216
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.3.1
> Environment: Maven 3.0.1, Java 6u23
>Reporter: André Fügenschuh
> Attachments: pom.xml
>
>
> Given the following simple project:
> {code}
>
> 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
> foo
> app
> 3.0-SNAPSHOT
> App
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
>
> org.apache.maven.plugins
> maven-project-info-reports-plugin
> 2.3.1
>
>
>
>
> dependency-management
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> junit
> junit
> [4.8,)
> test
>
>
>
>
>
> junit
> junit
>
>
>
> {code}
> {{mvn site}} throws an exception (although site is generated):
> {code}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building App 3.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-3:site (default-site) @ app ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.3.1
> [WARNING] No URL defined for the project - decoration links will not be
> resolved
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Generating "Dependency Management" report---
> maven-project-info-reports-plugin:2.3.1
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find junit:junit:pom:[4.
> 8,) in http://uk.maven.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the updat
> e interval of UK has elapsed or updates are forced for project
> junit:junit:pom:[4.8,)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:260)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtil
> s.java:332)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(Depen
> dencyManagementRenderer.java:219)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForS
> cope(DependencyManagementRenderer.java:198)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForA
> llScopes(DependencyManagementRenderer.java:149)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDe
> pendencies(DependencyManagementRenderer.java:140)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyM
> anagementRenderer.java:126)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:
> 115)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.j
[jira] Commented: (MJAVADOC-181) Javadoc report not generated for multi-module project if run from parent level.
[ http://jira.codehaus.org/browse/MJAVADOC-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250849#action_250849 ] André Fügenschuh commented on MJAVADOC-181: --- @ Herve You are right. I don't know the IT, but the original intention was to *aggregate* javadocs at 'library' level (for 'module-\[a|b\]') and generate _non-aggregate_ javadocs for 'application'. As for me, this issue hasn't been resolved, see: [MSITE-518|http://jira.codehaus.org/browse/MSITE-518]. > Javadoc report not generated for multi-module project if run from parent > level. > --- > > Key: MJAVADOC-181 > URL: http://jira.codehaus.org/browse/MJAVADOC-181 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug > Environment: W2K, JDK 6u5, Maven 2.0.8 >Reporter: André Fügenschuh >Assignee: Vincent Siveton > Fix For: 2.6 > > Attachments: maven-site-javadoc-testcase.zip, > maven_release_failure_caused_by_mjavadoc.txt, MJAVADOC-181-1.patch, > MJAVADOC-181.patch > > > For the following project design (s. attached testcase): > parent > \- library// javadoc:aggregate! > \- module-a > \- module-b > \- application > javadoc report for 'library' is *not* generated (not invoked), if 'mvn site' > is > called at 'parent' level (but is properly done if run at 'library' level > itself). -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250856#action_250856 ] Andrei Pozolotin commented on MNG-4452: --- Benjamin: just to confirm, is it fixed in 3.0.1? the issue still affecting me thanks; Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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-4452) Metadata for snapshots should include classifier
[
http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250857#action_250857
]
Andrei Pozolotin commented on MNG-4452:
---
I guess, I must clarify:
1) yes I see in 3.0.1 that shapshots metadata does includes classifier;
2) the problem is that resolver still does not find attached artifacts form
previous deployments;
for example, this is repo metadata after 2 deployments:
note, that artifacts of interest are (build 83 and 84):
com.barchart.udt:barchart-udt4:1.0.2-20110108.023638-83:i386-Linux-g++-jni:nar
com.barchart.udt:barchart-udt4:1.0.2-20110108.023723-84:amd64-Linux-g++-jni:nar
##
com.barchart.udt
barchart-udt4
1.0.2-SNAPSHOT
−
−
20110108.023723
84
20110108023723
−
−
jar
1.0.2-20110108.023723-84
20110108023723
−
pom
1.0.2-20110108.023723-84
20110108023723
−
noarch
nar
1.0.2-20110108.023723-84
20110108023723
−
i386-Linux-g++-jni
nar
1.0.2-20110108.023638-83
20110108023638
−
amd64-Linux-g++-jni
nar
1.0.2-20110108.023723-84
20110108023723
##
and this is dependency declaration, I want 1 jar and 2 nar, platform dependent:
##
com.barchart.udt
barchart-udt4
${barchart.version}
jar
com.barchart.udt
barchart-udt4
${barchart.version}
i386-Linux-g++-jni
nar
com.barchart.udt
barchart-udt4
${barchart.version}
amd64-Linux-g++-jni
nar
##
and this is the error:
##
[INFO] Scanning for projects...
[INFO] snapshot com.barchart.udt:barchart-udt4-parent:1.0.0-SNAPSHOT: checking
for updates from sonatype-nexus-snapshots
[INFO]
[INFO] Building Unnamed -
com.barchart.udt:barchart-udt4-bundle:jar:1.0.0-SNAPSHOT
[INFO]task-segment: [validate]
[INFO]
[INFO] snapshot com.barchart.udt:barchart-udt4:1.0.2-SNAPSHOT: checking for
updates from sonatype-nexus-snapshots
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84.pom
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84.jar
78K downloaded (barchart-udt4-1.0.2-20110108.023723-84.jar)
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84-i386-Linux-g++-jni.nar
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84-amd64-Linux-g++-jni.nar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
##
in other words, the resolver tries to find
barchart-udt4-1.0.2-20110108.023723-84-i386-Linux-g++-jni.nar
and
barchart-udt4-1.0.2-20110108.023723-84-amd64-Linux-g++-jni.nar
both from latest build #84, instead of looking through the versioning
in order to find the file that actually exists in build #83:
barchart-udt4-1.0.2-20110108.023638-83:i386-Linux-g++-jni.nar
> Metadata for snapshots should include classifier
>
>
> Key: MNG-4452
> URL: http://jira.codehaus.org/browse/MNG-4452
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.2.1, 3.0-alpha-4
>Reporter: Paul Benedict
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
>
> Please see the whole conversation here:
> http://old.nabble.com/Multi-Platform-snapshots-td25295999.html
> Essentially, an artifact's classifier isn't included in the repository's
> metadata of a snapshot. This makes it difficult (impossible?) to deploy
> multiply snapshots with different classifiers. The primary use case is to
> continuously build an artifact for different environments.
--
This message is aut
[jira] Created: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
resolver fails to find artifacts with classifiers from previous deployments --- Key: MNG-4965 URL: http://jira.codehaus.org/browse/MNG-4965 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, windows x86, windows x86_64 jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 maven 3.0.1 Reporter: Andrei Pozolotin please see my comment and detailed example to the issue MNG-4452 http://jira.codehaus.org/browse/MNG-4452 -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250858#action_250858 ] Andrei Pozolotin commented on MNG-4452: --- forgot to mention: of course, this relates to SNAPSHOT artifacts only > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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
