[jira] [Resolved] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka resolved MNG-5863. --- Resolution: Won't Fix understood. Another workaround, and probably also the right solution, is to rely on own "corporate-wide" parent poms defining a release profile completely independently. Thanks anyway > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5863) default pom's release-profile should invoke source with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated MNG-5863: -- Summary: default pom's release-profile should invoke source with goal "jar-no-fork" instead of "jar" (was: default pom's release-profile should use goal "jar-no-fork" instead of "jar") > default pom's release-profile should invoke source with goal "jar-no-fork" > instead of "jar" > --- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated MNG-5863: -- Summary: default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar" (was: default pom's release-profile should invoke source with goal "jar-no-fork" instead of "jar") > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5863) default pom's release-profile should use goal "jar-no-fork" instead of "jar"
Petr Kozelka created MNG-5863: - Summary: default pom's release-profile should use goal "jar-no-fork" instead of "jar" Key: MNG-5863 URL: https://issues.apache.org/jira/browse/MNG-5863 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.3.3 Reporter: Petr Kozelka in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" which binds some executions to the lifecycle. One of them is source:jar - which forks the build. That can be a problem in some configurations, and the forking is probably not necessary. One situation where the forked build hurts is this: - I have checkstyle:check attached to phase "validate" - some of my modules generate code, obviously not compliant to the checkstyle The problem is that, inside forked build, the checkstyle:check is called again, but now it checks also the generated code (because target/ is no longer empty). And of course fails. Even worse: during normal development iterations, everything is fine. But when I have to issue a release (usually under some pressure), I hit this problem. Fortunately, there _is_ a workaround: override the execution "attach-sources" and assign it to a non-existing phase, and define execution with different id for that. But it is too ugly and I believe that the simple fix would solve it - for the meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (SCM-650) HgChangeLogConsumer generates phantom 'null' changeset at the end
[ https://jira.codehaus.org/browse/SCM-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka closed SCM-650. Resolution: Fixed Fix Version/s: 1.9 > HgChangeLogConsumer generates phantom 'null' changeset at the end > - > > Key: SCM-650 > URL: https://jira.codehaus.org/browse/SCM-650 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.6 >Reporter: Petr Kozelka > Fix For: 1.9 > > Attachments: scm-hg-revision-null.patch > > > $subject says it all > - the phantom changeset has no fields set, revision=null > - the fix is trivial, moves adding the changeset to result list to a place > where line "changeset:" is already detected -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-679) enhance scm api to support limited number of returned changesets by changelog command
[
https://jira.codehaus.org/browse/SCM-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301578#comment-301578
]
Petr Kozelka commented on SCM-679:
--
Hi Olivier,
attached scm-changelog-limit-wrapped.patch contains the request-style as you
suggested.
Few implementation notes:
- to keep the changes minimalistic, especially in the implementation part, I am
reusing as much of existing "argument rich" methods code as possible; rewriting
these might require heavy testing, so it's perhaps better to leave it up to
separate contributions
- on the API side, I deprecated all other "changelog" overloads to clearly
indicate the (as I suppose) preferred calling style
- ScmRequest holds all the data, most of them within a CommandParameters
object; this simplifies passing the data down to the implementation side
- no method chaining introduced yet but it might be a nice next improvement
- this request/result style of passing api parameters might be similarly useful
for other commands, I will keep that in mind when submitting patches in future
> enhance scm api to support limited number of returned changesets by changelog
> command
> -
>
> Key: SCM-679
> URL: https://jira.codehaus.org/browse/SCM-679
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-api, maven-scm-provider-bazaar,
> maven-scm-provider-git, maven-scm-provider-mercurial (hg),
> maven-scm-provider-svn
>Affects Versions: 1.7, 1.8
>Reporter: Petr Kozelka
> Attachments: scm-changelog-limit.patch,
> scm-changelog-limit-wrapped.patch
>
>
> The current api returns changesets between specified/unspecified
> dates/revisions.
> This leaves some important usecases unsupported; some of them are:
> - get last changeset on given repository/path
> - get last n changesets there ("first page" when browsing changes)
> The only workarround currently possible is, list all commits and filter them
> - but this is very time consuming.
> For this reason, I propose attached enhancement which overloads the changeLog
> method, adding the limit parameter:
> {code}
> ChangeLogScmResult changeLog( ScmRepository repository, ScmFileSet
> fileSet, Date startDate, Date endDate,
> int numDays, ScmBranch branch, String
> datePattern, Integer limit )
> throws ScmException;
> {code}
> For the "last changeset" usecase, the client sets limit = 1.
> For "paged browsing", it can specify null startDate/endDate on firstPage, and
> then work with dates for next/previous pages, still using the limit to
> specify page size.
> Note that the limit parameter can be null (as it is "Integer", not "int") to
> specify unlimited number of returned changesets.
> The suggested patch includes deprecations of enhanced methods, I hope this is
> a good way to reduce the number of actively used overloaded variants of
> "changelog" in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-679) enhance scm api to support limited number of returned changesets by changelog command
[
https://jira.codehaus.org/browse/SCM-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka updated SCM-679:
-
Attachment: scm-changelog-limit-wrapped.patch
request style patch
> enhance scm api to support limited number of returned changesets by changelog
> command
> -
>
> Key: SCM-679
> URL: https://jira.codehaus.org/browse/SCM-679
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-api, maven-scm-provider-bazaar,
> maven-scm-provider-git, maven-scm-provider-mercurial (hg),
> maven-scm-provider-svn
>Affects Versions: 1.7, 1.8
>Reporter: Petr Kozelka
> Attachments: scm-changelog-limit.patch,
> scm-changelog-limit-wrapped.patch
>
>
> The current api returns changesets between specified/unspecified
> dates/revisions.
> This leaves some important usecases unsupported; some of them are:
> - get last changeset on given repository/path
> - get last n changesets there ("first page" when browsing changes)
> The only workarround currently possible is, list all commits and filter them
> - but this is very time consuming.
> For this reason, I propose attached enhancement which overloads the changeLog
> method, adding the limit parameter:
> {code}
> ChangeLogScmResult changeLog( ScmRepository repository, ScmFileSet
> fileSet, Date startDate, Date endDate,
> int numDays, ScmBranch branch, String
> datePattern, Integer limit )
> throws ScmException;
> {code}
> For the "last changeset" usecase, the client sets limit = 1.
> For "paged browsing", it can specify null startDate/endDate on firstPage, and
> then work with dates for next/previous pages, still using the limit to
> specify page size.
> Note that the limit parameter can be null (as it is "Integer", not "int") to
> specify unlimited number of returned changesets.
> The suggested patch includes deprecations of enhanced methods, I hope this is
> a good way to reduce the number of actively used overloaded variants of
> "changelog" in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-679) enhance scm api to support limited number of returned changesets by changelog command
[
https://jira.codehaus.org/browse/SCM-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301488#comment-301488
]
Petr Kozelka commented on SCM-679:
--
good idea, I will rewrite the patch
> enhance scm api to support limited number of returned changesets by changelog
> command
> -
>
> Key: SCM-679
> URL: https://jira.codehaus.org/browse/SCM-679
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-api, maven-scm-provider-bazaar,
> maven-scm-provider-git, maven-scm-provider-mercurial (hg),
> maven-scm-provider-svn
>Affects Versions: 1.7, 1.8
>Reporter: Petr Kozelka
> Attachments: scm-changelog-limit.patch
>
>
> The current api returns changesets between specified/unspecified
> dates/revisions.
> This leaves some important usecases unsupported; some of them are:
> - get last changeset on given repository/path
> - get last n changesets there ("first page" when browsing changes)
> The only workarround currently possible is, list all commits and filter them
> - but this is very time consuming.
> For this reason, I propose attached enhancement which overloads the changeLog
> method, adding the limit parameter:
> {code}
> ChangeLogScmResult changeLog( ScmRepository repository, ScmFileSet
> fileSet, Date startDate, Date endDate,
> int numDays, ScmBranch branch, String
> datePattern, Integer limit )
> throws ScmException;
> {code}
> For the "last changeset" usecase, the client sets limit = 1.
> For "paged browsing", it can specify null startDate/endDate on firstPage, and
> then work with dates for next/previous pages, still using the limit to
> specify page size.
> Note that the limit parameter can be null (as it is "Integer", not "int") to
> specify unlimited number of returned changesets.
> The suggested patch includes deprecations of enhanced methods, I hope this is
> a good way to reduce the number of actively used overloaded variants of
> "changelog" in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-679) enhance scm api to support limited number of returned changesets by changelog command
Petr Kozelka created SCM-679:
Summary: enhance scm api to support limited number of returned
changesets by changelog command
Key: SCM-679
URL: https://jira.codehaus.org/browse/SCM-679
Project: Maven SCM
Issue Type: New Feature
Components: maven-scm-api, maven-scm-provider-bazaar,
maven-scm-provider-git, maven-scm-provider-mercurial (hg),
maven-scm-provider-svn
Affects Versions: 1.7, 1.8
Reporter: Petr Kozelka
Attachments: scm-changelog-limit.patch
The current api returns changesets between specified/unspecified
dates/revisions.
This leaves some important usecases unsupported; some of them are:
- get last changeset on given repository/path
- get last n changesets there ("first page" when browsing changes)
The only workarround currently possible is, list all commits and filter them -
but this is very time consuming.
For this reason, I propose attached enhancement which overloads the changeLog
method, adding the limit parameter:
{code}
ChangeLogScmResult changeLog( ScmRepository repository, ScmFileSet fileSet,
Date startDate, Date endDate,
int numDays, ScmBranch branch, String
datePattern, Integer limit )
throws ScmException;
{code}
For the "last changeset" usecase, the client sets limit = 1.
For "paged browsing", it can specify null startDate/endDate on firstPage, and
then work with dates for next/previous pages, still using the limit to specify
page size.
Note that the limit parameter can be null (as it is "Integer", not "int") to
specify unlimited number of returned changesets.
The suggested patch includes deprecations of enhanced methods, I hope this is a
good way to reduce the number of actively used overloaded variants of
"changelog" in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-676) Add property "revision" to CheckOutScmResult
Petr Kozelka created SCM-676: Summary: Add property "revision" to CheckOutScmResult Key: SCM-676 URL: https://jira.codehaus.org/browse/SCM-676 Project: Maven SCM Issue Type: Improvement Components: maven-scm-api, maven-scm-provider-svn Reporter: Petr Kozelka Attachments: SCM-CheckOutScmResultWithRevision.patch It is often useful to get revision number when checking out current state. Attached patch adds this property, and implementation for SVN. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286044#comment-286044
]
Petr Kozelka commented on MNG-5218:
---
@Ondrej:
{quote}
default is "..", and if it's missing, the build fails
{quote}
... not exactly true - if it's missing, Maven resolves it (using parent GAV)
from repo.
You are right that people sometimes make their modules non-isolated, because
sometimes it is so comfortable, much more than doing it via extra artifacts...
but it is not the default.
I always discourage this technique, because it removes one good thing I like
about Maven - strictly and simply expressed build prerequisities.
It also has issues in teams where modules have strict responsibility split (I
change a file in my module and break someone else's module, although the output
artifact is unchanged)
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285955#comment-285955
]
Petr Kozelka commented on MNG-5218:
---
thanks I didn't know ...
still, I believe that using this can lead to much less usable builds, for the
reasons I wrote before.
One more thing I didn't mention before: your suggestion is well defined when
the parent is reachable via relativePath(s).
But that is not always the case. What should "productDistribution" contain in
this case ? Or should it fail ?
In general, I think that the build works best when every module is standalone
and isolated, in the sense that it does not directly access files belonging to
any other module.
Which is - as I guess - opposite of what your suggestion tries to achieve...
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5219) Regression from M2: Installing non-existing artifact is silently ignored
Petr Kozelka created MNG-5219:
-
Summary: Regression from M2: Installing non-existing artifact is
silently ignored
Key: MNG-5219
URL: https://jira.codehaus.org/browse/MNG-5219
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.3, 3.0.4
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /home/kozelka/opt/apache-maven-3.0.3
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "2.6.38-13-generic", arch: "amd64", family: "unix"
Reporter: Petr Kozelka
Attachments: MNG-fail-install-ifnotfound.patch, pom.xml
Maven 2.2.1 used to fail during "install" phase when an attached artifact did
not exist.
This is no longer true with version 3.0.3.
To reproduce the bug, store attached pom.xml into an empty directory and try:
a) maven 2.2.1 - use command "mvn clean install -e" to see the stacktrace:
{noformat}
[INFO] [install:install {execution: default-install}]
[INFO] Installing /TESTDIR/pom.xml to
/LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.pom
[INFO] Installing /TESTDIR/target/nonexistent.nonsense to
/LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.nonsense
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact: File /TESTDIR/target/nonexistent.nonsense
does not exist
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifact: File /TESTDIR/target/nonexistent.nonsense 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(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 /TESTDIR/target/nonexistent.nonsense does not exist
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
Error installing artifact: File /TESTDIR/target/nonexistent.nonsense does not
exist
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:133)
... 19 more
Caused by: java.io.IOException: File /TESTDIR/target/nonexistent.nonsense does
not exist
at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1003)
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:98)
... 20 more
[INFO]
{noformat}
Here, M2 fails, and gives nice explanatory message.
b) maven 3.0.3 - use command "mvn clean install -X" to see the improper message
from aether:
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-install-plugin:2.3.1:install' with basic
configurator -->
[DEBUG] (f)
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285847#comment-285847
]
Petr Kozelka commented on MNG-5218:
---
The incompatibility problem could be avoided by introducing a new property, say
"${invocationdir}".
But then, the submodule pom will get different value when invoked from its own
dir versus when invoked from the project parent dir (or any intermediate).
This makes it too easy to develop poms where submodules can't be built
individually (from their own dirs), and I would prefer not going this direction.
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285387#comment-285387 ] Petr Kozelka commented on SCM-649: -- ... cannot add bazaar component to Jira issue, so I guess next time it's better to make a new one with link here > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-bazaar.patch, scm-richmodel-git.patch, > scm-richmodel-model.patch, scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated SCM-649: - Attachment: scm-richmodel-bazaar.patch Attaching the bazaar patch. > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-bazaar.patch, scm-richmodel-git.patch, > scm-richmodel-model.patch, scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka reopened SCM-649: -- I just implemented simple support of this feature for Bazaar SCM so I hope it's ok to reopen the existing issue. Please let me know if subtasks or any other way is preferred. Bazaar implementation notes: - action "renamed" is supported; this stores *originalFile* but not *originalRevision* because there is no such information in the log - I _manually_ enhanced the changeLogWithMerge.txt file to contain "renamed" section _(taken from my sample bzr repo)_, which is then checked in test > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-git.patch, scm-richmodel-model.patch, > scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285084#comment-285084 ] Petr Kozelka commented on SCM-649: -- Hi Olivier, done, ack forwarded to your @apache mail > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-git.patch, scm-richmodel-model.patch, > scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-650) HgChangeLogConsumer generates phantom 'null' changeset at the end
HgChangeLogConsumer generates phantom 'null' changeset at the end - Key: SCM-650 URL: https://jira.codehaus.org/browse/SCM-650 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.6 Reporter: Petr Kozelka Attachments: scm-hg-revision-null.patch $subject says it all - the phantom changeset has no fields set, revision=null - the fix is trivial, moves adding the changeset to result list to a place where line "changeset:" is already detected -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-46) bad url in jira description
bad url in jira description --- Key: MINDEXER-46 URL: https://jira.codehaus.org/browse/MINDEXER-46 Project: Maven Indexer Issue Type: Bug Reporter: Petr Kozelka Priority: Trivial current url shown at http://jira.codehaus.org/browse/MINDEXER is: http://maven.apache.org/indexer/ (results in Page Not Found) It should be http://maven.apache.org/maven-indexer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-649) Enhance SCM changelog model to hold more data about changes
Enhance SCM changelog model to hold more data about changes --- Key: SCM-649 URL: https://jira.codehaus.org/browse/SCM-649 Project: Maven SCM Issue Type: Improvement Components: maven-scm-api, maven-scm-provider-git, maven-scm-provider-svn Affects Versions: 1.6 Reporter: Petr Kozelka Attachments: scm-richmodel-git.patch, scm-richmodel-model.patch, scm-richmodel-svn.patch Hello, I would like to get more information from SCM changelog command, and attached patches contain my proposal doing some part of this. There are separate patches for model and for GIT and SVN implementations, I hope it makes them easier to review. New functionality is mostly covered with tests. +Summary of proposed enhancements:+ ChangeFile.java: - added: ScmFileStatus *action* - added: String *originalName* - added: String *originalRevision* - they all included in toString() ScmFileStatus.java: - added: *RENAMED* = new ScmFileStatus( "renamed" ); - added: *COPIED* = new ScmFileStatus( "copied" ); ChangeSet.java: - added: String *parentRevision* - added: Set *mergedRevisions* - both added to toString() - both added to toXML() + those from ChangeFile - all values stored in elements not attributes just like the others GIT implementation notes (GitChangeLogConsumer): - besides parsing the "whatchanged" command, now the consumer can handle also many options of the "log" command and harvest most of its provided info. In particular, the output of "git log --format=raw -C --raw --no-abbrev" can be parsed. - there is a potential to simply enable parsing for some more information like committer, committerDate and treeHash, which I didn't yet (as GIT-only stuff it may require separate discussion) SVN implementation notes (SvnChangeLogConsumer): - svn action "A" (Add) translates to "added" or "copied" depending of presence of originalFile - svn action "M" (Modified) always translates to "modified" no matter if there is an originalFile; _any opinions about this ?_ - svn action "R" (Replace) translates to "updated" which IMHO has sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-647) SvnChangeLogConsumer parses filename incorrectly when file is copied from existing one
SvnChangeLogConsumer parses filename incorrectly when file is copied from
existing one
--
Key: SCM-647
URL: https://jira.codehaus.org/browse/SCM-647
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.5, 1.6
Reporter: Petr Kozelka
Attachments: scm-svn-origfile.patch
Current implementations uses non-xml svn log for gathering information. It
always returns everything after 5th char as the filename, which is a bug in
cases like this:
{quote} A
/maven/scm/trunk/maven-scm-test/src/main/java/org/apache/maven/scm/ScmTestCase.java
(from
/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmTestCase.java:191665){quote}
which indicate copying a path from existing revision.
Note that this example was taken from the [svnlog2.txt line
510|https://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/test/resources/svn/changelog/svnlog2.txt?view=markup#l510]
file in test resources.
I suggest to fix it with the attached patch. It also enhances tests to assert
that the parsed filenames are correct - not containing spaces and beginning
with common path.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-541) GitExe commit should include --allow-empty option
[ https://jira.codehaus.org/browse/SCM-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283877#comment-283877 ] Petr Kozelka commented on SCM-541: -- Hello Kathryn, I just tested your suggested option - see https://github.com/pkozelka/git-demo/commit/8bc7b72317b3e5d80fa8fdfa3a692ddc211a8620 It shows that it causes git to *create an empty commit* , but that is not a no-op and I believe it should not be used. Instead, I think the output should be parsed for string "nothing to commit (working directory clean)" when git fails and used for the no-op case. > GitExe commit should include --allow-empty option > - > > Key: SCM-541 > URL: https://jira.codehaus.org/browse/SCM-541 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Reporter: Kathryn Huxtable >Priority: Minor > > Without it, git returns a status of 1 when there is nothing to commit. This > makes the wagon-scm and other processes that depend on this being a no-op > fail. > I think that git should not fail on an empty commit, and adding the > --allow-empty option on commits would achieve that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-646) git parser should fill changeset revision
git parser should fill changeset revision - Key: SCM-646 URL: https://jira.codehaus.org/browse/SCM-646 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.5 Reporter: Petr Kozelka Attachments: SCM-git-changeset-revision.patch Current implementation of GitChangeLogConsumer fills revision on each ChangeFile but not on its containing ChangeSet - where it IMHO naturally belongs. I fixed this on GitHub and submitted a pull request here: https://github.com/apache/maven-scm/pull/1 I guess that Apache does not process Github pull-requests yet so I am attaching the patch also here. In this patch, also unittest is extended to cover checking changeset revision as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[ https://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275550#comment-275550 ] Petr Kozelka commented on MENFORCER-98: --- on Maven 3.0.3, requirePluginVersions is still not working. Is there any better way to reach the functionality ? Is Jeff's patch considered wrong ? Just to remind, https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution states that it can be used to check for missing plugin versions in the POM. Right now that statement is false. > requirePluginVersions rule is not compatible with maven 3.0-beta-1 > -- > > Key: MENFORCER-98 > URL: https://jira.codehaus.org/browse/MENFORCER-98 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-1 > Environment: Windows XP > Sun JDK 1.6.0_18 > Maven 3.0-beta-1 >Reporter: Anders Hammar > Attachments: MENFORCER-98.patch > > > When using the requirePluginVersions rule, I get a message saying "This rule > is not compatible with the current version of Maven. The rule is not able to > perform any checks." -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MINSTALL-78) install:install should remove leftovers from local repository
[
http://jira.codehaus.org/browse/MINSTALL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka reopened MINSTALL-78:
--
You are right that I can configure some sort of explicit purging at
buildserver; but this issue mainly affects simple configurations without one.
Even in a big team: people who want to make a build *before* commit, trying to
avoid failure at CI build, are affected too. I am often explaining developers
from my team why the build nicely passing on their local machine fails on CI
server, and would be happy if one of the most frequent reasons could be
eliminated
IMHO the case when you need to just "update" repo is very infrequent.
What about to make this functionality controlled by an option? Then, I can
control this by corporate pom, and explicitly turn on "update" behavior for the
few modules that need it.
I can create a patch for this; please let me know if it sounds like acceptable
way.
> install:install should remove leftovers from local repository
> -
>
> Key: MINSTALL-78
> URL: http://jira.codehaus.org/browse/MINSTALL-78
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.3.1
>Reporter: Petr Kozelka
>Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> It sometimes happens that we need to change the set of output artifacts. When
> this happens, the install mojo does not bother to remove older artifacts that
> are no longer produced by this module.
> The bad effect is, that other modules depending on the obsolete artifacts can
> still use it - and later there comes a surprise.
> Much better behavior in this situation would be, to remove the obsolete files
> from the local repository's directory dedicated for given module.
> h4. reproducing the problem
> # download the sample pom to an empty directory
> # execute {{mvn clean install -Dc=obsolete-demo}} - this represents the
> "older version" of a module
> # execute {{mvn clean install}} - this represents the "newer version" of a
> module, after changing the classifier
> # now, look in the local repo using {{ls -1
> $HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
> {quote}
> maven-metadata-local.xml
> sample-zip-module-1-SNAPSHOT-demo.zip
> {color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
> sample-zip-module-1-SNAPSHOT.pom
> {quote}
> h4. possible solutions
> I see two approaches
> # *drop the installdir first* - straightforward
> # *list installdir, install, drop leftovers* - slightly more complicated but
> maximizes the time of installed module existence (if that matters)
--
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: (MANTRUN-151) provide a property always pointing to the currently effective local repository
[
http://jira.codehaus.org/browse/MANTRUN-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka closed MANTRUN-151.
Resolution: Fixed
Fix Version/s: 1.5
seems that version 1.5 uses {{settings.localRepository}} property for this
purpose
> provide a property always pointing to the currently effective local repository
> --
>
> Key: MANTRUN-151
> URL: http://jira.codehaus.org/browse/MANTRUN-151
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.3, 1.4
>Reporter: Petr Kozelka
> Fix For: 1.5
>
>
> Right now, there are at least 3 ways to define where local repository resides:
> 1) the default, ${user.home}/.m2/repository
> 2) settings.xml under /settings/localRepository
> 3) commandline property "maven.repo.local"
> Unfortunately, when writing ant fragments that need to access the local
> repository directly, there is no way to get effective local repo in all these
> cases.
> - I cannot use ant property "maven.repo.local" because it is only set if the
> corresponding maven prop.(3) is set
> - even adding fallback to default (1) still does not cover the case (2)
> I suggest introducing something like "settings.localRepository.file" which
> would always give me the right path
--
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: (MANTRUN-153) install:install should remove leftovers from local repository
[
http://jira.codehaus.org/browse/MANTRUN-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka closed MANTRUN-153.
Resolution: Won't Fix
> install:install should remove leftovers from local repository
> -
>
> Key: MANTRUN-153
> URL: http://jira.codehaus.org/browse/MANTRUN-153
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Petr Kozelka
> Attachments: pom.xml
>
>
> It happens that we need to change the set of output artifacts. When this
> happens, the install mojo does not bother to remove older artifacts that are
> no longer produced by this module.
> The bad effect is, that other modules depending on the obsolete artifacts can
> still use it. Much better behavior in this situation would be, to remove the
> obsolete files from the local repository's directory dedicated for given
> module.
> h4. reproducing the problem
> # download the sample pom to an empty directory
> # execute {{mvn clean install -Dc=obsolete-demo}} - this represents the
> "older version" of a module
> # execute {{mvn clean install}} - this represents the "newer version" of a
> module, after changing the classifier
> # now, look in the local repo using {{ls -1
> $HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
> {quote}
> maven-metadata-local.xml
> sample-zip-module-1-SNAPSHOT-demo.zip
> {color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
> sample-zip-module-1-SNAPSHOT.pom
> {quote}
> h4. possible solutions
> I see two approaches
> # *drop the installdir first* - straightforward
> # *list installdir, install, drop leftovers* - slightly more complicated but
> maximizes the time of installed module existence
--
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: (MINSTALL-78) install:install should remove leftovers from local repository
install:install should remove leftovers from local repository
-
Key: MINSTALL-78
URL: http://jira.codehaus.org/browse/MINSTALL-78
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.3.1
Reporter: Petr Kozelka
Attachments: pom.xml
It sometimes happens that we need to change the set of output artifacts. When
this happens, the install mojo does not bother to remove older artifacts that
are no longer produced by this module.
The bad effect is, that other modules depending on the obsolete artifacts can
still use it - and later there comes a surprise.
Much better behavior in this situation would be, to remove the obsolete files
from the local repository's directory dedicated for given module.
h4. reproducing the problem
# download the sample pom to an empty directory
# execute {{mvn clean install -Dc=obsolete-demo}} - this represents the "older
version" of a module
# execute {{mvn clean install}} - this represents the "newer version" of a
module, after changing the classifier
# now, look in the local repo using {{ls -1
$HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
{quote}
maven-metadata-local.xml
sample-zip-module-1-SNAPSHOT-demo.zip
{color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
sample-zip-module-1-SNAPSHOT.pom
{quote}
h4. possible solutions
I see two approaches
# *drop the installdir first* - straightforward
# *list installdir, install, drop leftovers* - slightly more complicated but
maximizes the time of installed module existence (if that matters)
--
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: (MANTRUN-153) install:install should remove leftovers from local repository
install:install should remove leftovers from local repository
-
Key: MANTRUN-153
URL: http://jira.codehaus.org/browse/MANTRUN-153
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Petr Kozelka
Attachments: pom.xml
It happens that we need to change the set of output artifacts. When this
happens, the install mojo does not bother to remove older artifacts that are no
longer produced by this module.
The bad effect is, that other modules depending on the obsolete artifacts can
still use it. Much better behavior in this situation would be, to remove the
obsolete files from the local repository's directory dedicated for given module.
h4. reproducing the problem
# download the sample pom to an empty directory
# execute {{mvn clean install -Dc=obsolete-demo}} - this represents the "older
version" of a module
# execute {{mvn clean install}} - this represents the "newer version" of a
module, after changing the classifier
# now, look in the local repo using {{ls -1
$HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
{quote}
maven-metadata-local.xml
sample-zip-module-1-SNAPSHOT-demo.zip
{color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
sample-zip-module-1-SNAPSHOT.pom
{quote}
h4. possible solutions
I see two approaches
# *drop the installdir first* - straightforward
# *list installdir, install, drop leftovers* - slightly more complicated but
maximizes the time of installed module existence
--
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-66) The plugin should only install attached artifacts to the project if they have a classifier
[ http://jira.codehaus.org/browse/MINSTALL-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236288#action_236288 ] Petr Kozelka commented on MINSTALL-66: -- in my company we use attached artifacts without classifier for: - ZIP modules - the result of build is packaged as ZIP and there is no other "primary" artifact - ISO modules - the final product is packaged as ISO (=iso9660) - complete result ready to be burned Yes, I can invent a string to use as the classifier; but ... why ? On the other hand, I do not understand why attached artifacts without classifier should be ignored, as Bruno suggests. That would completely break my use cases :( > The plugin should only install attached artifacts to the project if they have > a classifier > -- > > Key: MINSTALL-66 > URL: http://jira.codehaus.org/browse/MINSTALL-66 > Project: Maven 2.x Install Plugin > Issue Type: Improvement > Components: install:install >Affects Versions: 2.3 >Reporter: Bruno Duarte >Priority: Minor > > When running in the lifecycle of a project, the plugin installs attached > artifacts that don't have a classifier and overrides the file of the default > one. > Ideally the plugin should ignore attached artifacts that don't have a > classifier associated and should write a warning about the ones that is > unable to install. -- 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: (MANTRUN-152) Embedded task "attachartifact" does not work without classifier
Embedded task "attachartifact" does not work without classifier
---
Key: MANTRUN-152
URL: http://jira.codehaus.org/browse/MANTRUN-152
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.5, 1.4, 1.3
Environment: Java 5, Maven 2.2.1
Reporter: Petr Kozelka
Attachments: MANTRUN-attachartifact-unclassified.patch
cause: use this task without specifying classifier attribute
symptom: your file will not be copied to local repo during install phase
h4. the bug
The reason apparently is that this case has special handling in
AttachArtifactTask.java, and this handling has following problems:
- uses {{mavenProject.getArtifact().setFile( file );}} which apparently does
not result in the artifact being considered the project artifact, neither being
attached
- even if it worked, this implementation would not work for multiple
unclassified artifacts (the latest would always win)
- the name "attachartifact" implies attaching, not declaring project artifact
h4. a workarround
Before this gets fixed, the workarround is to use
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html as
a subsequent mojo execution
h4. the fix, patch contents
The attached patch includes:
# fix in code that just removes the conditionality for {{classifier==null}}
-- _compatibility is IMHO not a problem, because this part was not working
anyway_
# integration test enhancement - to check the attachartifact functionality
without classifier
To see the incorrect behavior, just use the pom from integration test
{{src/it/attach-artifact-test/pom.xml}} and remove the classifier artifact; the
build log of that test will then show that the zip is really not copied by
install mojo.
h4. attached vs. Project artifact
Concerning the (nonfunctional) attempt to declare the file as project artifact:
IMHO it is not a good thing at all.
Even if the abovementioned problem with overriding was solved, I would expect
the task to do what its name indicates, and nothing else.
Well, I am not aware of any important differences between having project
artifact and having the same artifact as attached (I should read something
about it...), but in any case, I would prefer to have some control over this
different behavior.
For instance, adding attribute {{projectArtifact="true"}} can indicate that
setting project artifact is the desired action.
Another approach, maybe even cleaner, would be to define a separate task (or
better, configuration param) just for this purpose.
h4. thoughts on merging build-helper approach
What I really like about the embedded attachartifact task is, I don't need to
*invoke separate mojo* (build-helper:attach-artifact).
For me, creating something with ant piece and attaching it to project is the
most common usecase of antrun plugin.
Therefore I have the feeling that it should be treated specially - I mean, the
way used in build-helper:attach-artifact mojo.
Really, the "attaching" action is something different from normal tasks; it
does not "do" anything visible to subsequent tasks, just enhances the internal
declaration of the project... but we have POM for such things, right ?
So, wouldn't it be better to *copy the functionality of
build-helper:attach-artifact here ?* Perhaps the anttask attachartifact should
still exist, for some rare cases like conditional/parameterized attachments;
but the preferred way would be the (declarative) "maven" way - maybe this is
worth separate issue.
--
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: (MANTRUN-151) provide a property always pointing to the currently effective local repository
provide a property always pointing to the currently effective local repository
--
Key: MANTRUN-151
URL: http://jira.codehaus.org/browse/MANTRUN-151
Project: Maven 2.x Antrun Plugin
Issue Type: New Feature
Affects Versions: 1.4, 1.3
Reporter: Petr Kozelka
Right now, there are at least 3 ways to define where local repository resides:
1) the default, ${user.home}/.m2/repository
2) settings.xml under /settings/localRepository
3) commandline property "maven.repo.local"
Unfortunately, when writing ant fragments that need to access the local
repository directly, there is no way to get effective local repo in all these
cases.
- I cannot use ant property "maven.repo.local" because it is only set if the
corresponding maven prop.(3) is set
- even adding fallback to default (1) still does not cover the case (2)
I suggest introducing something like "settings.localRepository.file" which
would always give me the right path
--
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: (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[
http://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234740#action_234740
]
Petr Kozelka commented on MENFORCER-98:
---
with Maven 3.0-beta-3 it does not check again
{noformat}
...
[INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-plugin-versions) @
systinet-pom ---
[WARNING] This rule is not compatible with the current version of Maven. The
rule is not able to perform any checks.
...
{noformat}
> requirePluginVersions rule is not compatible with maven 3.0-beta-1
> --
>
> Key: MENFORCER-98
> URL: http://jira.codehaus.org/browse/MENFORCER-98
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0-beta-1
> Environment: Windows XP
> Sun JDK 1.6.0_18
> Maven 3.0-beta-1
>Reporter: Anders Hammar
>
> When using the requirePluginVersions rule, I get a message saying "This rule
> is not compatible with the current version of Maven. The rule is not able to
> perform any checks."
--
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: (MRELEASE-526) release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232662#action_232662
]
Petr Kozelka commented on MRELEASE-526:
---
same problem here; I observe it only on multimodule projects, and not strictly
always - which seems to be confirming the explanation above
> release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of
> project/trunk
> ---
>
> Key: MRELEASE-526
> URL: http://jira.codehaus.org/browse/MRELEASE-526
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Damien Coraboeuf
>Priority: Critical
> Fix For: 2.1
>
> Attachments: export.zip
>
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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: (DOXIA-401) doxia-module-twiki has no syntax for using macros
doxia-module-twiki has no syntax for using macros - Key: DOXIA-401 URL: http://jira.codehaus.org/browse/DOXIA-401 Project: Maven Doxia Issue Type: Bug Components: Module - Twiki Affects Versions: 1.1.3 Environment: Maven 2.2.1 Reporter: Petr Kozelka There is no way to use doxia macros, like "snippet" or "toc". I found a discussion where Abhijit Bagri offers his enhancements, but apparently it didn't get to doxia: http://maven.40175.n5.nabble.com/Twiki-Module-Enhancements-td327348.html#a327348 Are there any plans in this area, or at least, is Abhijit's code available ? -- 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-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
release:prepare does not pass argument "--settings" with current settings.xml to inner maven Key: MRELEASE-577 URL: http://jira.codehaus.org/browse/MRELEASE-577 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0, 2.0-beta-9 Reporter: Petr Kozelka Priority: Critical The impact is that release:prepare tries to use $HOME/.m2/settings.xml instead of the one supplied by --settings cmdline option, which leads to unexpected behavior Of course if it does not exist, the inhouse repository is avoided and release often fails due to a ResourceDoesNotExistException when an inhouse artifact is requested by the pom. To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml and run this: mvn --settings=$HOME/.m2/s.xml release:prepare . -- 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: (MANTRUN-127) provide more tracking info when a task fails
provide more tracking info when a task fails Key: MANTRUN-127 URL: http://jira.codehaus.org/browse/MANTRUN-127 Project: Maven 2.x Antrun Plugin Issue Type: Improvement Reporter: Petr Kozelka Priority: Minor - task name - pom line number - or at least, line number in the tasks part This might make finding out a problem much faster -- 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: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.
[
http://jira.codehaus.org/browse/DOXIA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202077#action_202077
]
Petr Kozelka commented on DOXIA-68:
---
I wonder if there is a way to make twiki working against released versions. I
tried this:
{code}
...
org.apache.maven.plugins
maven-project-info-reports-plugin
2.1.2
org.apache.maven.doxia
doxia-module-twiki
1.1.2
...
{code}
but got following error:
{code}
...
this realm = plexus.core
urls[0] = file:/home/pk/opt/maven/lib/maven-2.2.1-uber.jar
Number of imports: 10
import: org.codehaus.classworlds.en...@a6c57a42
import: org.codehaus.classworlds.en...@12f43f3b
import: org.codehaus.classworlds.en...@20025374
import: org.codehaus.classworlds.en...@f8e44ca4
import: org.codehaus.classworlds.en...@92758522
import: org.codehaus.classworlds.en...@ebf2705b
import: org.codehaus.classworlds.en...@bb25e54
import: org.codehaus.classworlds.en...@bece5185
import: org.codehaus.classworlds.en...@3fee8e37
import: org.codehaus.classworlds.en...@3fee19d8
-
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error getting reports from the plugin
'org.apache.maven.plugins:maven-project-info-reports-plugin:2.1.2': Unable to
find the mojo 'project-team' (or one of its required components) in the plugin
'org.apache.maven.plugins:maven-project-info-reports-plugin'
org.apache.maven.doxia.module.site.AbstractSiteModule.(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
...
{code}
It seems that adding the dependency impacts dependency graph for the plugin
classpath somehow. Is there any better version to use ?
> Adding twiki plugin as build extension makes goal site:site fail.
> -
>
> Key: DOXIA-68
> URL: http://jira.codehaus.org/browse/DOXIA-68
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Twiki
>Affects Versions: 1.0-alpha-8
> Environment: WinXp, Java5
>Reporter: Martin Zeltner
>Assignee: Lukas Theussl
>
> When I add the twiki module as an extension in my pom.xml the goal site:site
> will fail.
> Extension config snippet:
> --
>
>
>
>
> doxia-module-twiki
> org.apache.maven.doxia
> 1.0-alpha-9-SNAPSHOT
>
>
>
> --
> Console output:
> --
> mvn site:site -X
> + Error stacktraces are turned on.
> Maven version: 2.1-SNAPSHOT
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'site'.
> [INFO]
>
> [INFO] Building EL4J module core
> [INFO]task-segment: [site:site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro :
[jira] Created: (MNG-4481) store snapshots in separate local repository
store snapshots in separate local repository
Key: MNG-4481
URL: http://jira.codehaus.org/browse/MNG-4481
Project: Maven 2
Issue Type: New Feature
Components: Artifacts and Repositories, Settings
Environment: Maven 3
Reporter: Petr Kozelka
This feature could be activated by an option in settings, for instance:
{code:xml}
${user.home}/.m2/snapshots
...
{code}
This gives developer more control over snapshots which he typically produces
during build.
One simple usecase is: drop all snapshots and make clean build (no ancient
snapshot dependencies will bass) - useful especially after changing module
identification.
--
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: (MRELEASE-317) release:prepare should fail if any pom depends on SNAPSHOT parent
[ http://jira.codehaus.org/browse/MRELEASE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174620#action_174620 ] Petr Kozelka commented on MRELEASE-317: --- In the meantime I started to use much better approach - the whole release runs from within a specialized launcher that makes it use dedicated empty local repository and settings.xml etc. This is far much safer, because the release-specific settings.xml file mirrors all requests to a nexus group that only has access to release repositories => it may never happen that a SNAPSHOT gets anywhere into release. It also allows me to place other restrictions so that the release reproducibility is as high as possible. Now the release is slower (not important), but very very safe. > release:prepare should fail if any pom depends on SNAPSHOT parent > - > > Key: MRELEASE-317 > URL: http://jira.codehaus.org/browse/MRELEASE-317 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare > Environment: maven-2.0.8 > java-1.6 >Reporter: Petr Kozelka >Priority: Critical > Attachments: MRELEASE-317.patch.txt > > > Currently the release plugin happily releases a pom that declares a SNAPSHOT > version of parent. > Such a release is exposed to a danger of irreproducibility: > 1.) on another machine > 2.) at another time (parent may significantly change in the meantime) > While it can be sometimes convenient, it is, as I am quite sure, a bad > behavior. -- 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: (MENFORCER-62) requirePluginVesions: avoid checking commandline-invoked mojos
requirePluginVesions: avoid checking commandline-invoked mojos
--
Key: MENFORCER-62
URL: http://jira.codehaus.org/browse/MENFORCER-62
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-alpha-4
Environment: Maven 2.0.8, 2.0.9
Linux,Windows
Reporter: Petr Kozelka
Locking plugin versions affects also mojos invoked from commandline, which is
typically undesired.
Besides that, such mojos cannot be even invoked with fully qualified name.
I am using following configuration in our corporate pom, to enforce that all
plugin versions are explicitly declared so that builds are reproducible:
{noformat}
...
ERROR: Please always define plugin
versions.
true
true
false
false
clean,deploy,install
...
{noformat}
With this config, I cannot use commandline mojos that are not mentioned with
exact version.
One such case is {{mvn idea:idea}} which ends with enforcer failure.
*Even worse*: in this case I have {color:red}no chance to invoke{color} that
mojo even with full qualifier - it fails as if I didn't specify version (maybe
this part is a bug in different component):
{noformat}
mvn org.apache.maven.plugins:maven-idea-plugin:2.2:idea
{noformat}
I can theoretically add something like this to the corporate pom, and it really
helps:
{noformat}
...
org.apache.maven.plugins:maven-idea-plugin
...
{noformat}
However, this approach is generally unusable, as it requires re-releasing of
all modules descending from that pom - which is never desired and rarely
possible.
h3. A semi-solution idea:
This might be difficult to fix - but if the list of unchecked plugins was
somehow externalizable, it would solve my urgent need.
For instance, add option {{unCheckedPluginList}} containing comma separated
items - then I can reference a property defined in {{settings.xml}} from there.
That would work for me, because settings are not subject to releasing:
{noformat}
...
${my.unchecked.plugins}
...
{noformat}
--
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: (MWAR-181) warSourceExcludes does not work in 2.1-alpha-2
warSourceExcludes does not work in 2.1-alpha-2
--
Key: MWAR-181
URL: http://jira.codehaus.org/browse/MWAR-181
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: Petr Kozelka
Priority: Critical
we use following configuration to produce jar-less war artifacts, in order to
embed them to EAR:
{{WEB-INF/lib/*.jar}}
This does not work with release 2.1-alpha-2.
Switching to 2.1-alpha-1 solves the problem.
--
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: (MRELEASE-394) Support for SCM update after each commit
[ http://jira.codehaus.org/browse/MRELEASE-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156876#action_156876 ] Petr Kozelka commented on MRELEASE-394: --- I just confirm that the same happens to me too, observed since 12.11.2008 - but only on multimodule releases. For some strange reason, releasing single modules works fine. My svn client is version 1.5.4, running against SVN repositories at sourceforge.net and assembla com. Using maven-2.0.9, java-1.6.0_10, Gentoo Linux on x86. > Support for SCM update after each commit > > > Key: MRELEASE-394 > URL: http://jira.codehaus.org/browse/MRELEASE-394 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.0-beta-8 > Environment: Windows Vista SP1 + JDK 1.5 + Mvn 2.0.9 and > Ubuntu 8.04 Server + JDK 1.5 + Mvn 2.0.8 >Reporter: rahul somasunderam > > I have a multi module project and currently I have to do > >>svn co http://svnrepo/project/trunk > >>mvn release:prepare > At this stage it fails > >>svn up > >>mvn release:prepare > Now it is complete. > It would be good to have a hook to get the svn update to happen after each > svn commit performed by the release 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] Commented: (MSITE-224) [PATCH] please make UTF-8 the default encoding
[ http://jira.codehaus.org/browse/MSITE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129810#action_129810 ] Petr Kozelka commented on MSITE-224: That's true for input encoding. However, for output encoding, each xml file has its own XML declaration with encoding optionally specified. And when it is specified, it should be respected, otherwise it is a bug. But respecting XML encoding is possible only if you can convert any text from its content into the output encoding. So in my opinion, the best solution is that the functionality fails when it encounters any character that cannot be converted this way, but it might be much harder to implement. While switching (at least) the default output encoding to UTF8 is easy and would be very helpful and produces no compatibility issues I believe. > [PATCH] please make UTF-8 the default encoding > -- > > Key: MSITE-224 > URL: http://jira.codehaus.org/browse/MSITE-224 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: encoding > Environment: Gentoo Linux, UTF-8 encoded pom files >Reporter: Petr Kozelka >Priority: Minor > Attachments: site-plugin-UTF8-encoding.patch > > > UTF-8 is already widely supported and used by tools, there is hardly a reason > to keep with ISO-8859-1 found through the code. > In my usecases, it typically makes troubles with developer names containing > accented letters. > Attached patch changes the default input and output encoding in > maven-site-plugin which is the most important piece. -- 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: (MRELEASE-51) release:perform could update the date attribute in the changes.xml
[ http://jira.codehaus.org/browse/MRELEASE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120396 ] Petr Kozelka commented on MRELEASE-51: -- may I suggest that the date be in the xs:dateTime format ? I mean _including_ the time part. My experience shows that sometimes it happens that you need to re-release something the same day. I know it is not the best thing under sun but it just happens that you discover an omission or whatever right after the release is published. > release:perform could update the date attribute in the changes.xml > --- > > Key: MRELEASE-51 > URL: http://jira.codehaus.org/browse/MRELEASE-51 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Priority: Minor > > Could the release:perform made a simple update with the date in changes.xml > as maven do. -- 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: (MRELEASE-317) release:prepare should fail if any pom depends on SNAPSHOT parent
[ http://jira.codehaus.org/browse/MRELEASE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119776 ] Petr Kozelka commented on MRELEASE-317: --- More info: the target usecase is that parent pom is released as a separate project. > release:prepare should fail if any pom depends on SNAPSHOT parent > - > > Key: MRELEASE-317 > URL: http://jira.codehaus.org/browse/MRELEASE-317 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: maven-2.0.8 > java-1.6 >Reporter: Petr Kozelka >Priority: Critical > > Currently the release plugin happily releases a pom that declares a SNAPSHOT > version of parent. > Such a release is exposed to a danger of irreproducibility: > 1.) on another machine > 2.) at another time (parent may significantly change in the meantime) > While it can be sometimes convenient, it is, as I am quite sure, a bad > behavior. -- 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-317) release:prepare should fail if any pom depends on SNAPSHOT parent
release:prepare should fail if any pom depends on SNAPSHOT parent - Key: MRELEASE-317 URL: http://jira.codehaus.org/browse/MRELEASE-317 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: maven-2.0.8 java-1.6 Reporter: Petr Kozelka Priority: Critical Currently the release plugin happily releases a pom that declares a SNAPSHOT version of parent. Such a release is exposed to a danger of irreproducibility: 1.) on another machine 2.) at another time (parent may significantly change in the meantime) While it can be sometimes convenient, it is, as I am quite sure, a bad behavior. -- 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: (MAVENUPLOAD-1895) Sync net.sf.buildbox repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated MAVENUPLOAD-1895: -- Attachment: net.sf.buildbox.sh > Sync net.sf.buildbox repository > --- > > Key: MAVENUPLOAD-1895 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1895 > Project: maven-upload-requests > Issue Type: Task >Reporter: Petr Kozelka > Attachments: net.sf.buildbox.sh > > > Please synchronize http://buildbox.sourceforge.net/maven2 repository to the > central maven repository. > As a proof that I own the project at sourceforge, I created this page: > http://buildbox.sourceforge.net/maintainers.html -- 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: (MAVENUPLOAD-1895) Sync net.sf.buildbox repository
Sync net.sf.buildbox repository --- Key: MAVENUPLOAD-1895 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1895 Project: maven-upload-requests Issue Type: Task Reporter: Petr Kozelka Please synchronize http://buildbox.sourceforge.net/maven2 repository to the central maven repository. As a proof that I own the project at sourceforge, I created this page: http://buildbox.sourceforge.net/maintainers.html -- 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: (MRELEASE-154) mvn release:perform does not inherit command line variable
[ http://jira.codehaus.org/browse/MRELEASE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118961 ] Petr Kozelka commented on MRELEASE-154: --- This problem also happens for other commandline arguments, like --settings. Therefore I cannot use specialized settings.xml for releases :( It would be really nice to avoid calling maven from its plugin. At least not as separate JVM. > mvn release:perform does not inherit command line variable > -- > > Key: MRELEASE-154 > URL: http://jira.codehaus.org/browse/MRELEASE-154 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Michael Semb Wever >Priority: Critical > > When I deploy i must add -Duser.name=mickw to ensure scpexe logins in with > the correct username. > eg mvn deploy -Duser.name=mick > But when I run "mvn release:perform" scpexe fails when it forks the sub > process: > mvn deploy site-deploy --no-plugin-updates -P null,null -DperformRelease=true > and it's missing the -Duser.name=mickw variable. > I need some way of setting the user.name property to make it possible to run > 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] Commented: (MNG-2917) Ant classpath issue in maven 2.0.6
[ http://jira.codehaus.org/browse/MNG-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106543 ] Petr Kozelka commented on MNG-2917: --- I just want to confirm that this really helped to me too. In particular, adding the explicit ant-1.6.5 dependency made the difference. There must be some magic, because the maven-antrun-plugin, used by xdoclet-maven-plugin, itself depends on ant-1.6.5, but I didn't bother to explore it deeper. > Ant classpath issue in maven 2.0.6 > -- > > Key: MNG-2917 > URL: http://jira.codehaus.org/browse/MNG-2917 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Yuri Schimke >Priority: Critical > > This was working in 2.0.5. Unfortunately I'm guessing its related to the > woefully bad xdoclet-maven-plugin > The main error is that the xdoclet-maven-plugin can't find one of the ant > classes > Caused by: java.lang.NoClassDefFoundError: org/apache/tools/ant/PropertyHelper > - > this realm = app0.child-container[org.codehaus.mojo:xdoclet-maven-plugin] > urls[0] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/codehaus/mojo/xdoclet-maven-plugin/1.0-alpha-2/xdoclet-maven-plugin-1.0-alpha-2.jar > urls[1] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-wsee-module/1.2.3/xdoclet-wsee-module-1.2.3.jar > urls[2] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > urls[3] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jboss-module/1.2.3/xdoclet-jboss-module-1.2.3.jar > urls[4] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-xdoclet-module/1.2.3/xdoclet-xdoclet-module-1.2.3.jar > urls[5] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-orion-module/1.2.3/xdoclet-orion-module-1.2.3.jar > urls[6] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jmx-module/1.2.3/xdoclet-jmx-module-1.2.3.jar > urls[7] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-ibm-module/1.2.3/xdoclet-ibm-module-1.2.3.jar > urls[8] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[9] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-collections/commons-collections/2.1/commons-collections-2.1.jar > urls[10] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant/1.5.2/ant-1.5.2.jar > urls[11] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-apache-module/1.2.3/xdoclet-apache-module-1.2.3.jar > urls[12] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant-launcher/1.6.5/ant-l > auncher-1.6.5.jar > urls[13] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-fr_FR-locale/1.2.3/xdoclet-fr_FR-locale-1.2.3.jar > urls[14] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-objectweb-module/1.2.3/xdoclet-objectweb-module-1.2.3.jar > urls[15] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.0/maven-antrun-plugin-1.0.jar > urls[16] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-java-module/1.2.3/xdoclet-java-module-1.2.3.jar > urls[17] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-exolab-module/1.2.3/xdoclet-exolab-module-1.2.3.jar > urls[18] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-bea-module/1.2.3/xdoclet-bea-module-1.2.3.jar > urls[19] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-mvcsoft-module/1.2.3/xdoclet-mvcsoft-module-1.2.3.jar > urls[20] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-sun-module/1.2.3/xdoclet-sun-module-1.2.3.jar > urls[21] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-spring-module/1.2.3/xdoclet-spring-module-1.2.3.jar > urls[22] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-de-locale/1.2.3/xdoclet-de-locale-1.2.3.jar > urls[23] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/jboss/jboss-j2ee/3.2.1/jboss-j2ee-3.2.1.jar > urls[24] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar > urls[25] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-web-module/1.2.3/xdoclet-web-module-1.2.3.jar > urls[26] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-caucho-module/1.2.3/xdoclet-caucho-module-1.2.3.jar > urls[27] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jdo-module/1.2.3/xdoclet-jdo-module-1.2.3.jar > urls[28] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-tjdo-module/1.2.3/xdoclet-tjdo-module-1.2.3.jar > urls[29] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[30] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-openejb-module/1.2.3/xdoclet-openejb-module-1.2.3.jar > urls[31] = > file:/C:/Docume~1/nbk7xsp/.m2/rep
[jira] Commented: (MNG-2808) Anchors on maven.apache.org are broken
[ http://jira.codehaus.org/browse/MNG-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105622 ] Petr Kozelka commented on MNG-2808: --- now it seems to be fixed, as far as I could check > Anchors on maven.apache.org are broken > -- > > Key: MNG-2808 > URL: http://jira.codehaus.org/browse/MNG-2808 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting > Environment: Both Firefox 2 and IE 7.0 >Reporter: Alexander Dotor >Priority: Minor > Fix For: Reviewed Pending Version Assignment > > > The anchors for on-page-navigation on maven.apache.org are broken. The > href-attrivbute contains uppercase letters at the beginning and blanks > between words. The name-Attribute of the appropriate anchors is in lowercase > and containts underscores instead of blanks. > This makes it extremly difficult to navigate the POM-Reference for 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] Created: (MNG-3164) Enable plugin configuration in settings.xml
Enable plugin configuration in settings.xml --- Key: MNG-3164 URL: http://jira.codehaus.org/browse/MNG-3164 Project: Maven 2 Issue Type: New Feature Components: Settings Reporter: Petr Kozelka Currently there is no way to correctly persist user-specific configuration of plugins. There are many plugins, that do not affect the build process, and should therefore NOT be configured in pom.xml (and versioned and released etc). This is most annoying with IDE integration plugins. In a team, some developers use IDEA, some Eclipse, some Netbeans or anything else. It is apparently a nonsense to preconfigure anything about IDEA in pom.xml and commit it to the repository, because others either do not care or perhaps want different settings. Ideally, it should be part of profile section. And to make the things really correct, each plugin (or even parameter?) should specify whether it can be configured in pom only, in settings only, or in both; one of these options might be used as the default. This feature will greatly improve the pom's reputation of being a project descriptor, instead of being one user's setup. -- 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: (MWAR-108) parameter "archive" not respected - no way to influence MANIFEST.MF
[
http://jira.codehaus.org/browse/MWAR-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka closed MWAR-108.
-
Resolution: Fixed
oops... I actually edited different POM which of course had no impact on
observed war :-)
In fact, the "archive" parameter influences both the WAR's MANIFEST.MF, and the
one in JAR created from archived classes.
This probably is not the right thing anyway, but definitely a different
bugreport.
> parameter "archive" not respected - no way to influence MANIFEST.MF
> ---
>
> Key: MWAR-108
> URL: http://jira.codehaus.org/browse/MWAR-108
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Petr Kozelka
>
> There seems to be no way to influence the war's MANIFEST.MF . At least the
> expected way is not working:
> {quote}
> ...
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
> {color:red}
>
> true
>
> true
>
>
> ${artifactId}
>
> {color}
>
>
>
> ...
> {quote}
> This configuration does not change anything in the resulting
> {{xyz.war!/META-INF/MANIFEST.MF}}
--
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: (MWAR-108) parameter "archive" not respected - no way to influence MANIFEST.MF
parameter "archive" not respected - no way to influence MANIFEST.MF
---
Key: MWAR-108
URL: http://jira.codehaus.org/browse/MWAR-108
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Petr Kozelka
There seems to be no way to influence the war's MANIFEST.MF . At least the
expected way is not working:
{quote}
...
org.apache.maven.plugins
maven-war-plugin
{color:red}
true
true
${artifactId}
{color}
...
{quote}
This configuration does not change anything in the resulting
{{xyz.war!/META-INF/MANIFEST.MF}}
--
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-30) I can't build a war-file without a web.xml.
[ http://jira.codehaus.org/browse/MWAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99851 ] Petr Kozelka commented on MWAR-30: -- Also when using war overlays, it makes pretty good sense to create a war without web.xml and add this file in an overlay. I suggest at least to add configuration option allowing WARs without web.xml, defaulting to current behavior. > I can't build a war-file without a web.xml. > --- > > Key: MWAR-30 > URL: http://jira.codehaus.org/browse/MWAR-30 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Christoffer Hammarström > > I have a small webapp with a small number of jsps, to overlay on a larger > webapp. > The larger webapp already has a web.xml and the small one doesn't need one. > I can't build a war of the small webapp, because the war-plugin requires a > web.xml. > I realise that a war-file without a web.xml might not be considered a comple > war-file, and i only need it to unzip on top of the larger webapp. > Maybe packaging the small webapp in a zip would be better? -- 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: (MSITE-226) Missing escaping of ${project.name} for default site descriptor
[
http://jira.codehaus.org/browse/MSITE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92442
]
Petr Kozelka commented on MSITE-226:
more useful part of stacktrace:
{quote}
...
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: expected =
after attribute name (position: START_DOCUMENT seen ...ations\nunder the
License.\n-->\n\n Missing escaping of ${project.name} for default site descriptor
> ---
>
> Key: MSITE-226
> URL: http://jira.codehaus.org/browse/MSITE-226
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: linux, maven-2.0.6
>Reporter: Petr Kozelka
>Priority: Minor
>
> It seems that when using the default site descriptor, no xml escaping is
> performed for name (and maybe other values).
> Excerpt from {{pom.xml}}:
> {quote}
> ...
> Module "MyMod-1.0"
> ...
> {quote}
> Excerpt from build log:
> {quote}
> ...
> [INFO] Error parsing site descriptor
> Embedded error: expected = after attribute name (position: START_DOCUMENT
> seen ...ations\nunder the License.\n-->\n\n [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing site
> descriptor
> 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:272)
> ...
> {quote}
--
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: (MSITE-226) Missing escaping of ${project.name} for default site descriptor
Missing escaping of ${project.name} for default site descriptor
---
Key: MSITE-226
URL: http://jira.codehaus.org/browse/MSITE-226
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Environment: linux, maven-2.0.6
Reporter: Petr Kozelka
Priority: Minor
It seems that when using the default site descriptor, no xml escaping is
performed for name (and maybe other values).
Excerpt from {{pom.xml}}:
{quote}
...
Module "MyMod-1.0"
...
{quote}
Excerpt from build log:
{quote}
...
[INFO] Error parsing site descriptor
Embedded error: expected = after attribute name (position: START_DOCUMENT seen
...ations\nunder the License.\n-->\n\nhttp://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2927) [PATCH] please make UTF-8 the default encoding
[PATCH] please make UTF-8 the default encoding -- Key: MNG-2927 URL: http://jira.codehaus.org/browse/MNG-2927 Project: Maven 2 Issue Type: Improvement Components: Sites & Reporting Affects Versions: 2.0.6 Environment: Gentoo Linux, UTF-8 encoded pom files Reporter: Petr Kozelka Priority: Minor Attachments: site-plugin-UTF8-encoding.patch UTF-8 is already widely supported and used by tools, there is hardly a reason to keep with ISO-8859-1 found through the code. In my usecases, it typically makes troubles with developer names containing accented letters. Attached patch changes the default input and output encoding in maven-site-plugin which is the most important piece. -- 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: (MNG-2922) M2 website: broken section links on pom.html, settings.html and others
[
http://jira.codehaus.org/browse/MNG-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Kozelka closed MNG-2922.
-
Resolution: Duplicate
found similar report in MNG-2808 , closing
> M2 website: broken section links on pom.html, settings.html and others
> --
>
> Key: MNG-2922
> URL: http://jira.codehaus.org/browse/MNG-2922
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: General
>Reporter: Petr Kozelka
>Priority: Minor
>
> Following pages contain TOC which does not work at all:
> http://maven.apache.org/pom.html
> http://maven.apache.org/settings.html
> The reason is that the TOC items refer to anchors incorrectly. For instance,
> in settings.html, there is reference
> bq.{{Quick Overview}}
> but the corresponding anchor is
> bq.{{Quick Overview}}
> Manual conversion of letters to lowercase and replacing spaces with
> underscores is too annoying to be considered workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-311) incorrectly displayed groupId for dependencies
incorrectly displayed groupId for dependencies
--
Key: MRM-311
URL: http://jira.codehaus.org/browse/MRM-311
Project: Archiva
Issue Type: Bug
Components: web application
Reporter: Petr Kozelka
the list in the "Dependencies" tab contains correct artifacts, but with groupId
taken from the library being explored, not from the dependency itself.
Example:
library {{org.hibernate:hibernate:3.2.1.ga}} depends on
- {{*net.sf.ehcache*:ehcache:1.2.3}}
- {{*javax.transaction*:jta:1.0.1B}}
- etc
but the page displays this information:
- {{{color:red}org.hibernate{color}:ehcache:1.2.3}}
- {{{color:red}org.hibernate{color}:jta:1.0.1B}}
- etc
The same bug appears on tabs "*Dependency tree*" and "*Used by*".
--
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-2922) M2 website: broken section links on pom.html, settings.html and others
[
http://jira.codehaus.org/browse/MNG-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91907
]
Petr Kozelka commented on MNG-2922:
---
same issue at http://maven.apache.org/guides/getting-started/index.html
> M2 website: broken section links on pom.html, settings.html and others
> --
>
> Key: MNG-2922
> URL: http://jira.codehaus.org/browse/MNG-2922
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: General
>Reporter: Petr Kozelka
>Priority: Minor
>
> Following pages contain TOC which does not work at all:
> http://maven.apache.org/pom.html
> http://maven.apache.org/settings.html
> The reason is that the TOC items refer to anchors incorrectly. For instance,
> in settings.html, there is reference
> bq.{{Quick Overview}}
> but the corresponding anchor is
> bq.{{Quick Overview}}
> Manual conversion of letters to lowercase and replacing spaces with
> underscores is too annoying to be considered workaround.
--
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-2922) M2 website: broken section links on pom.html, settings.html and others
M2 website: broken section links on pom.html, settings.html and others
--
Key: MNG-2922
URL: http://jira.codehaus.org/browse/MNG-2922
Project: Maven 2
Issue Type: Bug
Components: Documentation: General
Reporter: Petr Kozelka
Priority: Minor
Following pages contain TOC which does not work at all:
http://maven.apache.org/pom.html
http://maven.apache.org/settings.html
The reason is that the TOC items refer to anchors incorrectly. For instance, in
settings.html, there is reference
bq.{{Quick Overview}}
but the corresponding anchor is
bq.{{Quick Overview}}
Manual conversion of letters to lowercase and replacing spaces with underscores
is too annoying to be considered workaround.
--
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
