[jira] Commented: (MDEPLOY-112) deployed snapshot name has different build numbers for multiple artifacts of the same build
[ http://jira.codehaus.org/browse/MDEPLOY-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189639#action_189639 ] Gabriel Dogaru commented on MDEPLOY-112: I tried that . if i use MavenProjectHelper.attachArtifact() the artifacts do not have timestamp or build number. They get deployed the same way as using uniqueVersion=false. The reason why I didn't use MavenProjectHelper the first time is that for some projects I needed to create artifacts with a different name than project.name, and there is no MavenProjectHelper.attachArtifact() that would accept artifactId as parameter. Also I couldn't (still can't) use AttachedArtifact in project.addAttachedArtifact(artifact) as it is used in MavenProjectHelper because of some dependency conflict (I use gmaven 1.0-rc-4 and maven 2.2.1) and I used instead DefaultArtifact. I guess that is not a problem since they both implement Artifact. > deployed snapshot name has different build numbers for multiple artifacts of > the same build > --- > > Key: MDEPLOY-112 > URL: http://jira.codehaus.org/browse/MDEPLOY-112 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.2.1 > Environment: windows xp >Reporter: Gabriel Dogaru > > I have a module that deploys 2 artifacts,1 jar and 1 of them is custom type. > The build number from the snapshot name is different for the 2 (in the > repository). It get incremented every time an artifact is deployed. When I > try to make a local build it searches for the highest build number, and tries > to bring both the artifacts with the latest build number but only one of them > has that number. > I found a workaround for this by false for > the snapshotRepository. -- 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-479) Option to handle plugins missing explicit version number
Option to handle plugins missing explicit version number Key: MRELEASE-479 URL: http://jira.codehaus.org/browse/MRELEASE-479 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-9 Reporter: Tuomas Kiviaho A plugin declaration without version number is likely to turn 'bad' when using other version of maven (and super-pom). A switch that prompts version number providing version from super-pom as default would prevent maven upgrades from corrupting builds. -- 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-479) Option to handle plugins missing explicit version number
[ http://jira.codehaus.org/browse/MRELEASE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189642#action_189642 ] Joerg Schaible commented on MRELEASE-479: - While this is true in general, there are exceptions. E.g. it does indeed make sense to use latest maven-help-plugin, maven-eclipse-plugin, ... > Option to handle plugins missing explicit version number > > > Key: MRELEASE-479 > URL: http://jira.codehaus.org/browse/MRELEASE-479 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Tuomas Kiviaho > > A plugin declaration without version number is likely to turn 'bad' when > using other version of maven (and super-pom). A switch that prompts version > number providing version from super-pom as default would prevent maven > upgrades from corrupting builds. -- 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: (MCHANGELOG-103) Does not depend on gitexe provider
Does not depend on gitexe provider -- Key: MCHANGELOG-103 URL: http://jira.codehaus.org/browse/MCHANGELOG-103 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Maarten Billemont The plugin specifies a whole bunch of providers manually. This sounds like pretty bad practice; aside from that, it does not specify the gitexe provider, effectively making the plugin useless for repositories using the GIT SCM. Perhaps it should depend on org/apache/maven/scm/maven-scm-providers-standard or org/apache/maven/scm/maven-scm instead? -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
NPE when using the plugin with the git provider --- Key: MCHANGELOG-104 URL: http://jira.codehaus.org/browse/MCHANGELOG-104 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Maarten Billemont I've manually added a dependency on the gitexe provider to make the plugin able to use it. However, using the plugin with GIT then causes the following NullPointerEception: Caused by: java.lang.NullPointerException at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) at org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) at org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) at org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) ... 19 more -- 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-3) release:prepare should not require multimodule artifacts to be in the local repository
[ http://jira.codehaus.org/browse/MRELEASE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189646#action_189646 ] Job de Noo commented on MRELEASE-3: --- have te same issue that it will not resolve reactor dependencies in maven 2.2 > release:prepare should not require multimodule artifacts to be in the local > repository > -- > > Key: MRELEASE-3 > URL: http://jira.codehaus.org/browse/MRELEASE-3 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Reporter: John Casey > Fix For: Future > > > Currently, if you try to run release:prepare on a multimodule project after > removing any of that build's artifacts from the local repository, it will > fail. Investigate why release:prepare needs the multimodule artifacts > installed in the local repository before it can succeed. > To reproduce, comment the following line in it2002/test.sh: > mvn clean install > NOTE: This may have to do with the version resolution code, which is used to > resolve SNAPSHOT versions. -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[ http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189654#action_189654 ] Olivier Lamy commented on MCHANGELOG-104: - Are you using plugin trunk ? > NPE when using the plugin with the git provider > --- > > Key: MCHANGELOG-104 > URL: http://jira.codehaus.org/browse/MCHANGELOG-104 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont > > I've manually added a dependency on the gitexe provider to make the plugin > able to use it. However, using the plugin with GIT then causes the following > NullPointerEception: > Caused by: java.lang.NullPointerException > at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) > at > org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) > at > org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) > ... 19 more -- 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: (MCHANGELOG-103) Does not depend on gitexe provider
[ http://jira.codehaus.org/browse/MCHANGELOG-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHANGELOG-103. --- Assignee: Olivier Lamy Resolution: Duplicate > Does not depend on gitexe provider > -- > > Key: MCHANGELOG-103 > URL: http://jira.codehaus.org/browse/MCHANGELOG-103 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont >Assignee: Olivier Lamy > > The plugin specifies a whole bunch of providers manually. This sounds like > pretty bad practice; aside from that, it does not specify the gitexe > provider, effectively making the plugin useless for repositories using the > GIT SCM. > Perhaps it should depend on org/apache/maven/scm/maven-scm-providers-standard > or org/apache/maven/scm/maven-scm instead? -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[ http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189656#action_189656 ] Maarten Billemont commented on MCHANGELOG-104: -- Nope, maven-changelog-plugin-2.1. > NPE when using the plugin with the git provider > --- > > Key: MCHANGELOG-104 > URL: http://jira.codehaus.org/browse/MCHANGELOG-104 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont > > I've manually added a dependency on the gitexe provider to make the plugin > able to use it. However, using the plugin with GIT then causes the following > NullPointerEception: > Caused by: java.lang.NullPointerException > at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) > at > org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) > at > org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) > ... 19 more -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[
http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189657#action_189657
]
Mark Struberg commented on MCHANGELOG-104:
--
this has most probably already been fixed.
changelog-plugin-2.1 still uses maven-scm-1.0.
In maven-scm-1.2 this has been fixed with
{noformat}
if ( files != null )
{
for ( Iterator i = files.iterator(); i.hasNext(); )
{noformat}
Could you please test the changelog plugin by manually setting the dependency
to maven-scm-1.2? - txs! (This should also include the gitexe provider)
> NPE when using the plugin with the git provider
> ---
>
> Key: MCHANGELOG-104
> URL: http://jira.codehaus.org/browse/MCHANGELOG-104
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Maarten Billemont
>
> I've manually added a dependency on the gitexe provider to make the plugin
> able to use it. However, using the plugin with GIT then causes the following
> NullPointerEception:
> Caused by: java.lang.NullPointerException
> at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425)
> at
> org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> ... 19 more
--
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-479) Option to handle plugins missing explicit version number
[ http://jira.codehaus.org/browse/MRELEASE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189668#action_189668 ] Tuomas Kiviaho commented on MRELEASE-479: - Using maven-eclipse-plugin type of plugin for released artifacts goes beyond my imagination :-) What about sticking to plugins that have explicit configuration in the pom at hand and leaving undeclared plugins as-is. > Option to handle plugins missing explicit version number > > > Key: MRELEASE-479 > URL: http://jira.codehaus.org/browse/MRELEASE-479 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Tuomas Kiviaho > > A plugin declaration without version number is likely to turn 'bad' when > using other version of maven (and super-pom). A switch that prompts version > number providing version from super-pom as default would prevent maven > upgrades from corrupting builds. -- 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-4194) API to safely release of plugin realms
[ http://jira.codehaus.org/browse/MNG-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189671#action_189671 ] Benjamin Bentmann commented on MNG-4194: Could you provide some more details on the desired API, e.g. pseudo-code that illustrates its intended usage and the required methods? > API to safely release of plugin realms > -- > > Key: MNG-4194 > URL: http://jira.codehaus.org/browse/MNG-4194 > Project: Maven 2 > Issue Type: Improvement > Components: Class Loading >Affects Versions: 3.0-alpha-2 >Reporter: Igor Fedorenko > Fix For: 3.0-alpha-5 > > > This is a followup request for MNG-4041. > PluginManager and Plugin cache should allow safe release of plugin realms, > that is, ability for embedding application, like Eclipse or Netbeans, to > determine if any given plugin realm is currently being used and remove unused > realms from PluginCache in a thread-safe manner. > I see at least two cases when it is not safe to release a plugin realm > * Regular plugin realm during mojo execution. > * Extensions plugin realm for as long as the referencing project(s) are in > the reactor or otherwise known to the embedding application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-496) org.apache.maven.scm.NoSuchCommandScmException: No such command 'list' when the Perforce SCM Provider is used by the SCM Wagon in "maven deploy"
org.apache.maven.scm.NoSuchCommandScmException: No such command 'list' when the Perforce SCM Provider is used by the SCM Wagon in "maven deploy" Key: SCM-496 URL: http://jira.codehaus.org/browse/SCM-496 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Environment: Maven 2.2.1, jdk 1.6 SR16, Win32 Reporter: Louis Lecaroz Priority: Critical Attachments: pom.xml After having taken a look in the svn in trunk, the AbstractScmProvider & its implementations except Perforce implement the AbstractScmProvider.list() method. As this method is called by the ScmWagon, & because it is not implemented in the PerforceScmProvider, it generates this exception (generated by the AbstractScmProvider.list() code ) : Uploading: scm:perforce:lleca...@pperforce.server.com:1971://experiments/llecaroz/Maven/Repository/demo/foo/app/tp.sun.java-test-1/1.2-SNAPSHOT/tp.sun.java-test-1-1.2-20090903.105728-1.jar [INFO] No password found, proceeding without it. [DEBUG] No such command 'list'. org.apache.maven.scm.NoSuchCommandScmException: No such command 'list'. at org.apache.maven.scm.provider.AbstractScmProvider.list(AbstractScmProvider.java:595) at org.apache.maven.scm.provider.AbstractScmProvider.list(AbstractScmProvider.java:579) at org.apache.maven.wagon.providers.scm.ScmWagon.checkOut(ScmWagon.java:371) at org.apache.maven.wagon.providers.scm.ScmWagon.putInternal(ScmWagon.java:285) at org.apache.maven.wagon.providers.scm.ScmWagon.put(ScmWagon.java:254) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) 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) So I was unable to use the Perforce SCM Provider as SCM Wagn as you will see in this simplified attached/POM(testcase) to reproduce the issue. Don't forget to replace the url & username by a working one. To run it : -detach this pom -modify the url to a valid perforce server -launch "maven deploy" Tried with svn just by switching the extension from perforce into svn & modifying the url : no problem... as svn provider implements the list() method. So the list() method needs to be implemented in the PerforceScmProvider as solution. At this time from my understanding, no project can use perforce as repository. Thx in advance Louis -- 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-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189682#action_189682 ] Robert Burrell Donkin commented on MSITE-159: - Introducing buggy URL rewriting code just because some Maven users don't understand URLs is a poor design choice. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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: (MSOURCES-50) Add optional 'classifier' for source artifact
Add optional 'classifier' for source artifact - Key: MSOURCES-50 URL: http://jira.codehaus.org/browse/MSOURCES-50 Project: Maven 2.x Source Plugin Issue Type: New Feature Reporter: Barry Pitman Attachments: classifier.patch The default classifiers, 'sources' and 'test-sources' are sufficient for most cases, but I have come across cases where specifying a different classifier could be useful. E.g. when building a skinny war with packaged classes, the 'sources' artifact is really the source of the (secondary) classes artifact, not the primary war artifact. As such, the classifier of the sources should be 'classes-sources', not 'sources'. I've attached a basic patch which I am using. -- 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-4055) wrong error on mvn install in folder without pom.xml
[ http://jira.codehaus.org/browse/MNG-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189697#action_189697 ] Benjamin Bentmann commented on MNG-4055: What exactly is wrong with the error? You have "a folder without maven's pom.xml file" and the errors says "Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.", seems OK to me and appears to match Maven 2.x behavior as well. > wrong error on mvn install in folder without pom.xml > - > > Key: MNG-4055 > URL: http://jira.codehaus.org/browse/MNG-4055 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 3.0-alpha-2 >Reporter: Milos Kleint > Fix For: 3.0-alpha-5 > > > a folder without maven's pom.xml file. running mvn install there-> > [mkle...@localhost glassfish]$ ~/javatools/apache-maven-3.0-alpha-2/bin/mvn > install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Default Project > [INFO] > [INFO] Id: org.apache.maven:super-pom:jar:3.0-SNAPSHOT > [INFO] task-segment: [install] > [INFO] > > [ERROR] > Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources': Cannot > execute mojo: resources. It requires a project with an existing pom.xml, but > the build is not using one. > While building project with id: org.apache.maven:super-pom:jar:3.0-SNAPSHOT -- 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: (MANT-59) Add support for generating build files when bundle
Add support for generating build files when bundle -- Key: MANT-59 URL: http://jira.codehaus.org/browse/MANT-59 Project: Maven 2.x Ant Plugin Issue Type: New Feature Reporter: Alexander Kurtakov When packaging is set to bundle ant:ant task generates an empty package target containting the following message "No Ant task exists for the packaging 'bundle'. You could overrided the Ant package target in your build.xml." It would be good if packaging bundle is handled the same way as packaging jar. This will allow generating build.xml good enough for building a jar though it not be an OSGi bundle but this is good enough for bootstrapping purposes. It would be even better if a parameter for setting the MANIFEST.MF is present, e.g being able to use `ant -Dmaven.bundle.manifest=./MANIFEST.MF package` -- 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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-317: - Assignee: (was: Olivier Lamy) Fix Version/s: (was: 1.3) > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Attachments: provider-cvs-with-edit.patch > > -- 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: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
[ http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-444: - Assignee: (was: Olivier Lamy) Fix Version/s: (was: 1.3) Won't fix ? > Git provider does 'git push' during 'mvn release:prepare' which causes > unwanted problems > > > Key: SCM-444 > URL: http://jira.codehaus.org/browse/SCM-444 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Petter Måhlén >Priority: Minor > > When doing 'mvn release:prepare' with a Git provider, a 'git push' command is > executed. This is not ideal because the push command can fail or push things > from the local repository that are not needed/wanted in the remote > repository. Some examples are: > 1. The local repository has two branches: master (tracking origin/master) and > dummy (tracking origin/dummy). The release is being made on the master > branch, and the dummy and origin/dummy branches have diverged. Running > 'release:prepare' causes a 'git push', which will succeed for the master > branch (assuming that the release preparation has been made correctly) and > fail for the dummy branch (the two branches have diverged and need to be > merged or rebased). The release preparation aborts and the directory is left > in a somewhat inconsistent state where manual cleaning up is needed (removing > pom.xml.next files, changing versions to -SNAPSHOT, etc.) > 2. The local repository has two branches: master (tracking origin/master) and > localtest (not in the origin repository). The localtest branch shouldn't be > published because it is just used for some temporary testing and doesn't even > work. It will be pushed during 'release:prepare'. > Suggested behaviour: use 'git push origin :', > or even better, query for which remote repository to push to (found in > .git/config) and which branch to push from and to. For me, it would be great > to have a 'confirm push' before doing it so as to keep things clean, but > maybe that is quite complex. -- 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-2587) Equinox Core Framework 3.5.0.v20090520
Equinox Core Framework 3.5.0.v20090520 -- Key: MAVENUPLOAD-2587 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2587 Project: Maven Upload Requests Issue Type: Wish Reporter: Guillaume Nodet -- 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: (MJAVADOC-245) Aggregate does not work
[ http://jira.codehaus.org/browse/MJAVADOC-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189755#action_189755 ] Jörg Hohwiller commented on MJAVADOC-245: - Sorry for delay... I tried your testcase and aggregated javadoc works with "mvn site" as well as with "mvn site:stage". However a Javadoc per module is not generated but is also not configured so not a bug so far. Next I try to figure out the differences to my project... Maybe it is just because I also wanted to have javadocs per module. See if I will find the time to extract a testcase to show the problem... However my workaround works okay. > Aggregate does not work > --- > > Key: MJAVADOC-245 > URL: http://jira.codehaus.org/browse/MJAVADOC-245 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5, 2.6 >Reporter: Jörg Hohwiller > Attachments: MJAVADOC-245.zip > > > I want to have an aggregated javadoc for the entire project as well as per > module. > Therefore I followed instructions at: > http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html > When I do mvn site:stage I get no aggregated javadoc but just per module. > This does not even change if I only do > > > > aggregate > > > > So to me this looks as if is magically ignored here. > I have tested 2.5 as well as 2.6 from > https://repository.apache.org/content/repositories/maven-staging-027/org/apache/maven/plugins/maven-javadoc-plugin/2.6/ -- 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-2588) rsync_ssh request for net.sf.transmorph
rsync_ssh request for net.sf.transmorph --- Key: MAVENUPLOAD-2588 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2588 Project: Maven Upload Requests Issue Type: Wish Reporter: Cédric Chabanois "net.sf.transmorph","mavens...@web.sourceforge.net:/home/groups/t/tr/transmorph/htdocs/m2repo","rsync_ssh","Cedric Chabanois","cchaban...@gmail.com",, -- 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-2589) Jansi 1.0
Jansi 1.0 - Key: MAVENUPLOAD-2589 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2589 Project: Maven Upload Requests Issue Type: Wish Reporter: Guillaume Nodet -- 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-2590) sync of release repo
sync of release repo Key: MAVENUPLOAD-2590 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2590 Project: Maven Upload Requests Issue Type: Wish Reporter: Claus Brøndby Reimer Hi Maven Tema I have created my first maven plugin, and i would love to share can I have my project sync'ed "org.wooddog.mavenplugins","rsync://www.wooddog.org/mavenplugins","rsync","Claus Brøndby Reimer","claus...@gmail.com" proof of domain http://reports.internic.net/cgi/whois?type=domain&whois_nic=wooddog.org http://www.wooddog.org/maven/site/keystore/team-list.html best regards, Claus -- 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-3913) Figure out why MavenEmbedderExampleTest fails on the grid and reenable when fixed.
[ http://jira.codehaus.org/browse/MNG-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3913. -- Resolution: Fixed > Figure out why MavenEmbedderExampleTest fails on the grid and reenable when > fixed. > -- > > Key: MNG-3913 > URL: http://jira.codehaus.org/browse/MNG-3913 > Project: Maven 2 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-4 > > -- 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-4221) Push all repository/artifact related code into a legacy module and create a backward compat layer for external consumers
[ http://jira.codehaus.org/browse/MNG-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189788#action_189788 ] Jason van Zyl commented on MNG-4221: The first part of this has been done, in that the maven-compat layer was created and a quarter of the adapters have been created. This needs to be complete, the adapters finished and the direction of all dependencies from maven-compat be outbound. > Push all repository/artifact related code into a legacy module and create a > backward compat layer for external consumers > > > Key: MNG-4221 > URL: http://jira.codehaus.org/browse/MNG-4221 > Project: Maven 2 > Issue Type: Task >Affects Versions: 3.0-alpha-2 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-4 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4221) Push all repository/artifact related code into a legacy module and create a backward compat layer for external consumers
[ http://jira.codehaus.org/browse/MNG-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4221: --- Fix Version/s: (was: 3.0-alpha-3) 3.0-alpha-4 > Push all repository/artifact related code into a legacy module and create a > backward compat layer for external consumers > > > Key: MNG-4221 > URL: http://jira.codehaus.org/browse/MNG-4221 > Project: Maven 2 > Issue Type: Task >Affects Versions: 3.0-alpha-2 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-4 > > -- 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
