[jira] Commented: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235952#action_235952 ] Arik Kfir commented on MRELEASE-318: Brett, can you please elaborate about the "more general problem about ranges" you mentioned? > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Assignee: Brett Porter >Priority: Blocker > Fix For: 2.1 > > Attachments: MNG-3351-unittest.patch, MNG-3351.zip, > MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, > simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [13:42:05]: at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It seems the reason version is null is that the call to > selectVersionFromNewRangeIfAvailable() assumes that > versionRange.getRecommendedVersion() will always return non-null, else it > sets the version to null! However during the release:prepare phase this is > not true, see the output: > [13:42:04]: [INFO] [release:prepare] > [13:42:04]: [INFO] Verifying that there are no local modifications... > [13:42:04]: [INFO] Executing: svn --non-interactive status > [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 > [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... > [13:42:05]: TEST!!! version=null > [13:42:05]: TEST!!! versionRange=[1.0,2.0) > [13:42:05]: TEST!!! getRecommendedVersion=null > TEST!!! Lines are my test code so I could see
[jira] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[
http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244032#action_244032
]
Arik Kfir commented on MNG-3092:
+1 for including SNAPSHOTs in the version ranges if the artifact is in the
reactor. I also liked the [x,y){use-snapshots=true} proposal.
I also agree that this is a process problem and should be enforced by the
enforcer plugin, rather than maven core itself.
Btw, besides CI builds, another use-case in favor of including SNAPSHOTs in
ranges is IDE integration; we have a project consisting of multiple
inter-dependant modules and having them resolve to each-other using ranges is
very convenient, rather than updating the POMs everytime one of them is
released.
> Version ranges with non-snapshot bounds can contain snapshot versions
> -
>
> Key: MNG-3092
> URL: http://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Hobson
> Attachments: MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-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] Commented: (MRELEASE-519) release plugin fails on version ranges
[ http://jira.codehaus.org/browse/MRELEASE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231411#action_231411 ] Arik Kfir commented on MRELEASE-519: Hi, This happens to us too, using Maven 2.2.1 and version 2.0 of the plugin. This is the first time we use ranges though so I can't confirm it used to work in a previous version. > release plugin fails on version ranges > -- > > Key: MRELEASE-519 > URL: http://jira.codehaus.org/browse/MRELEASE-519 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0 > Environment: Mac OS X 10.6, maven 2.2.1 >Reporter: Stephen Cooper >Priority: Critical > > I have the following dependency in my pom.xml > >com.ften.protocols >protocols >[3.0.0,) >compile > > I downloaded the source for maven-release 2.0 and installed locally. > If I specify 2.0-beta-9, then mvn release:perform functions as it should. If > I specify maven-release-plugin version 2.0, I get the following error: > [INFO] Checking dependencies and plugins for snapshots ... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for com.ften.protocols:protocols > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > com.ften.protocols:protocols > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390) > at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562) -- 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-1258) Add option to redownload poms
[ http://jira.codehaus.org/browse/MNG-1258?page=comments#action_68763 ] Arik Kfir commented on MNG-1258: Hi, You could use the "If-Modified-Since" HTTP header when querying the repo. All HTTP servers support this (part of HTTP protocol). This essentially tells the server to provide the resource (POM, JAR, etc) only if it was modified after a certain date; the given date can be the date it was downloaded to the user's computer. Even more powerful would be to have maven do this automatically once in a while. So, for example, once a week maven does this to every artifact it downloads (even without the command line parameter). Of course, this should be configured in the settings.xml file. This would completely eliminate the stale artifacts problem in users' computers, whilst not requiring users to know about this command line switch, and not hurting performance too much (since only the deltas are re-downloaded). The downside is that there is still an additional request to the server (once a week or whatever) but the upside is that no stale artifacts are present for too long in a user's dir. WDYT? > Add option to redownload poms > - > > Key: MNG-1258 > URL: http://jira.codehaus.org/browse/MNG-1258 > Project: Maven 2 > Type: Improvement > Components: Plugins and Lifecycle > Versions: 2.0 (RC) > Reporter: Carlos Sanchez > Fix For: 2.1 > > > Add an option to the command line to redownload the poms, so it's easy to get > the fixes in the remote repo. Something like -f , --refresh or whatever -- 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-29) Imposible to generated UTF-8 site with APT
[ http://jira.codehaus.org/browse/MSITE-29?page=comments#action_70397 ] Arik Kfir commented on MSITE-29: I think this issue can be closed... > Imposible to generated UTF-8 site with APT > -- > > Key: MSITE-29 > URL: http://jira.codehaus.org/browse/MSITE-29 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Linux 2.6.10, JDK 1.5, Maven 2.0-alpha-3 >Reporter: Jean-Charles Giardina >Priority: Minor > Fix For: 2.0 > > > Maven plugin's site cannot generated HTML files from APT files using charset > UTF-8 rather than ISO-8859-1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-54) Team list table improvement
[ http://jira.codehaus.org/browse/MPIR-54?page=comments#action_72211 ]
Arik Kfir commented on MPIR-54:
---
I noticed that your patch creates two organization columns - one for the
organization name ("Organization") and one for the organization URL
("Organization URL").
Perhaps it is better to unify them to one column simply called "Organization"
that always displays the organization name, but if an organization URL is
specified in the POM, that label becomes a link to that URL. This would save
some space in the table.
> Team list table improvement
> ---
>
> Key: MPIR-54
> URL: http://jira.codehaus.org/browse/MPIR-54
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 2.0-beta-3, 2.0, 2.0.1
>Reporter: Dmitry Kobyleha
> Attachments: TeamListReport.java
>
>
> When fo all developers in pom.xml we some property not defined, it is good to
> not include it to html output.
> Fow example:
> ...
>
> developer1
> Developer 1
> [EMAIL PROTECTED]
>
> Project Manager
> Architect
> Java Developer
>
> +2
>
>
> developer2
> Developer 2
> [EMAIL PROTECTED]
>
> Java Developer
>
> +2
>
> ...
> For both developers properties like URL, Organization,Organization
> URL and Properties not specified. In result html we have cells with "-".
> As for me it is good not not include columns where only "-" present at all.
--
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-2511) Need ability to redefine distribution management url
[ http://jira.codehaus.org/browse/MNG-2511?page=comments#action_72590 ] Arik Kfir commented on MNG-2511: Milos, It should work, but I think this JIRA refers to use-cases when the project at hand had not defined such a property. For example, we work in an offline environment, where I'd like to generate and deploy the Maven site to our intranet servers. I cannot do that since such a property does not exist in components/pom.xml. > Need ability to redefine distribution management url > > > Key: MNG-2511 > URL: http://jira.codehaus.org/browse/MNG-2511 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4 >Reporter: Brian Fox > > Currently the only way to specify a url for distributionManagement is in the > pom. We need to be able to override that so that if needed a developer can > set a server id in their settings and define a new url. For example, some > developers are outside the company's infrastructure and they deploy > differently than developers internally. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-42) General setting of dependency filenames
[ http://jira.codehaus.org/browse/MEAR-42?page=comments#action_75398 ] Arik Kfir commented on MEAR-42: --- IMO this should also be the default... > General setting of dependency filenames > --- > > Key: MEAR-42 > URL: http://jira.codehaus.org/browse/MEAR-42 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Jonas Olsson >Priority: Minor > Fix For: 2.3 > > > When adding dependencies to the EAR, the "brief" filename from the repository > is used (i.e. -.jar). > I some cases this will result in a name collision, required to be manually > resolved with bundleFilename, but wouldn't an option to use the "full" > filename (i.e. --.jar) be better, allowing > automatic re-use of the already established namespace? -- 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-3) MavenProject / pom listener
[ http://jira.codehaus.org/browse/MNG-3?page=comments#action_75691 ] Arik Kfir commented on MNG-3: - Hi, I still think this can make IDE integration easier, but for now - I think this issue shouldn't be marked as FIXED, but rather WON'T FIX, or incomplete, since it wasn't really implemented. > MavenProject / pom listener > --- > > Key: MNG-3 > URL: http://jira.codehaus.org/browse/MNG-3 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritence and Interpolation, Embedding >Reporter: gilles dodinet > Assigned To: Jason van Zyl > Fix For: 2.1 > > > ide integration needs a listener mechanism so that when project/model is > changed interested parties are notified and can eventually reflect those > changes (f.i. refresh a view). we've implemented that in mevenide, please see > : > http://cvs.mevenide.codehaus.org/cvsweb.cgi/mevenide-core/src/java/org/mevenide/project/ -- 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-3150) Command line -f option should propagate to module poms.
[ http://jira.codehaus.org/browse/MNG-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106823 ] Arik Kfir commented on MNG-3150: Why not use profiles for this? > Command line -f option should propagate to module poms. > --- > > Key: MNG-3150 > URL: http://jira.codehaus.org/browse/MNG-3150 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Reporter: Paul Gier > Attachments: MNG-3150-maven-core-r573613.patch > > > I have a multi module project where I would like to have parrallel builds. > The default pom.xml build would be using jdk1.5 or jdk6, and the parrallel > build pom would be for creating retro compiled jdk14 artifacts. So the pom > for this build would be "pom-jdk14.xml". I've explored other options such as > using a classifier for the retro translated artifact, and using profiles to > choose between jdk1.5 and jdk1.4 builds. But both of these have problems > that I can't get around without a lot of difficulty. > Using two separate poms works great for me for a single module project, but > for a multi module project, I have no way to tell the modules to pick up a > different pom.xml file. > So for my multi module build I would like to be able to say > mvn -f pom-jdk14.xml install > And each module should then look for it's own pom-jdk14.xml. This could be > made into the default behaviour of the "-f" option, or a new option could be > introduced like "-fg" to use the other pom file globally across all the > module. -- 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: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115012 ] Arik Kfir commented on MDEPLOY-48: -- Note that deploy:deploy-file spews an exceptions while deploying an artifact with the -Dclassifier=sources parameter: *mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId= -Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY -Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF* [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar 60K uploaded [INFO] Retrieving previous metadata from codeshine [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace *java.lang.NullPointerException at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:842) at org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java: 428) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java: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)* [INFO] [INFO] Total time: 42 seconds [INFO] Finished at: Tue Nov 27 12:00:53 IST 2007 [INFO] Final Memory: 3M/6M [INFO] *The actual deployment of the artifact to the remote server succeeds - it fails when (apparently) trying to install the file as well.* > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- 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] Issue Comment Edited: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[
http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115012
]
arikkfir edited comment on MDEPLOY-48 at 11/27/07 4:09 AM:
Note that deploy:deploy-file spews an exceptions while deploying an artifact
with the -Dclassifier=sources parameter:
*mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=
-Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY
-Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF*
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
[INFO] [deploy:deploy-file]
Uploading:
scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar
60K uploaded
[INFO] Retrieving previous metadata from codeshine
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
*java.lang.NullPointerException
at
hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:842)
at
org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:
428)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86)
at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java: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)*
[INFO]
[INFO] Total time: 42 seconds
[INFO] Finished at: Tue Nov 27 12:00:53 IST 2007
[INFO] Final Memory: 3M/6M
[INFO]
{noformat}
*The actual deployment of the artifact to the remote server succeeds - it fails
when (apparently) trying to install the file as well.*
was (Author: arikkfir):
Note that deploy:deploy-file spews an exceptions while deploying an
artifact with the -Dclassifier=sources parameter:
*mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=
-Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY
-Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF*
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
[INFO] [deploy:deploy-file]
Uploading:
scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar
60K uploaded
[INFO] Retrieving previous metadata from codeshine
[INFO] --
[jira] Issue Comment Edited: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[
http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115012
]
arikkfir edited comment on MDEPLOY-48 at 11/27/07 4:10 AM:
Note that deploy:deploy-file spews an exceptions while deploying an artifact
with the -Dclassifier=sources parameter:
*mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=
-Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY
-Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF*
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
[INFO] [deploy:deploy-file]
Uploading:
scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar
60K uploaded
[INFO] Retrieving previous metadata from codeshine
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
*java.lang.NullPointerException
at
hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:842)
at
org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:
428)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86)
at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java: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)*
[INFO]
[INFO] Total time: 42 seconds
[INFO] Finished at: Tue Nov 27 12:00:53 IST 2007
[INFO] Final Memory: 3M/6M
[INFO]
{noformat}
*The actual deployment of the artifact to the remote server succeeds - it fails
when (apparently) trying to install the file as well.*
was (Author: arikkfir):
Note that deploy:deploy-file spews an exceptions while deploying an
artifact with the -Dclassifier=sources parameter:
*mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=
-Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY
-Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF*
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
[INFO] [deploy:deploy-file]
Uploading:
scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar
60K uploaded
[INFO] Retrieving previous metadata from codeshine
[INFO
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91703 ] Arik Kfir commented on MIDEA-39: This is definitly working for me in 2.1-SNAPSHOT. Caveat is to run "mvn idea:idea" in the multi-module root; if you run it inside one of the modules, inter-module dependencies indeed do not work (as they are not in the reactor I believe). > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Attachments: module-dependencies.patch > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- 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: (MIDEA-86) [Patch] Add support for IDEA 7 (Selena) EJB/EAR modules
[Patch] Add support for IDEA 7 (Selena) EJB/EAR modules
---
Key: MIDEA-86
URL: http://jira.codehaus.org/browse/MIDEA-86
Project: Maven 2.x Idea Plugin
Issue Type: Improvement
Affects Versions: 2.0, 2.1
Environment: IntelliJ IDEA 7.x (Selena)
Reporter: Arik Kfir
Attachments: idea-7-support.patch
This patch prevents generation of an entry for the deployment descriptor if it
does not exist, in accordance to JEE 5. This is only done if the actual IDEA
version (set in the project's POM) is indeed 7. In IDEA 7, if a descriptor is
specified in the IML file, but does not exist, it spits out an error on every
compilation
Also, *unrelated* to the plugin runtime, this patch adds this snippet to the
pom.xml:
{noformat}
maven-idea-plugin
1.4
{noformat}
For those who use IDEA to work on the plugin, this makes sure that the project
JDK level is 1.4 (which is the policy currently, to prevent IDEA's suggestions
for JDK 5-level (e.g. "don't suggest using a "for-each" instead of "for(int
i=...)")
--
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-2715) Maven does not comply to XML rules regarding prefixes.
[
http://jira.codehaus.org/browse/MNG-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93797
]
Arik Kfir commented on MNG-2715:
Seva,
I don't think Jason meant Maven will *never* support namespaces; only the 2.0.x
branch won't. I'm quite sure Maven 2.1 will support it (by moving to a standard
XML parser) - I think work has already began on the matter.
Jason, please correct me if I'm mistaken.
Best regards,
Arik.
> Maven does not comply to XML rules regarding prefixes.
> --
>
> Key: MNG-2715
> URL: http://jira.codehaus.org/browse/MNG-2715
> Project: Maven 2
> Issue Type: Bug
> Environment: Ubuntu 6.10
> Maven 2.0.4
>Reporter: Seva Safris
>Priority: Critical
>
> I am new to Maven and have been trying to learn how to create a simple
> project.
> Let me walk through my scenario of creating a pom.xml file:
> 1. I bind the {http://maven.apache.org/POM/4.0.0} namespace (defined at
> "http://maven.apache.org/maven-v4_0_0.xsd";) to Java classes using an XML
> Binding solution.
> 2. I use the bound classes to create a simple as one would expect
> to see in a pom.xml file.
> 3. I marshal the bound Java objects into xml and write it into pom.xml. Here
> is the xml I use:
>xmlns:ns1="http://maven.apache.org/POM/4.0.0";>
> 4.0.0
> com.myapp
> sample-project
> Sample Maven Project
> 1.0
>
>
> ssafris
> Seva Safris
>
>
>
> ${basedir}/src/java
>
>
> 4. I run mvn, and am promptly given a "Not a v4.0.0 POM." exception.
> Tracing through Maven's source, I went to the exact location of the exception
> in DefaultMavenProjectBuilder.java. On line 1297 it has:
> if ( modelSource.indexOf( "4.0.0" ) < 0 )
> {
> throw new InvalidProjectModelException( projectId, pomLocation, "Not a
> v4.0.0 POM." );
> }
> Since modelSource is checked explicitly for
> xml as shown above will fail this test because it has: This is most definitely a bug in Maven and should be fixed as soon as
> possible. The workaround is to use a
> xmlns="http://maven.apache.org/POM/4.0.0"; and define all elements without a
> prefix. However, my use of xmlns:ns1="http://maven.apache.org/POM/4.0.0";
> should not break Maven as it is not merely legal by xml conventions, but is
> also a better practice for xml documents.
> I hope you see the importance of getting this bug fixed: My use of a XML
> Binding solution to bind Maven's xml to Java allows me a strongly-typed level
> of indirection that will deterministically create proper xml that will
> validate successfully. If this bug is not fixed, then this level of
> indirection is not possible (or very very very difficult because the XML
> Binding solution would have to be hacked to use the xmlns="[...]"
> convention). I have only found this one instance of where the bug is obvious,
> but perhaps there are more locations in Maven where the same kind of error
> can occur.
> Thank you for your time, and I hope you consider this issue as seriously as I
> do.
> Sincerely,
> Seva Safris
--
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: (MEV-518) Google Juice POM has wrong "" - should be "jar" and not "pom"
Google Juice POM has wrong "" - should be "jar" and not "pom" Key: MEV-518 URL: http://jira.codehaus.org/browse/MEV-518 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Arik Kfir The pom for guice-1.0 states a packaging of "pom", but it really represents a jar (sits alongside the guice-1.0.jar file). -- 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] Reopened: (MEV-518) Google Juice POM has wrong "" - should be "jar" and not "pom"
[ http://jira.codehaus.org/browse/MEV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arik Kfir reopened MEV-518: --- Problem seems to still exist, although the duplicated issue is marked as fixed. Packaging is still "pom" in the "pom.xml" file... > Google Juice POM has wrong "" - should be "jar" and not "pom" > > > Key: MEV-518 > URL: http://jira.codehaus.org/browse/MEV-518 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Arik Kfir >Assignee: Carlos Sanchez > > The pom for guice-1.0 states a packaging of "pom", but it really represents a > jar (sits alongside the guice-1.0.jar file). -- 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: (MIDEA-86) [Patch] Add support for IDEA 7 (Selena) EJB/EAR modules
[
http://jira.codehaus.org/browse/MIDEA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95168
]
Arik Kfir commented on MIDEA-86:
ok...
> [Patch] Add support for IDEA 7 (Selena) EJB/EAR modules
> ---
>
> Key: MIDEA-86
> URL: http://jira.codehaus.org/browse/MIDEA-86
> Project: Maven 2.x Idea Plugin
> Issue Type: Improvement
>Affects Versions: 2.0, 2.1
> Environment: IntelliJ IDEA 7.x (Selena)
>Reporter: Arik Kfir
> Attachments: idea-7-support.patch
>
>
> This patch prevents generation of an entry for the deployment descriptor if
> it does not exist, in accordance to JEE 5. This is only done if the actual
> IDEA version (set in the project's POM) is indeed 7. In IDEA 7, if a
> descriptor is specified in the IML file, but does not exist, it spits out an
> error on every compilation
> Also, *unrelated* to the plugin runtime, this patch adds this snippet to the
> pom.xml:
> {noformat}
>
>
> maven-idea-plugin
>
> 1.4
>
>
>
> {noformat}
> For those who use IDEA to work on the plugin, this makes sure that the
> project JDK level is 1.4 (which is the policy currently, to prevent IDEA's
> suggestions for JDK 5-level (e.g. "don't suggest using a "for-each" instead
> of "for(int i=...)")
--
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: (MAVENUPLOAD-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99757 ] Arik Kfir commented on MAVENUPLOAD-1603: I don't see it either. > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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: (MEV-534) Dependencies of commons-logging should be optional
[ http://jira.codehaus.org/browse/MEV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100701 ] Arik Kfir commented on MEV-534: --- Shouldn't log4j be optional too? > Dependencies of commons-logging should be optional > -- > > Key: MEV-534 > URL: http://jira.codehaus.org/browse/MEV-534 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: J-C Walmetz > > Dependencies in pom should be > > >log4j >log4j >1.2.12 > > − > > logkit > logkit > 1.0.1 > > − > > junit > junit > 3.8.1 > test > > − > > avalon-framework > avalon-framework > 4.1.3 > > − > > javax.servlet > servlet-api > 2.3 > true > > instead of > > − > > log4j > log4j > 1.2.12 > > − > > logkit > logkit > 1.0.1 > > − > > junit > junit > 3.8.1 > test > > − > > avalon-framework > avalon-framework > 4.1.3 > > − > > javax.servlet > servlet-api > 2.3 > > > -- 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-186) Display version numbers in documentation, particularly for plugins
[ http://jira.codehaus.org/browse/MSITE-186?page=comments#action_78747 ]
Arik Kfir commented on MSITE-186:
-
If the site.xml could be interpolated with macros such as "${project.version}"
then this would be easy - one would simply add the ${version} to the project
title. Same goes for the APT docs.
> Display version numbers in documentation, particularly for plugins
> --
>
> Key: MSITE-186
> URL: http://jira.codehaus.org/browse/MSITE-186
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
>Reporter: Nigel Magnay
>
> Typical day at the office
> user : This plugin doesn't seem to be working properly
> me: have you checked the documentation
> user: Yes, it says but I just get some error
> me: Ah, that's because the documentation is for version of that plugin,
> and we're using plugin version
> user: how do I know which version I'm running and what version this
> documentation is for ?
> * Add the version to the site
> * For plugins, make the version a link to a page that tells the user how to
> determine what version of a plugin they are 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] Created: (MEV-475) glazedlists 1.7.0 "-sources" JAR is built incorrectly
glazedlists 1.7.0 "-sources" JAR is built incorrectly - Key: MEV-475 URL: http://jira.codehaus.org/browse/MEV-475 Project: Maven Evangelism Issue Type: Bug Reporter: Arik Kfir The "-sources" JAR for the stated artifact is not built correctly - it contains dirs such as "sources", "test", etc which themselves contain the actual source code. This means that the JAR cannot be used by IDEs as the source references (the maven-idea/eclipse-plugin download such JARs and link them to the binary). I've attached a fixed JAR which simply contains the content of such directories directly in the JAR's root directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEV-475) glazedlists 1.7.0 "-sources" JAR is built incorrectly
[ http://jira.codehaus.org/browse/MEV-475?page=all ] Arik Kfir updated MEV-475: -- Attachment: glazedlists_java15-1.7.0-sources.jar > glazedlists 1.7.0 "-sources" JAR is built incorrectly > - > > Key: MEV-475 > URL: http://jira.codehaus.org/browse/MEV-475 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Arik Kfir > Attachments: glazedlists_java15-1.7.0-sources.jar > > > The "-sources" JAR for the stated artifact is not built correctly - it > contains dirs such as "sources", "test", etc which themselves contain the > actual source code. This means that the JAR cannot be used by IDEs as the > source references (the maven-idea/eclipse-plugin download such JARs and link > them to the binary). > I've attached a fixed JAR which simply contains the content of such > directories directly in the JAR's root directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-202) Language bundle not found for empty pom project
[ http://jira.codehaus.org/browse/MSITE-202?page=comments#action_83181 ] Arik Kfir commented on MSITE-202: - This happens to me too. And the weird thing - it happens when I invoke "mvn clean install" - not even invoking the site plugin > Language bundle not found for empty pom project > --- > > Key: MSITE-202 > URL: http://jira.codehaus.org/browse/MSITE-202 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Kenney Westerhof > > for a POM project, no modules, no src/site, the following error is generated: > Added 'maven-site-plugin/src/test/projects/site-plugin-test13/'. > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - > org.apache.maven.plugins.site-plugin-test:site-plugin-test12:pom:1.0 > [INFO]task-segment: [site] > [INFO] > > [WARNING] Unable to get resource > 'org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT' from repository > java.net (https://maven-repository.dev.java.net/nonav/repository/) > [WARNING] POM for 'commons-collections:commons-collections:pom:3.1:runtime' > is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 > POM. > [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] [site:site] > [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for > updates from java.net > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Can't find bundle for base name site-plugin, locale en > [INFO] > > [INFO] Trace > java.util.MissingResourceException: Can't find bundle for base name > site-plugin, locale en > at > org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394) > at > org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157) > at > org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206) > at > org.apache.maven.plugins.site.AbstractSiteMojo.populateReportsMenu(AbstractSiteMojo.java:412) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateDocuments(AbstractSiteRenderingMojo.java:608) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:116) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:95) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:435) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:391) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:178) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:797) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:404) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > [INFO] > > [INFO] Total time: 11 seconds > [INFO] Finished at: Mon Dec 18 10:50:
[jira] Commented: (MSITE-202) Language bundle not found for empty pom project
[ http://jira.codehaus.org/browse/MSITE-202?page=comments#action_83183 ] Arik Kfir commented on MSITE-202: - Ooops - strike that: I was accidently using Maven 2.1 (I know 2.1 had some problems with the site plugin lately... I think Jason is working on it). > Language bundle not found for empty pom project > --- > > Key: MSITE-202 > URL: http://jira.codehaus.org/browse/MSITE-202 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Kenney Westerhof > > for a POM project, no modules, no src/site, the following error is generated: > Added 'maven-site-plugin/src/test/projects/site-plugin-test13/'. > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - > org.apache.maven.plugins.site-plugin-test:site-plugin-test12:pom:1.0 > [INFO]task-segment: [site] > [INFO] > > [WARNING] Unable to get resource > 'org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT' from repository > java.net (https://maven-repository.dev.java.net/nonav/repository/) > [WARNING] POM for 'commons-collections:commons-collections:pom:3.1:runtime' > is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 > POM. > [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] [site:site] > [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for > updates from java.net > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Can't find bundle for base name site-plugin, locale en > [INFO] > > [INFO] Trace > java.util.MissingResourceException: Can't find bundle for base name > site-plugin, locale en > at > org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394) > at > org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157) > at > org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206) > at > org.apache.maven.plugins.site.AbstractSiteMojo.populateReportsMenu(AbstractSiteMojo.java:412) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateDocuments(AbstractSiteRenderingMojo.java:608) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:116) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:95) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:435) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:391) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:178) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:797) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:404) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > [INFO] > > [INFO] Total time: 11 seconds > [INFO] Finished at:
[jira] Created: (MIDEA-82) [Patch] EJB module packaging is not generated correctly, and also does not support EJB 3.0
[Patch] EJB module packaging is not generated correctly, and also does not
support EJB 3.0
--
Key: MIDEA-82
URL: http://jira.codehaus.org/browse/MIDEA-82
Project: Maven 2.x Idea Plugin
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: All
Reporter: Arik Kfir
Priority: Critical
Attachments: MEJB-ejb3_and_ejb_deployment.patch
When the plugin generates an IML for a module of EJB packaging, IDEA's Ejb
Module Settings section is not generated correctly. The dependencies themselves
are generated fine, but the settings for how they are deployed is wrong.
Each EJB module in IDEA has an EJB Module Settings tab where each of the EJB
module's dependencies is configured for deployment (link via manifest, target
directory in the EAR, etc). Currently, the plugin specifies "WEB-INF/classes"
as the target directory for each dependency, which is obviously wrong.
Attached is a patch which does:
1. Adds the "ideaVersion" parameter to the IdeaModuleMojo. This is needed so
that the "name" attribute of a module is not added to it in IDEA 6.x (other
version will receive it as before)
2. Extracts the "ejbVersion" parameter from the "maven-ejb-plugin"
configuration in the pom (if present). If not available, defaults to "2.x" as
before. If present and equals "3.0", will mark the ejb-jar.xml as such and make
it optional (as the ejb spec specified).
3. Fixes EJB deployment directory for ejb modules' dependencies from
"/WEB-INF/classes" to "/lib/.jar". This is consistent with the JEE
spec.
4. Adds the missing element for each dependency of EJB modules, pointing
to the local repo.
5. Adds a new method "getJarUrl" which accepts a File instance and returns an
IDEA-style URL ("jar://!/") and modified the "getLibraryUrl" method to
use the new method. This was required for cases when you don't have an Artifact
instance in hand.
6. In IdeaMojo, pass "ideaVersion" to the IdeaModuleMojo instance (see 1)
7. Updates IdeaModuleTest.java to accomodate new changes
--
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: (MIDEA-82) [Patch] EJB module packaging is not generated correctly, and also does not support EJB 3.0
[ http://jira.codehaus.org/browse/MIDEA-82?page=comments#action_84267 ]
Arik Kfir commented on MIDEA-82:
Hi,
The $MAVEN_REPO$ is a macro (idea feature, much like path variables in eclipse)
which points to the local maven repository. The user has to configure such a
variable to point to ~/.m2/repository. If the user wants to use a different
repo, he/she simply change the variable. This is not mandatory, but makes
things more modular...
Regarding 3 - the same thing is valid for J2EE 1.3/4, only in JEE5 all JARs in
"/lib" are automatically "classpath'ed" for all wars/ejbs/etc. In 1.3/4, the
war/ejbs need to reference these JARs in their MANIFEST.MF (using "Class-Path"
directive). The fix is valid regardless of J2EE version, as no
"WEB-INF/classes" dir can exist in EAR files anyway (even in 1.3/4) - I think
it's simply a forgotten copy/paste bug.
> [Patch] EJB module packaging is not generated correctly, and also does not
> support EJB 3.0
> --
>
> Key: MIDEA-82
> URL: http://jira.codehaus.org/browse/MIDEA-82
> Project: Maven 2.x Idea Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: All
>Reporter: Arik Kfir
> Assigned To: Stephane Nicoll
>Priority: Critical
> Attachments: MEJB-ejb3_and_ejb_deployment.patch
>
>
> When the plugin generates an IML for a module of EJB packaging, IDEA's Ejb
> Module Settings section is not generated correctly. The dependencies
> themselves are generated fine, but the settings for how they are deployed is
> wrong.
> Each EJB module in IDEA has an EJB Module Settings tab where each of the EJB
> module's dependencies is configured for deployment (link via manifest, target
> directory in the EAR, etc). Currently, the plugin specifies "WEB-INF/classes"
> as the target directory for each dependency, which is obviously wrong.
> Attached is a patch which does:
> 1. Adds the "ideaVersion" parameter to the IdeaModuleMojo. This is needed so
> that the "name" attribute of a module is not added to it in IDEA 6.x (other
> version will receive it as before)
> 2. Extracts the "ejbVersion" parameter from the "maven-ejb-plugin"
> configuration in the pom (if present). If not available, defaults to "2.x" as
> before. If present and equals "3.0", will mark the ejb-jar.xml as such and
> make it optional (as the ejb spec specified).
> 3. Fixes EJB deployment directory for ejb modules' dependencies from
> "/WEB-INF/classes" to "/lib/.jar". This is consistent with the
> JEE spec.
> 4. Adds the missing element for each dependency of EJB modules,
> pointing to the local repo.
> 5. Adds a new method "getJarUrl" which accepts a File instance and returns an
> IDEA-style URL ("jar://!/") and modified the "getLibraryUrl" method to
> use the new method. This was required for cases when you don't have an
> Artifact instance in hand.
> 6. In IdeaMojo, pass "ideaVersion" to the IdeaModuleMojo instance (see 1)
> 7. Updates IdeaModuleTest.java to accomodate new changes
--
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: (MIDEA-82) [Patch] EJB module packaging is not generated correctly, and also does not support EJB 3.0
[ http://jira.codehaus.org/browse/MIDEA-82?page=comments#action_84277 ]
Arik Kfir commented on MIDEA-82:
Sure:
$MAVEN_REPO$ - I guess you're right ;-)
About 5: if we drop the MAVEN_REPO thing, then 5 is no longer required (replace
all calls to the existing "getLibraryUrl" method instead. In fact, looking now
at the patch, it could be avoided all together anyway. It was intended for
cases when the caller has no Artifact instace, but I see now that in all
references, there is always an Artifact reference, so this method is not needed.
> [Patch] EJB module packaging is not generated correctly, and also does not
> support EJB 3.0
> --
>
> Key: MIDEA-82
> URL: http://jira.codehaus.org/browse/MIDEA-82
> Project: Maven 2.x Idea Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: All
>Reporter: Arik Kfir
> Assigned To: Stephane Nicoll
>Priority: Critical
> Attachments: MEJB-ejb3_and_ejb_deployment.patch
>
>
> When the plugin generates an IML for a module of EJB packaging, IDEA's Ejb
> Module Settings section is not generated correctly. The dependencies
> themselves are generated fine, but the settings for how they are deployed is
> wrong.
> Each EJB module in IDEA has an EJB Module Settings tab where each of the EJB
> module's dependencies is configured for deployment (link via manifest, target
> directory in the EAR, etc). Currently, the plugin specifies "WEB-INF/classes"
> as the target directory for each dependency, which is obviously wrong.
> Attached is a patch which does:
> 1. Adds the "ideaVersion" parameter to the IdeaModuleMojo. This is needed so
> that the "name" attribute of a module is not added to it in IDEA 6.x (other
> version will receive it as before)
> 2. Extracts the "ejbVersion" parameter from the "maven-ejb-plugin"
> configuration in the pom (if present). If not available, defaults to "2.x" as
> before. If present and equals "3.0", will mark the ejb-jar.xml as such and
> make it optional (as the ejb spec specified).
> 3. Fixes EJB deployment directory for ejb modules' dependencies from
> "/WEB-INF/classes" to "/lib/.jar". This is consistent with the
> JEE spec.
> 4. Adds the missing element for each dependency of EJB modules,
> pointing to the local repo.
> 5. Adds a new method "getJarUrl" which accepts a File instance and returns an
> IDEA-style URL ("jar://!/") and modified the "getLibraryUrl" method to
> use the new method. This was required for cases when you don't have an
> Artifact instance in hand.
> 6. In IdeaMojo, pass "ideaVersion" to the IdeaModuleMojo instance (see 1)
> 7. Updates IdeaModuleTest.java to accomodate new changes
--
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-17) Tests fail when running from parent
Tests fail when running from parent --- Key: MINSTALL-17 URL: http://jira.codehaus.org/browse/MINSTALL-17 Project: Maven 2.x Install Plugin Type: Bug Versions: 2.2 Environment: Fedora Core 5, JDK 1.5.0_06 Reporter: Arik Kfir Attachments: MINSTALL-tests-fail-on-parent-build.patch When executing "mvn clean install" from the "plugins" directory, above the "maven-install-plugin" dir, the new test-harness tests fail. The reason is that the basedir is now the "plugins" dir, rather than the "maven-install-plugin" dir. Edwin has fixed this for the idea-plugin - attached here is the patch for fixing this in the install 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: (MINSTALL-17) Tests fail when running from parent
[ http://jira.codehaus.org/browse/MINSTALL-17?page=comments#action_63043 ] Arik Kfir commented on MINSTALL-17: --- Perhaps the fix can be somehow propagated to the plugin-testing-harness, so that this won't have to be specified repeatedly for each test... > Tests fail when running from parent > --- > > Key: MINSTALL-17 > URL: http://jira.codehaus.org/browse/MINSTALL-17 > Project: Maven 2.x Install Plugin > Type: Bug > Versions: 2.2 > Environment: Fedora Core 5, JDK 1.5.0_06 > Reporter: Arik Kfir > Assignee: Allan Ramirez > Attachments: MINSTALL-tests-fail-on-parent-build.patch > > Original Estimate: 10 minutes > Remaining: 10 minutes > > When executing "mvn clean install" from the "plugins" directory, above the > "maven-install-plugin" dir, the new test-harness tests fail. The reason is > that the basedir is now the "plugins" dir, rather than the > "maven-install-plugin" dir. > Edwin has fixed this for the idea-plugin - attached here is the patch for > fixing this in the install 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: (MJAR-37) HttpJarSignClient - New goal "httpsign" which will sign jar files by submitting them to a signing service via HTTP Post
[ http://jira.codehaus.org/browse/MJAR-37?page=comments#action_63496 ] Arik Kfir commented on MJAR-37: --- Just an idea - this can be a cool Plexus component (JAR signing, that is...especially by HTTP) > HttpJarSignClient - New goal "httpsign" which will sign jar files by > submitting them to a signing service via HTTP Post > --- > > Key: MJAR-37 > URL: http://jira.codehaus.org/browse/MJAR-37 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: David Boden > Attachments: jar-plugin-newfiles.zip, jarplugin.diff > > > The patch and new files attached to this issue are newer and make the > contributions in MJAR-35 obsolete. > There is a test pom.xml that you can do a "mvn install" on to see the new > goal working. -- 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: (CONTINUUM-37) Add a professional user interface
[ http://jira.codehaus.org/browse/CONTINUUM-37?page=comments#action_64237 ] Arik Kfir commented on CONTINUUM-37: I think a better alternative would be a Swing interface to be launched via Java Web Start. > Add a professional user interface > - > > Key: CONTINUUM-37 > URL: http://jira.codehaus.org/browse/CONTINUUM-37 > Project: Continuum > Type: New Feature > Components: Web interface > Reporter: Emmanuel Venisse > Fix For: 1.1 > > > I'd like to see a professional interface with some flash components like a > Macromedia Flex interface. > Laszlo provides an open source implementation of this technology (CPL > License). http://www.laszlosystems.com/ > You can see some demo here (http://www.laszlosystems.com/demos/). > The screen creation is very simple, it a very simple xml. > I'll hope you'll be interesting. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_64409 ] Arik Kfir commented on MNG-624: --- two more cents: imo the algoritm should do the following: (in specified order) 1. if a version is given, resolve it from reactor/repository 2. otherwise, if a path is given, use that 3. otherwise, if the project has an SCM, retrieve it from the scm (using same tag/branch/etc) 4. error > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Type: Improvement > Components: Inheritence and Interpolation > Reporter: Brett Porter > Assignee: Brett Porter > Priority: Blocker > Fix For: 2.1 > > Original Estimate: 4 hours > Remaining: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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-1330) direct support for mock classes
[ http://jira.codehaus.org/browse/MNG-1330?page=comments#action_64410 ] Arik Kfir commented on MNG-1330: I disagree - there are too many source dirs already, and the test-jar works perfectly...no need to complicate things, IMO. > direct support for mock classes > --- > > Key: MNG-1330 > URL: http://jira.codehaus.org/browse/MNG-1330 > Project: Maven 2 > Type: New Feature > Versions: 2.0 > Reporter: Jorg Heymans > Fix For: 2.1 > > > a element of some sort would allow projects to easily > deal with mock classes. > At the moment you would have to create a separate module myproject-mocks and > include it as a dependency in your project. -- 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: (MJAVADOC-69) javadoc plugin install fails when running "mvn install" from plugins dir
javadoc plugin install fails when running "mvn install" from plugins dir Key: MJAVADOC-69 URL: http://jira.codehaus.org/browse/MJAVADOC-69 Project: Maven 2.x Javadoc Plugin Type: Bug Environment: fedora core 5, jdk 1.5.0_06, x86 Reporter: Arik Kfir When running "mvn clean install" from the plugins dir (above the maven-javadoc-plugin dir) the plugin fails to build. Running the same command from inside the javadoc dir works fine. -- 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: (SCM-195) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/SCM-195?page=comments#action_65273 ] Arik Kfir commented on SCM-195: --- emmanuel: when the release plugin writes the modified pom back into svn (with the released version, etc), it also writes a wrong scm url (under the tag). The url that's written is the one of the parent pom, without the module's name appended to the "/trunk" - *even though* it was properly specified there before the release... when the child pom has no tag, it works well. > Wrong SCM info put by the release plugin for modules > > > Key: SCM-195 > URL: http://jira.codehaus.org/browse/SCM-195 > Project: Maven SCM > Type: Bug > Versions: 1.0-beta-3 > Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion SCM > Reporter: Arik Kfir > Fix For: 1.0 > > > Hi, > I have a project with several modules in it. The entire project is > stored in one SVN repository, in the following layout: > myproject > | > +-- module A > | > +-- module B > | > +-- . > The root pom has a url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own tag with a url such as > "http://svn.myserver/.../trunk/moduleA";, etc. > When running "release:prepare", the URL encoded back into the modules' POMs > (the back-to-trunk pom, not the released one) is the same URL as the root > POM, rather than the original module's SCM url. So module A's urls > would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory > appended to it (as it was before releasing). > Carlos has pointed out to me that the best practice for this use case is not > specifying the tag for the modules' POMs at all. He did, however, also > noted that it's still a bug - hence this JIRA ;-) > Cheers. -- 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
