[jira] Commented: (MAVENUPLOAD-1695) CC/PP API jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106624 ] Torsten Dettborn commented on MAVENUPLOAD-1695: --- Hi, i have fixed the pom. I'm not sure, if this is right. The license is inside the zip which contains the api and the zip is down loadable under http://java.sun.com/j2ee/ccpp/. > CC/PP API jar > - > > Key: MAVENUPLOAD-1695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1695 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Torsten Dettborn > > To enable interoperability between web servers and access mechanisms, and to > facilitate development of device independent web applications, this > specification will define a set of APIs for processing CC/PP information. > This is result from the jsr188. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-97) pieces of the pom are missing after using create-from-project
pieces of the pom are missing after using create-from-project - Key: ARCHETYPE-97 URL: http://jira.codehaus.org/browse/ARCHETYPE-97 Project: Maven Archetype Issue Type: Bug Affects Versions: NG-1.0-alpha-1 Reporter: Brian Fox After running create from project, i find pieces of the pom are missing. I noticed that the parent and modules sections are gone, along with comments. -- 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: (ARCHETYPE-87) create-from-project replaces too many things in the pom with variables
[
http://jira.codehaus.org/browse/ARCHETYPE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106620
]
Brian Fox commented on ARCHETYPE-87:
in multimodule archetypes, there isn't a way to update the names of the modules
and the sibling dependencies aren't updated. For example, i ran it on the
enforcer tree. When I create the project from the archetype, I rename the group
id to org.apache.maven.checker and the artifact to checker. The groups all get
updated, but inside i still have enforcer-rule, enforcer-api etc. The parent
pom artifactid does get changed to checker.
Also, there are still dependencies in the modules that point to
org.apache.maven.enforcer.
> create-from-project replaces too many things in the pom with variables
> --
>
> Key: ARCHETYPE-87
> URL: http://jira.codehaus.org/browse/ARCHETYPE-87
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
>Priority: Blocker
> Fix For: NG-1.0-alpha-1
>
>
> Using the maven-integration-test-sample project, and create-from-project, I
> find that the processed pom has every fragment of the group,artifactid and
> version replaced. It's not a safe assumption that everything with the same
> version (and other values) should be generic. For example, if my sample
> project has 1.0 as a version, every version 1.0 will be replaced, even if
> it's something completely unrelated to my project.
> Example output:
> {noformat}
>
> 4.0.0
> ${groupId}
> ${artifactId}
> ${version}
> Maven Integration Tests
>
>
> org.apache.maven.shared
> maven-verifier
> 1.0
>
>
> org.apache.maven.its
> maven-integration-test-helper
> ${version}
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1701. --- Assignee: Carlos Sanchez Resolution: Fixed > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible >Assignee: Carlos Sanchez > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106612 ] Matt Raible commented on MAVENUPLOAD-1701: -- After blowing away my local repository, I was able to get this to work. I suspect I wasn't able to get it to work in the past because of the http://jira.codehaus.org/browse/MNG-2432? Who knows. > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106611 ] Matt Raible commented on MAVENUPLOAD-1701: -- Nope, that's not how it works - at least not on my machine with Maven 2.0.7. I tried changing the appfuse-maven-plugin to have a groupId of org.appfuse.mojo and then installed it locally. I then tried changing an appfuse-generated project from using org.codehaus.mojo as the groupId (for the plugin). The result is that it doesn't find the plugin: [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.codehaus.mojo:appfuse-maven-plugin' does not exist or no valid version could be found Conclusion: If I want to publish the appfuse-maven-plugin in the central repo, I need to move the code to Codehaus. > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106609 ] Carlos Sanchez commented on MAVENUPLOAD-1701: - AFAIK if you have a plugin in the section of the pom you can use it the short way > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1682. - Resolution: Duplicate Fix Version/s: (was: 2.1) great! > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows NT; JDK 1.5 >Reporter: Nigel Magnay > Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- 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: (DOXIA-136) Create an FML DTD or XSD
[ http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-136: -- Fix Version/s: (was: 1.0-alpha-9) 1.0-beta-1 > Create an FML DTD or XSD > > > Key: DOXIA-136 > URL: http://jira.codehaus.org/browse/DOXIA-136 > Project: Maven Doxia > Issue Type: Task > Components: Module - Fml >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0-beta-1 > > > Review the M1 FAQ schema is certainly a good start. > http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd -- 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-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106606 ] Jesse McConnell commented on CONTINUUM-358: --- sample conf is in the application.xml now > User Authentication via LDAP > > > Key: CONTINUUM-358 > URL: http://jira.codehaus.org/browse/CONTINUUM-358 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Frank Zhao >Assignee: Jesse McConnell > Fix For: 1.1-beta-3 > > > Please add LDAP support for the user authentication in Continuum user > management function. -- 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: (MASSEMBLY-125) add mojo for creating a source bundle
[ http://jira.codehaus.org/browse/MASSEMBLY-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106605 ] Kalle Korhonen commented on MASSEMBLY-125: -- Agree, assembly should have a support for classifiers. My use case is creating a user-downloadable distro that should contain *-sources.jars and javadoc.jars. Currently using dependencies:copy-dependencies to fetch all dependencies (it doesn't have an includes/excludes), then using fileSets in an assembly to package a few of them selectively into the distro. Would be much cleaner if I could use classifiers with a dependencySet. > add mojo for creating a source bundle > - > > Key: MASSEMBLY-125 > URL: http://jira.codehaus.org/browse/MASSEMBLY-125 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Reporter: Ovidio Mallo > Fix For: 2.2-beta-2 > > > I think it would be nice to have some mojo "source:jar-with-dependencies" or > something similar which not only includes the artifact's sources into the JAR > but also those of its transitive dependencies. This would e.g. allow to > create a source bundle for an assembly created with Maven. > As a concrete example, the "Maven 2.x Plugin for Eclipse" project, which is > no Maven but a simple PDE project, uses the MavenEmbedder assembly. There, it > would be very handy to also have such a source bundle to attach to the > assembly JAR file inside Eclipse for developing and especially for debugging. > Would there maybe be any interest (beside my single use case :-)) in such a > feature? If so, I would eventually give it a try myself if I find the time... -- 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: (MASSEMBLY-125) add mojo for creating a source bundle
[ http://jira.codehaus.org/browse/MASSEMBLY-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106604 ] Daniel Siegmann commented on MASSEMBLY-125: --- I have found the lack of such support to be a severe deficiency. I have an assembly descriptor which combines some (but not all) of the dependencies into one jar. However, I need to be able to deliver an analogous source jar. It is possible to work around this (with dependency:copy and some ant scripting), but it doesn't work very well. I suggest an enhancement be made to the dependencySet includes section so a classifier may be explicitly specified. This will provide flexibility to work not only for sources, but also for other types of jars (such as javadoc). I would be happy to provide an example, if desired. > add mojo for creating a source bundle > - > > Key: MASSEMBLY-125 > URL: http://jira.codehaus.org/browse/MASSEMBLY-125 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Reporter: Ovidio Mallo > Fix For: 2.2-beta-2 > > > I think it would be nice to have some mojo "source:jar-with-dependencies" or > something similar which not only includes the artifact's sources into the JAR > but also those of its transitive dependencies. This would e.g. allow to > create a source bundle for an assembly created with Maven. > As a concrete example, the "Maven 2.x Plugin for Eclipse" project, which is > no Maven but a simple PDE project, uses the MavenEmbedder assembly. There, it > would be very handy to also have such a source bundle to attach to the > assembly JAR file inside Eclipse for developing and especially for debugging. > Would there maybe be any interest (beside my single use case :-)) in such a > feature? If so, I would eventually give it a try myself if I find the time... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3192) Properties not effective in inherited elements in child projects
Properties not effective in inherited
elements in child projects
Key: MNG-3192
URL: http://jira.codehaus.org/browse/MNG-3192
Project: Maven 2
Issue Type: Bug
Reporter: John Allen
Setting to either true or false in a
parent project section will control whether or not that report is
inherited by a child. Changing the value of to be an expression,
such as ${inheritThisReport} and setting that property in the parent POM to
either true or false, prevents the report from appearing in all children
regardless or its value.
--
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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106603 ] Matt Raible commented on MAVENUPLOAD-1701: -- In a project (or archetype's) pom.xml, can I specify a ? AFAIK, it's only possible to do this in settings.xml. Therefore, if this plugin has an org.appfuse.plugins groupId, users will have to 1) modify settings.xml or 2) use the fully-qualified command. Correct? > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106602 ] Carlos Sanchez commented on MAVENUPLOAD-1701: - they can use appfuse:* in any project that has a pom if it doesn't it's likely gonna be only once and I don't see a big deal on copying and pasting the command line but definitely yes, you can only deploy to org.codehaus.mojo from the mojo project > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106601
]
Sebastian Annies commented on CONTINUUM-1402:
-
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDirectory.list();
> if ( files == null || files.length == 0 )
> {
> // We need to force so checkout to an empty directory will work.
> command.createArgument().setValue( "-f" );
> }
> // Not sure what to do here. I'm unclear whether we should be
> // sync'ing each file individually to the label or just sync the
> // entire contents of the workingDir. I'm going to assume the
> // latter until the exact semantics are clearer.
> if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
> {
> command.createArgument().setValue( "@" + version.getName() );
> }
> return command;
> {{monospaced}}
> The {{monospaced}}specname {{monospaced}} contains the backslashes and is
> these are neither escaped nor quoted! Hmm ... Is that a job that the
> CommandLine should handle? I think so!
> The next thing I will do is to file an issue at plexus-utils and link the
> issues.
--
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: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106601
]
Sebastian Annies edited comment on CONTINUUM-1402 at 9/5/07 4:40 PM:
-
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
Concerning single quotes:
If the maven-scm provider adds the single quotes - what about windows then?
was:
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDirectory.list();
> if ( files == null || files.length == 0 )
> {
> // We need to force so checkout to an empty directory will work.
> command.createArgument().setValue( "-f" );
> }
> // Not sure what to do here. I'm unclear whether we should be
> // sync'ing each file individually to the label or just sync the
> // entire contents of the workingDir. I'm going to assume the
> // latter until the exact semantics are clearer.
> if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
> {
> command.createArgument().setValue( "@" + version.getName() );
> }
> return command;
> {{monospaced}}
> The {{monospaced}}specname {{monospaced}} contains the backslashes and is
> these are neither escaped nor quoted! Hmm ... Is that a job that the
> CommandLine should handle? I think so!
> The next thing I will do is to file an issue at plexus-utils and link the
> issues.
--
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-144) Cannot generate Javadoc on Mac OS X if path contains space characters
Cannot generate Javadoc on Mac OS X if path contains space characters - Key: MJAVADOC-144 URL: http://jira.codehaus.org/browse/MJAVADOC-144 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Maven version: 2.0.7 Java version: 1.5.0_07 OS name: "mac os x" version: "10.4.10" arch: "i386" Reporter: Claes Buckwalter Running 'mvn javadoc:javadoc' fails if the path to the current directory contains a space character. It works with the 2.0 version of the plugin. It also works if I rename the directory so that it does not contain a space character. presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'javadoc'. [INFO] [INFO] Building The Elk Framework [INFO]task-segment: [javadoc:javadoc] (aggregator-style) [INFO] [INFO] Preparing javadoc:javadoc [INFO] [INFO] Building The Elk Framework [INFO] [INFO] No goals needed for project - skipping [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on => 'false'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] Setting property: resource.manager.logwhenfound => 'false'. [INFO] ** [INFO] Starting Jakarta Velocity v1.4 [INFO] RuntimeInstance initializing. [INFO] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader [INFO] ClasspathResourceLoader : initialization starting. [INFO] ClasspathResourceLoader : initialization complete. [INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [INFO] Default ResourceManager initialization complete. [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [INFO] Created: 20 parsers. [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [javadoc:javadoc] 1 error [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - cannot read options (No such file or directory) Command line was:"cd /Users/clabu/Documents/workarea/Elk API/target/site/apidocs && /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc" @options @packages [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - cannot read options (No such file or directory) Command line was:"cd /Users/clabu/Documents/workarea/Elk API/target/site/apidocs && /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc" @options @packages at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(Default
[jira] Created: (MSOURCES-22) configuration option for source:jar to exclude resources
configuration option for source:jar to exclude resources Key: MSOURCES-22 URL: http://jira.codehaus.org/browse/MSOURCES-22 Project: Maven 2.x Source Plugin Issue Type: Improvement Affects Versions: 2.0.3 Reporter: Daniel Siegmann Priority: Minor A typical use case for the source jar is attachment in an IDE, which allows for access to javadocs, and debugging. For this case there is no need to include resources in the source jar, as they will already be in the standard jar. This does not create any errors, but it may be inconvenient if a project includes large resources, such as images. It would be useful to provide a configuration option which allows the resources to be excluded. -- 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: (CONTINUUM-522) IRC support needed for IRC servers not supporting /privmsg
[ http://jira.codehaus.org/browse/CONTINUUM-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-522: --- After tests there is a trouble with this patch if two or more projectNotifiers use the same irc host / channel / nick. > IRC support needed for IRC servers not supporting /privmsg > -- > > Key: CONTINUUM-522 > URL: http://jira.codehaus.org/browse/CONTINUUM-522 > Project: Continuum > Issue Type: Improvement > Components: Notifier - IRC >Affects Versions: 1.0.2 > Environment: Linux >Reporter: Daniel Kulp >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-522 > > > The IRC server we use in house does not support /privmsg for any non-operator > user. The IS folks are refusing to add any other operators for use by the > continuum builds. > It would be nice if we could configure the IRC notifier to do a normal: > /join #channel > and then a normal text message is sent. -- 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: (NMAVEN-67) Mono does not allow creation of a new app domain manager: submit a bug and test cases to the mono project
[ http://jira.codehaus.org/browse/NMAVEN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed NMAVEN-67. -- Resolution: Fixed Submitted the bug: http://bugzilla.ximian.com/show_bug.cgi?id=82711 > Mono does not allow creation of a new app domain manager: submit a bug and > test cases to the mono project > - > > Key: NMAVEN-67 > URL: http://jira.codehaus.org/browse/NMAVEN-67 > Project: NMaven > Issue Type: Task > Environment: Mono >Reporter: Shane Isbell > > Mono does not support the use of the APPDOMAIN_MANAGER_ASM and > APPDOMAIN_MANAGER_TYPE environment variables to plugin a new app domain > manager. This impact is: 1) developers can't write Maven plugins in .NET; and > 2) NMaven plugins like the solution generator can't be executed in Mono > runtime. Submit a bug and test cases to the mono 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-3178) Talk with list about distributionManagement/status. What is this actually for?
[
http://jira.codehaus.org/browse/MNG-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106593
]
Carlos Sanchez commented on MNG-3178:
-
that was there since 2.0 to fail if a local pom has the
value
The value is set by the deploy plugin. If the validation is needed it should be
somewhere else
> Talk with list about distributionManagement/status. What is this actually for?
> --
>
> Key: MNG-3178
> URL: http://jira.codehaus.org/browse/MNG-3178
> Project: Maven 2
> Issue Type: Task
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
>
> After pushing more exceptions up to the top this chunk of code is failing:
> if ( checkDistributionManagementStatus )
> {
> if ( ( project.getDistributionManagement() != null ) && (
> project.getDistributionManagement().getStatus() != null ) )
> {
> String projectId = safeVersionlessKey( project.getGroupId(),
> project.getArtifactId() );
> throw new ProjectBuildingException( projectId,
> "Invalid project file: distribution status must not be
> specified for a project outside of the repository" );
> }
> }
> And I don't think it's needed.
--
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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106588 ] Matt Raible commented on MAVENUPLOAD-1701: -- I'm trying to make it possible to allow end users to run "appfuse:*" without further modifying their system. Modifying their settings.xml is a pain and I don't want to make them do that. If they're new to Maven, that's an overwhelming step for newbies. Also, using "org.appfuse.plugins:appfuse:gen" is way too verbose. So I guess my options are 1) Move the plugin to codehaus or 2) continue hosting the plugin in AppFuse's repo? Thanks, Matt > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106587 ] Carlos Sanchez commented on MAVENUPLOAD-1701: - what are you exactly trying to do? in the pom you can put the groupId you want For goals that can run without poms you can use pluginGroups in the settings.xml http://maven.apache.org/settings.html or the commandline mvn groupId:artifactId:version:goal > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1705) Sync script with cedarsoft.eu
Sync script with cedarsoft.eu - Key: MAVENUPLOAD-1705 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1705 Project: maven-upload-requests Issue Type: New Feature Reporter: Johannes Schneider #!/bin/sh CONTACT="[EMAIL PROTECTED]" MODE=rsync_ssh [EMAIL PROTECTED]:/home/maven/public/release GROUP_DIR=eu/cedarsoft Public key is in place. -- 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-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106584 ] Jochen Wiedmann commented on MNG-1682: -- Confirmed, Brett. My test project works fine with 2.0.7. > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows NT; JDK 1.5 >Reporter: Nigel Magnay > Fix For: 2.1 > > Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- 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-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106583 ] Emmanuel Venisse commented on CONTINUUM-358: continuum 1.1-beta-3 uses now redback alpha-3 and support LDAP authentication. We need to write a sample conf in application.xml (in comments) > User Authentication via LDAP > > > Key: CONTINUUM-358 > URL: http://jira.codehaus.org/browse/CONTINUUM-358 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Frank Zhao >Assignee: Jesse McConnell > Fix For: 1.1-beta-3 > > > Please add LDAP support for the user authentication in Continuum user > management function. -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106582 ] Matt Raible commented on MAVENUPLOAD-1701: -- Is it possible to get the "appfuse" prefix working w/o the plugin having a org.codehaus.mojo groupId? > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106580 ] Carlos Sanchez commented on MAVENUPLOAD-1701: - definitely you can't publish to org.codehaus.mojo. You don't want other people to post to org.appfuse, right? ;) > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106579 ] Matt Raible commented on MAVENUPLOAD-1701: -- The reason we're in the org.codehaus group is because 1) we were hosted there and there were too many problems managing development at the SVN level and publishing code and 2) because if we're in this group, users don't have to type the full path to the plugin, they can simply use the "appfuse" prefix. If this is a deal-breaker, we're more than happy to keep hosting it at http://static.appfuse.org/repository. We're just trying to make things easier for our users. > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1701) Add scripts to sync AppFuse release repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106578 ] Carlos Sanchez commented on MAVENUPLOAD-1701: - you can't sync org.codehaus group, your plugin must be in in your group, or hosted in the codehaus mojo project > Add scripts to sync AppFuse release repository > -- > > Key: MAVENUPLOAD-1701 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Matt Raible > > Contegix manages the static.appfuse.org and they've confirmed the public key > is in place. > AppFuse Core: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/appfuse/ > AppFuse Maven Plugin: > - > #!/bin/sh > CONTACTS="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/var/www/appfuse-releases > GROUP_DIR=org/codehaus/mojo/ -- 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-1700) java exchange connector (jec-1.53_12.jar)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106576 ] eli hasson commented on MAVENUPLOAD-1700: - new bundle URL: http://javaexchangeconnector.googlepages.com/jec.jar > java exchange connector (jec-1.53_12.jar) > - > > Key: MAVENUPLOAD-1700 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1700 > Project: maven-upload-requests > Issue Type: Wish >Reporter: eli hasson > > new JEC version -- 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: (MAVENUPLOAD-1696) Please sync with locale4j repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1696. --- Assignee: Carlos Sanchez Resolution: Fixed > Please sync with locale4j repo > -- > > Key: MAVENUPLOAD-1696 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1696 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tom Cort >Assignee: Carlos Sanchez > > Please sync with locale4j's repo. locale4j is a library for working with > localization data and performing translations. The shell can be found at > http://locale4j.sourceforge.net/net.sf.locale4j.sh > The repo contains jars for binary, source and javadoc, release 1.1.1. > I'm already subscribed to the [EMAIL PROTECTED] list -- 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: (MAVENUPLOAD-1702) Tacos 4.1.0 release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1702. --- Assignee: Carlos Sanchez Resolution: Fixed > Tacos 4.1.0 release > --- > > Key: MAVENUPLOAD-1702 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1702 > Project: maven-upload-requests > Issue Type: Task >Reporter: Igor Drobiazko >Assignee: Carlos Sanchez > Attachments: tacos.sh > > > Please sync with the tacos repository. The script is attached. Thanks. -- 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: (MAVENUPLOAD-1704) Janino 2.5.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1704. --- Assignee: Carlos Sanchez Resolution: Fixed > Janino 2.5.10 > - > > Key: MAVENUPLOAD-1704 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1704 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mark Proctor >Assignee: Carlos Sanchez > Attachments: janino-2.5.10-bundle.jar > > -- 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-1703) maven-jetty-pluto-embedded-1.0-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106575 ] Carlos Sanchez commented on MAVENUPLOAD-1703: - group is .com but your domain is .no, group should be .no > maven-jetty-pluto-embedded-1.0-bundle > - > > Key: MAVENUPLOAD-1703 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1703 > Project: maven-upload-requests > Issue Type: Task >Reporter: Nils-Helge Garli > Attachments: maven-jetty-pluto-embedded-1.0-bundle.jar > > > http://boss.bekk.no/proximity/repository/private/maven-jetty-pluto-embedded-1.0-bundle.jar > A jar file with everything needed to set up pluto with jetty in a maven > project. The artifact doesn't really have a project site, but information > about it can be found at http://portletwork.blogspot.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] Commented: (MAVENUPLOAD-1700) java exchange connector (jec-1.53_12.jar)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106574 ] Carlos Sanchez commented on MAVENUPLOAD-1700: - ERROR 403: Forbidden You cannot view this group's content because you are not currently a member. Members must be approved before joining. Description: Java Exchange Connector Users Forum > java exchange connector (jec-1.53_12.jar) > - > > Key: MAVENUPLOAD-1700 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1700 > Project: maven-upload-requests > Issue Type: Wish >Reporter: eli hasson > > new JEC version -- 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-1695) CC/PP API jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106573 ] Carlos Sanchez commented on MAVENUPLOAD-1695: - license is missing in the pom > CC/PP API jar > - > > Key: MAVENUPLOAD-1695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1695 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Torsten Dettborn > > To enable interoperability between web servers and access mechanisms, and to > facilitate development of device independent web applications, this > specification will define a set of APIs for processing CC/PP information. > This is result from the jsr188. -- 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: (MAVENUPLOAD-1699) Please upload testaco 0.9.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1699. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload testaco 0.9.10 > > > Key: MAVENUPLOAD-1699 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1699 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Geir Hedemark >Assignee: Carlos Sanchez > -- 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-1698) Jericho HTML Parser 2.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106572 ] Carlos Sanchez commented on MAVENUPLOAD-1698: - missing license in pom > Jericho HTML Parser 2.5 > --- > > Key: MAVENUPLOAD-1698 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1698 > Project: maven-upload-requests > Issue Type: Task >Reporter: Martin Jericho > > Jericho HTML Parser is a simple but powerful java library allowing analysis > and manipulation of parts of an HTML document, including some common > server-side tags, while reproducing verbatim any unrecognised or invalid > HTML. Also provides high-level HTML form manipulation functions. -- 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: (MAVENUPLOAD-1697) Upload freemarker-2.3.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1697. --- Assignee: Carlos Sanchez Resolution: Won't Fix Already in org.freemarker group. It's relocated too > Upload freemarker-2.3.10 > > > Key: MAVENUPLOAD-1697 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1697 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Jochen Wiedmann >Assignee: Carlos Sanchez > > FreeMarker is a "template engine"; a generic tool to generate text output > based on templates. -- 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-1693) Upload truezip
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106569 ] Carlos Sanchez commented on MAVENUPLOAD-1693: - scm url is wrong, has to be the url to the source repository why de.schlichtherle.io groupId and not net.java.dev.truezip > Upload truezip > -- > > Key: MAVENUPLOAD-1693 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1693 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Asankha Perera > > http://people.apache.org/~asankha/temp/truezip-upload.jar > https://truezip.dev.java.net/ > TrueZIP is a Java based Virtual File System (VFS) which enables client > applications to access ZIP, TAR and derivative archive types transparently as > if they were just directories in a file's path name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-114) Different builds for ejb-client optional with parent
Different builds for ejb-client optional with parent Key: MWAR-114 URL: http://jira.codehaus.org/browse/MWAR-114 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Tim Reilly Attachments: mytime.zip When trying to package a j2ee project's ejb-client artifact in the ear /lib directory the war plugin's optional attribute is ignored if building from the parent app project. If you build from the parent project you get the ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, and ear independently you get the ejb-client packaged in the ear /lib directory. It seems when run from the parent project the dependency/artifact doesn't have the optional attribute set. Perhaps this is b/c the artifact is a project artifact that was attached from the ejb plugin it is not resolved as optional when the dependency is resolved from the war project. Attaching Geronimo's mytime sample with modifications to reproduce the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-189) plugin not correctly interpolating POM variables like project.build.directory
[
http://jira.codehaus.org/browse/MASSEMBLY-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106568
]
Patrick Vinograd edited comment on MASSEMBLY-189 at 9/5/07 12:55 PM:
-
Since it looks like the problem is that it is stripping off the "project" part
of the property, I was able to reference "${project.build.directory}" by
replacing it with "${project.project.build.directory}"
Unfortunately this will likely break once the bug is fixed.
was:
Since it looks like the problem is that it is stripping off the "project" part
of the property, I was able to reference "${project.build.directory}" by
replacing it with "${project.project.build.directory}"
> plugin not correctly interpolating POM variables like project.build.directory
> -
>
> Key: MASSEMBLY-189
> URL: http://jira.codehaus.org/browse/MASSEMBLY-189
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: I used both released version 2.1 and also 2.2-SNAPSHOT
>Reporter: Ray Suliteanu
>Priority: Critical
> Fix For: 2.2
>
>
> I have a assembly descriptor file with ${project.build.directory} in the
> element of a . I get an error "Failed to create assembly: File
> to filter not found" because the file path has "${project.build.directory}"
> rather than the value of ${project.build.directory}.
> I have traced the problem to AssemblyInterpolator.interpolateElementValue().
> It tries to look up build.directory in ReflectionValueExtractor.evaluate()
> rather than project.build.directory, and it can't evaluate build.directory. A
> hack workaround is ...
> if (value == null)
> {
> try
> {
> value = ReflectionValueExtractor.evaluate(realExpr, project);
> if (value == null)
> {
> // HACK: strip ${ and } and retry
> wholeExpr = wholeExpr.substring(2, wholeExpr.length() - 1);
> value = ReflectionValueExtractor.evaluate(wholeExpr, 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: (MASSEMBLY-189) plugin not correctly interpolating POM variables like project.build.directory
[
http://jira.codehaus.org/browse/MASSEMBLY-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106568
]
Patrick Vinograd commented on MASSEMBLY-189:
Since it looks like the problem is that it is stripping off the "project" part
of the property, I was able to reference "${project.build.directory}" by
replacing it with "${project.project.build.directory}"
> plugin not correctly interpolating POM variables like project.build.directory
> -
>
> Key: MASSEMBLY-189
> URL: http://jira.codehaus.org/browse/MASSEMBLY-189
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: I used both released version 2.1 and also 2.2-SNAPSHOT
>Reporter: Ray Suliteanu
>Priority: Critical
> Fix For: 2.2
>
>
> I have a assembly descriptor file with ${project.build.directory} in the
> element of a . I get an error "Failed to create assembly: File
> to filter not found" because the file path has "${project.build.directory}"
> rather than the value of ${project.build.directory}.
> I have traced the problem to AssemblyInterpolator.interpolateElementValue().
> It tries to look up build.directory in ReflectionValueExtractor.evaluate()
> rather than project.build.directory, and it can't evaluate build.directory. A
> hack workaround is ...
> if (value == null)
> {
> try
> {
> value = ReflectionValueExtractor.evaluate(realExpr, project);
> if (value == null)
> {
> // HACK: strip ${ and } and retry
> wholeExpr = wholeExpr.substring(2, wholeExpr.length() - 1);
> value = ReflectionValueExtractor.evaluate(wholeExpr, 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: (CONTINUUM-1433) Wrong path in descripton on how to allow the file protocol.
Wrong path in descripton on how to allow the file protocol. Key: CONTINUUM-1433 URL: http://jira.codehaus.org/browse/CONTINUUM-1433 Project: Continuum Issue Type: Bug Components: Documentation Affects Versions: 1.1-beta-2 Reporter: Erik Drolshammer Is the path in the FAQ entry at http://maven.apache.org/continuum/faqs.html#can-i-use-file-protocol-in-add-project-view wrong? In my installation the file is located at: $continuumHome/continuum-webapp/src/main/resources/META-INF/plexus/application.xml. -- 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: (SUREFIRE-353) Link to test JavaDoc in test repor
Link to test JavaDoc in test repor -- Key: SUREFIRE-353 URL: http://jira.codehaus.org/browse/SUREFIRE-353 Project: Maven Surefire Issue Type: New Feature Components: report plugin Reporter: Francois Loison Priority: Minor Current report could be improved by displaying functional information of test cases. For exemple: TestX : tests functionality X One way should be to document test case functionality in javadoc and add an hyperlink in surefire report to javadoc. If feature agreed, I could propose some code. [EMAIL PROTECTED] -- 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: (MCHANGES-84) Provide support for Mantis bug tracking system
[ http://jira.codehaus.org/browse/MCHANGES-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106560 ] Dennis Lundberg commented on MCHANGES-84: - I'd like for us to keep the general refactoring ideas and discussions on: http://jira.codehaus.org/browse/MCHANGES-85 > Provide support for Mantis bug tracking system > -- > > Key: MCHANGES-84 > URL: http://jira.codehaus.org/browse/MCHANGES-84 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature > Environment: Maven 2.x, >Reporter: Gabriel Ciuloaica > > Mantis bug tracking system provides API to access it remotely. So, I think it > will not be complicate to integrate it. > I will start working on providing support for Mantis in changes plugin by > tomorrow. There is anybody interest in this support or is there anybody > already begin work to integrate Mantis? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-136) Create an FML DTD or XSD
[ http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106558 ] Dennis Lundberg commented on DOXIA-136: --- Pushing it to a later release is fine by me. > Create an FML DTD or XSD > > > Key: DOXIA-136 > URL: http://jira.codehaus.org/browse/DOXIA-136 > Project: Maven Doxia > Issue Type: Task > Components: Module - Fml >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0-alpha-9 > > > Review the M1 FAQ schema is certainly a good start. > http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd -- 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-282) Replace the current 'arguments' parameter with specialized version for each mojo (eg. 'argumentsRelease')
Replace the current 'arguments' parameter with specialized version for each mojo (eg. 'argumentsRelease') - Key: MRELEASE-282 URL: http://jira.codehaus.org/browse/MRELEASE-282 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-6 Environment: mvn 2.0.7 WinXP Reporter: Marcel Schutte There is currently no way to configure the release:prepare and release:perform mojos with different values for the 'arguments' parameter. Brett said the solution should be to use unique names for the parameters [1] [2]. I am aware that it is possible to use profiles for this. However, I want to declare the default behavior in my pom, not leave it to the user to provide the correct profile. There is a workaround available [3], however, this means you have to duplicate the default values for and http://jira.codehaus.org/browse/MNG-1446 [2] http://jira.codehaus.org/browse/MCOMPILER-15 [3] http://jira.codehaus.org/browse/MRELEASE-59 [4] http://www.nabble.com/release-plugin-configuration-tf4377660s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1432) Continuum doesn't start up with the startup script for x86-64
Continuum doesn't start up with the startup script for x86-64 - Key: CONTINUUM-1432 URL: http://jira.codehaus.org/browse/CONTINUUM-1432 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-2 Environment: Fedora Core 6 x64 Reporter: Brian Cribbs Startup script fails silently but this is in the wrapper.log file INFO | jvm 1| 2007/09/05 11:12:11 | WARNING - Unable to load the Wrapper's native library 'libwrapper.so'. INFO | jvm 1| 2007/09/05 11:12:11 | The file is located on the path at the following location but INFO | jvm 1| 2007/09/05 11:12:11 | could not be loaded: INFO | jvm 1| 2007/09/05 11:12:11 | /opt/continuum-1.1-beta-2/bin/linux-x86-64/../../bin/linux-x86-64/libwrapper.so INFO | jvm 1| 2007/09/05 11:12:11 | Please verify that the file is readable by the current user INFO | jvm 1| 2007/09/05 11:12:11 | and that the file has not been corrupted in any way. INFO | jvm 1| 2007/09/05 11:12:11 | One common cause of this problem is running a 32-bit version -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106556 ] Scott Wintermute commented on MNG-553: -- I am thrilled to hear and see this issue will be looked into. I agree with others above that it should have been a higher priority for some time now (at least Major) as I have been waiting and hoping to see it implemented. I have personally had fairly significant issues in trying to work around this issue within our organization over the past year and a half while trying to spread the adoption of Maven2. Can't wait to see! > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 2.1 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3191) Filtering not applied to dependency POMs
Filtering not applied to dependency POMs
Key: MNG-3191
URL: http://jira.codehaus.org/browse/MNG-3191
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.7
Reporter: Eric Miles
I have a dependency in my project from a 3rd party, and it's deployed POM has a
dependency that is determined via filtering. IE:
${repository.database.driver.groupId}
${repository.database.driver.artifactId}
${repository.database.driver.version}
When I attempt to reference this dependency in the dependency section of my
project, I receive the following error while attempting to package:
[DEBUG] Retrieving parent-POM: com.jaspersoft.jasperserver:server::2.0.0
for project:
com.jaspersoft.jasperserver:jasperserver-export-tool-package:jar:2.0.0
from the repository.
[WARNING] POM for
'com.jaspersoft.jasperserver:jasperserver-export-tool-package:pom:2.0.0:compile'
is invalid. It will be ignored for artifact resolution. Reason: Failed to
validate POM for project
com.jaspersoft.jasperserver:jasperserver-export-tool-package at Artifact
[com.jaspersoft.jasperserver:jasperserver-export-tool-package:pom:2.0.0:compile]
[DEBUG] Reason: Failed to validate POM for project
com.jaspersoft.jasperserver:jasperserver-export-tool-package at Artifact
[com.jaspersoft.jasperserver:jasperserver-export-tool-package:pom:2.0.0:compile]
[DEBUG]
Validation Errors:
[DEBUG] 'dependencies.dependency.artifactId' with value
'${repository.database.driver.artifactId}' does not match a valid id
pattern.
[DEBUG] 'dependencies.dependency.groupId' with value
'${repository.database.driver.groupId}' does not match a valid id
pattern.
[DEBUG]
Even if I setup my settings to contain the 3 expression values, they are NOT
applied to the dependency. If I check the effective POM for my project, those
settings are seen so I know I have set it up appropriately.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2917) Ant classpath issue in maven 2.0.6
[ http://jira.codehaus.org/browse/MNG-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106543 ] Petr Kozelka commented on MNG-2917: --- I just want to confirm that this really helped to me too. In particular, adding the explicit ant-1.6.5 dependency made the difference. There must be some magic, because the maven-antrun-plugin, used by xdoclet-maven-plugin, itself depends on ant-1.6.5, but I didn't bother to explore it deeper. > Ant classpath issue in maven 2.0.6 > -- > > Key: MNG-2917 > URL: http://jira.codehaus.org/browse/MNG-2917 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Yuri Schimke >Priority: Critical > > This was working in 2.0.5. Unfortunately I'm guessing its related to the > woefully bad xdoclet-maven-plugin > The main error is that the xdoclet-maven-plugin can't find one of the ant > classes > Caused by: java.lang.NoClassDefFoundError: org/apache/tools/ant/PropertyHelper > - > this realm = app0.child-container[org.codehaus.mojo:xdoclet-maven-plugin] > urls[0] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/codehaus/mojo/xdoclet-maven-plugin/1.0-alpha-2/xdoclet-maven-plugin-1.0-alpha-2.jar > urls[1] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-wsee-module/1.2.3/xdoclet-wsee-module-1.2.3.jar > urls[2] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > urls[3] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jboss-module/1.2.3/xdoclet-jboss-module-1.2.3.jar > urls[4] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-xdoclet-module/1.2.3/xdoclet-xdoclet-module-1.2.3.jar > urls[5] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-orion-module/1.2.3/xdoclet-orion-module-1.2.3.jar > urls[6] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jmx-module/1.2.3/xdoclet-jmx-module-1.2.3.jar > urls[7] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-ibm-module/1.2.3/xdoclet-ibm-module-1.2.3.jar > urls[8] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[9] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-collections/commons-collections/2.1/commons-collections-2.1.jar > urls[10] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant/1.5.2/ant-1.5.2.jar > urls[11] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-apache-module/1.2.3/xdoclet-apache-module-1.2.3.jar > urls[12] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant-launcher/1.6.5/ant-l > auncher-1.6.5.jar > urls[13] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-fr_FR-locale/1.2.3/xdoclet-fr_FR-locale-1.2.3.jar > urls[14] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-objectweb-module/1.2.3/xdoclet-objectweb-module-1.2.3.jar > urls[15] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.0/maven-antrun-plugin-1.0.jar > urls[16] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-java-module/1.2.3/xdoclet-java-module-1.2.3.jar > urls[17] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-exolab-module/1.2.3/xdoclet-exolab-module-1.2.3.jar > urls[18] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-bea-module/1.2.3/xdoclet-bea-module-1.2.3.jar > urls[19] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-mvcsoft-module/1.2.3/xdoclet-mvcsoft-module-1.2.3.jar > urls[20] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-sun-module/1.2.3/xdoclet-sun-module-1.2.3.jar > urls[21] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-spring-module/1.2.3/xdoclet-spring-module-1.2.3.jar > urls[22] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-de-locale/1.2.3/xdoclet-de-locale-1.2.3.jar > urls[23] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/jboss/jboss-j2ee/3.2.1/jboss-j2ee-3.2.1.jar > urls[24] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar > urls[25] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-web-module/1.2.3/xdoclet-web-module-1.2.3.jar > urls[26] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-caucho-module/1.2.3/xdoclet-caucho-module-1.2.3.jar > urls[27] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jdo-module/1.2.3/xdoclet-jdo-module-1.2.3.jar > urls[28] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-tjdo-module/1.2.3/xdoclet-tjdo-module-1.2.3.jar > urls[29] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[30] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-openejb-module/1.2.3/xdoclet-openejb-module-1.2.3.jar > urls[31] = > file:/C:/Docume~1/nbk7xsp/.m2/rep
[jira] Created: (MRELEASE-281) Pom version is not modified during release:branch goal
Pom version is not modified during release:branch goal -- Key: MRELEASE-281 URL: http://jira.codehaus.org/browse/MRELEASE-281 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: maven 2.0.6 Reporter: Franck HUGOT When I perform release:branch I have 3 problems : - FirstI have to specify the branch name on the command line (I don't want to have it in my pom to commit it!), why it don't ask me for the branche name as for the release:prepare goal? - Secondly, the most important, the version in the pom () is not modified. It should also work as the release:prepare goal. - To finish, the documentation on the web site talks about tag, I think you should talk about branch (http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html) I think this goal (release:branch) should have the same behavior as the release:prepare because the same actions have to be performed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3190) Need to fix hyperlinks at top of Getting Started Guide
Need to fix hyperlinks at top of Getting Started Guide -- Key: MNG-3190 URL: http://jira.codehaus.org/browse/MNG-3190 Project: Maven 2 Issue Type: Bug Components: Documentation: Guides Affects Versions: Documentation Deficit Reporter: Glen Mazza Priority: Minor Hello, the hyperlinks under the "Sections" heading at the top of http://maven.apache.org/guides/getting-started/index.html do not work--something is wrong with their anchor values. If these hyperlinks could be fixed, it would be a *great* help. -- 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-1755) Improve support for in reactor builds
[ http://jira.codehaus.org/browse/MNG-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106533 ] Mike Perham commented on MNG-1755: -- I don't know what the Maven dev schedule looks like so I can't really comment yes or no. This issue is not really critical to us but it does help Maven scale to larger teams and module layouts. It's also a POM change so it's good to get in as early as possible. Perhaps you could update the POM schema to allow a element but not implement the code for it yet (i.e. just ignore it for now) and that way you could add the feature in the future without breaking POM compatibility? > Improve support for in reactor builds > -- > > Key: MNG-1755 > URL: http://jira.codehaus.org/browse/MNG-1755 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: Mike Perham > Fix For: 2.1 > > > I would like to see something like added which acts > similarly to the other management elements in the POM. This would allow a > top-level project POM to list all the developers, their orgs, timezones, > emails, etc and child projects to reference just the ID and the developers > role in that module. Something like this: > parent's pom.xml: > > > msanchez > Matt Sanchez > [EMAIL PROTECTED] > http://priori.webify.local:9090/display/~msanchez > -6 > > > mperham > Mike Perham > [EMAIL PROTECTED] > http://priori:9090/display/~mperham > -6 > > > foo's pom.xml: > > > mperham > > Owner > > > > Our management wants to have one or two clear-cut owners for each module and > we would like to use maven to document those owners but the current impl is > terribly redundant since developers are not inherited. -- 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: (MPMD-62) pmd:check and pmd:cpd-check should print error details to stderr upon failure
[ http://jira.codehaus.org/browse/MPMD-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106532 ] Marat Radchenko commented on MPMD-62: - Some additions: This behavior can be disabled by default for backward-compatibility. And true attribute should be added to enable this behavior. > pmd:check and pmd:cpd-check should print error details to stderr upon failure > - > > Key: MPMD-62 > URL: http://jira.codehaus.org/browse/MPMD-62 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Affects Versions: 2.2 >Reporter: Marat Radchenko > > It would be wonderful if maven-pmd-plugin printed error details to stderr > when pmd:check or pmd:cpd-check fails. > This way it would be consistent with maven-checkstyle-plugin and maybe some > others. > Currentry we are having usability troubles when pmd:check fails on CI server > because we cannot see errors in build log. -- 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: (MPMD-62) pmd:check and pmd:cpd-check should print error details to stderr upon failure
pmd:check and pmd:cpd-check should print error details to stderr upon failure - Key: MPMD-62 URL: http://jira.codehaus.org/browse/MPMD-62 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: CPD, PMD Affects Versions: 2.2 Reporter: Marat Radchenko It would be wonderful if maven-pmd-plugin printed error details to stderr when pmd:check or pmd:cpd-check fails. This way it would be consistent with maven-checkstyle-plugin and maybe some others. Currentry we are having usability troubles when pmd:check fails on CI server because we cannot see errors in build log. -- 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-570) Plugin description and i18n
[ http://jira.codehaus.org/browse/MNG-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106524 ] Vincent Siveton commented on MNG-570: - A first draft: http://docs.codehaus.org/display/MAVEN/I18N+Plugin+Description > Plugin description and i18n > --- > > Key: MNG-570 > URL: http://jira.codehaus.org/browse/MNG-570 > Project: Maven 2 > Issue Type: Improvement > Components: Plugin Creation Tools >Affects Versions: 2.0-beta-1 >Reporter: Vincent Siveton > Fix For: 2.1 > > > Actually, classic javadoc is used for mojo description. > How to handle i18n description? -- 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-340) VSS Provider fails during check out when project path contains spaces
VSS Provider fails during check out when project path contains spaces
-
Key: SCM-340
URL: http://jira.codehaus.org/browse/SCM-340
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-vss
Affects Versions: 1.0
Environment: Windows XP, JRE 1.4.2
Reporter: Allan Lang
VSS Provider fails during check out if project path contains a space. For
example, using the following SCM URL:
{{scm:vss|[EMAIL PROTECTED]|/top path}}
This results in the following output:
{code}
Executing: "c:\program files\microsoft visual studio\vss\win32\ss" Get
"$/project root" -Yguest -R -I- -GWR
Working directory: c:\temp\fiddler
Provider message:
The vss command failed.
Command output:
'c:\program' is not recognized as an internal or external command,
operable program or batch file.
java.lang.Exception: Command failed.The vss command failed.
at com.goongo.vssscmtest.MyTest.checkResult(MyTest.java:125)
at com.goongo.vssscmtest.MyTest.checkOut(MyTest.java:75)
at com.goongo.vssscmtest.MyTest.main(MyTest.java:29)
Exception in thread "main"
{code}
This appears to be due to a bug in plexus-utils-1.1. If this dependency is
updated to v1.4 (or later) this error is fixed.
Therefore, resolution is to update dependency in pom.xml of maven-scm 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] Updated: (MNG-2296) Display what has changed since last release upon updating a plugin to a new version
[ http://jira.codehaus.org/browse/MNG-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-2296: -- Fix Version/s: (was: 2.1) 2.x > Display what has changed since last release upon updating a plugin to a new > version > --- > > Key: MNG-2296 > URL: http://jira.codehaus.org/browse/MNG-2296 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Cédric Vidal > Fix For: 2.x > > > Today, when a new version of a plugin is released, it is automatically > downloaded and this is great because it keeps you up to date. For example, > this morning, a new version of the WAR plugin was released on ibiblio (I had > 2.0-beta-2 previously), I got the following trace: > -- > [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for > updates from ibiblio > Downloading: > http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom > 1/1K > 1K downloaded > Downloading: > http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar > 1/21K > 21/21K > 21K downloaded > -- > The thing is I got no clue whatsoever of what has changed between versions > 2.0-beta-2 and 2.0. If I want to know was has changed, I have to manually go > on the maven site or in the JIRA to figure out what has changed. > It would be great if the list of changes that occured between between the > version which was previously locally installed and the newly installed was > displayed upon update as part of the build. > The trace could be: > -- > [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for > updates from ibiblio > Downloading: > http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom > 1/1K > 1K downloaded > Downloading: > http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar > 1/21K > 21/21K > 21K downloaded > [INFO] Changes that occured between version 2.0-beta-2 and 2.0 are: > o Added blah blah. > o Corrected bug blah blah. > o Removed blah blah. > -- > This feature might depend on adding the list of changes to the POM, which > might be an issue since Maven is stable now. But that might not be such a bug > deal since that POM information would most likely be optional. > The changes part of the POM could be structured like Maven 1 Changes plugin's > changes.xml file: > http://maven.apache.org/maven-1.x/plugins/changes/ > > > > Blah blah. > > > > > Added blah blah. > > > Corrected bug blah blah. > >due-to-email="[EMAIL PROTECTED]"> > Removed blah blah. > > > -- 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-2329) contribution: PluginClasspathTask (renamed from PluginDependencyTask)
[ http://jira.codehaus.org/browse/MNG-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-2329: -- Fix Version/s: (was: 2.1) 2.x > contribution: PluginClasspathTask (renamed from PluginDependencyTask) > - > > Key: MNG-2329 > URL: http://jira.codehaus.org/browse/MNG-2329 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Erik Romson > Fix For: 2.x > > Attachments: maven-artifact-ant.zip > > > I need to run ant tasks outside of maven2, because we use ant to populate > databases, generate reports etc from the database. Without going into any > discussions on the appropriate usage of ant, I needed to be able to get hold > of the classpath for plugins. I made a task for it. > Copy - paste of DependencyTask basically. -- 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-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106518 ] Arnaud Heritier commented on MSITE-256: --- I'll downgrade in some hours the plugin version on my project, thus my site will be fixed, but the bug always here > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-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] Updated: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSITE-256: -- Attachment: screenshot-2.jpg This is what the CI generates > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-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] Updated: (MNG-2348) add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often
[ http://jira.codehaus.org/browse/MNG-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-2348: -- Fix Version/s: (was: 2.1) 2.x > add a simple command line alias for -Dmaven.test.skip=true as I find myself > typing it very very often > - > > Key: MNG-2348 > URL: http://jira.codehaus.org/browse/MNG-2348 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.4 >Reporter: james strachan > Fix For: 2.x > > > Could we have some simple alias on the command line to disable unit tests > just like we have maven -o for offline. > Don't much mind what it is - how about... > -nt --no-testsDisables the junit tests in this build > so to do a build without unit tests > mvn -nt install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Le Clerc updated MSITE-211: --- Attachment: MSITE-211.patch Here is a proposed patch that : - get the proxy asociated with the repository access protocol : wagonManager.getProxy( repository.getProtocol() ) - check that the reposotory host is not in proxy nonProxyHosts list - SiteDeployMojoTest JUnit test case to test proxy selection Hope this helps, Cyrille > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > Attachments: MSITE-211.patch > > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > 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:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 > [INFO] Final Memory: 3M/7M > [INFO] > -- Th
[jira] Updated: (MNG-2675) add getModules() method which return a MavenProject List instead of module name String list
[ http://jira.codehaus.org/browse/MNG-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-2675: -- Fix Version/s: (was: 2.1) 2.x > add getModules() method which return a MavenProject List instead of module > name String list > --- > > Key: MNG-2675 > URL: http://jira.codehaus.org/browse/MNG-2675 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.4 > Environment: Maven 2.0.4, Windows 2000 >Reporter: David Vicente > Fix For: 2.x > > > Hi, > i try to develop a dashboard report plugin. > But i have a problem with a multi-project pom which i used to test my plugin. > I have a master project with modules which have some modules or project. > Until now, i get the modules list with project.getModules() method and i > compare each module name with the project name that i get with > project.getCollectedProjects() method. > And for each MavenProject object i retreive, i repeat the last algorithm > (getModules() .) > all module names are the same as ArtifactId and my plugin work well. > But with this new project, the module names and ArtifactId are different. > and i can't retreive MavenProjects which are direct module of my pom. > can you add a method to MavenProject object which return the list of modules > as MavenProject object instead of String object ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-136) Create an FML DTD or XSD
[ http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106509 ] Lukas Theussl commented on DOXIA-136: - I am afraid our current modello-generated xsd is unusable, I couldn't validate any fml with it. One problem is the default namespace that is generated (that's maybe fixed in modello-1.0-alpha-15 with MODELLO-46), the other is that all attributes are written out as elements in the xsd (see MODELLO-49). We can't publish it like that, so I propose to move this issue to a later release. > Create an FML DTD or XSD > > > Key: DOXIA-136 > URL: http://jira.codehaus.org/browse/DOXIA-136 > Project: Maven Doxia > Issue Type: Task > Components: Module - Fml >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0-alpha-9 > > > Review the M1 FAQ schema is certainly a good start. > http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd -- 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] Moved: (MARTIFACT-4) allow wildcards and versions in In/ExcludesArtifactFilter
[ http://jira.codehaus.org/browse/MARTIFACT-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-1918 to MARTIFACT-4: --- Fix Version/s: (was: 2.1) 3.0-alpha-1 Component/s: (was: Artifacts and Repositories) Complexity: (was: Intermediate) Workflow: jira (was: Maven New) Key: MARTIFACT-4 (was: MNG-1918) Project: Maven Artifact (was: Maven 2) > allow wildcards and versions in In/ExcludesArtifactFilter > - > > Key: MARTIFACT-4 > URL: http://jira.codehaus.org/browse/MARTIFACT-4 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 3.0-alpha-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: (MARTIFACT-4) allow wildcards and versions in In/ExcludesArtifactFilter
[ http://jira.codehaus.org/browse/MARTIFACT-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106504 ] Brett Porter commented on MARTIFACT-4: -- not sure if this is wanted or not, but is related to the consolidation of filters > allow wildcards and versions in In/ExcludesArtifactFilter > - > > Key: MARTIFACT-4 > URL: http://jira.codehaus.org/browse/MARTIFACT-4 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 3.0-alpha-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: (MNG-1902) track attempted downloads and only re-attempt on certain intervals
[ http://jira.codehaus.org/browse/MNG-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106503 ] Brett Porter commented on MNG-1902: --- actually, in the interests of reproducibility - we should probably just fail if it doesn't exist and force people to create POMs (and ensure it is 100% in central). Might need to be a policy in the element. > track attempted downloads and only re-attempt on certain intervals > -- > > Key: MNG-1902 > URL: http://jira.codehaus.org/browse/MNG-1902 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Brett Porter > Fix For: 2.1 > > > currently, because files are not stored locally when not found, files are > always looked for. > OTOH, we don't want to store incorrect info, especially if it is permanent > (ie, not a snapshot). > We should track in the local repo metadata files that were not found and > when, and check again on intervals. This should be part of the resolver so > the site plugin (site descriptors), poms and more all benefit. -- 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-1886) Need way to share code between report mojos and main build mojos
[ http://jira.codehaus.org/browse/MNG-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1886: -- Fix Version/s: (was: 2.1) 2.x > Need way to share code between report mojos and main build mojos > > > Key: MNG-1886 > URL: http://jira.codehaus.org/browse/MNG-1886 > Project: Maven 2 > Issue Type: Improvement > Components: Plugin API >Affects Versions: 2.0.1 >Reporter: Vincent Massol >Assignee: Brett Porter > Fix For: 2.x > > > For example in the clover plugin i have both report mojos and main build > mojos. They need to share lots of configuration elements and common methods > but it's not easy to do so because each type needs to extend either > AbstractMavenReport or AbstractMojo. Of course I could not extend > AbstractMavenReport and instead implement the interface but then I'll have to > reimplement all its methods. -- 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-1755) Improve support for in reactor builds
[ http://jira.codehaus.org/browse/MNG-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106502 ] Brett Porter commented on MNG-1755: --- Mike - do you think this should be postponed to 2.x? > Improve support for in reactor builds > -- > > Key: MNG-1755 > URL: http://jira.codehaus.org/browse/MNG-1755 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: Mike Perham > Fix For: 2.1 > > > I would like to see something like added which acts > similarly to the other management elements in the POM. This would allow a > top-level project POM to list all the developers, their orgs, timezones, > emails, etc and child projects to reference just the ID and the developers > role in that module. Something like this: > parent's pom.xml: > > > msanchez > Matt Sanchez > [EMAIL PROTECTED] > http://priori.webify.local:9090/display/~msanchez > -6 > > > mperham > Mike Perham > [EMAIL PROTECTED] > http://priori:9090/display/~mperham > -6 > > > foo's pom.xml: > > > mperham > > Owner > > > > Our management wants to have one or two clear-cut owners for each module and > we would like to use maven to document those owners but the current impl is > terribly redundant since developers are not inherited. -- 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-1753) support improved property based profile activation
[ http://jira.codehaus.org/browse/MNG-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1753: -- Fix Version/s: (was: 2.1) 2.x we're currently taking submissions for the new features to accept for 2.1 development - if you'd like to fill in a proposal please drop this in there - thanks! > support improved property based profile activation > -- > > Key: MNG-1753 > URL: http://jira.codehaus.org/browse/MNG-1753 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: John Allen > Fix For: 2.x > > > support better profile activation via > a) multiple property elements in the activation element. > eg:- > > > os.name > > > > os.name > > > > b) regex based property parsing for both name and value elements (dont know > how you'll want to handle the tagging to indicate that something is a regex > property rather than a plain one but for now im using regexName and > regexValue) > eg:- > > > os.name > Windows 2000|Windows XP > > > same for name. -- 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-1712) Maven should handle when a mojo doesn't requires a project
[ http://jira.codehaus.org/browse/MNG-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1712: -- Fix Version/s: (was: 2.1) 2.x > Maven should handle when a mojo doesn't requires a project > --- > > Key: MNG-1712 > URL: http://jira.codehaus.org/browse/MNG-1712 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Allan Ramirez > Fix For: 2.x > > > I have encountered this when I am trying to create the deploy:deploy-file > goal. > Currently, we can tell wagon what provider to use by adding , > but this mojo doesnt require a project so how can we tell the wagon what > provider to use? -- 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-1751) merging metadata doesn't fail when timestamp is in the future
[ http://jira.codehaus.org/browse/MNG-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1751: -- Fix Version/s: (was: 2.1) 2.0.x > merging metadata doesn't fail when timestamp is in the future > - > > Key: MNG-1751 > URL: http://jira.codehaus.org/browse/MNG-1751 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Brett Porter > Fix For: 2.0.x > > > on deploying, the timestamp got set to the future (set to GMT - Guelph Mean > Time instead of the expected Grenwich :) > subsequent attempts to deploy reported success, but did not update the > metadata. > The fact that we might suffer clock skew is probably a separate issue to > consider, that might be reoslved through passing deployments via repoman. -- 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] Moved: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[ http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-1699 to MDEPLOY-63: -- Affects Version/s: (was: 2.0) 2.3 Fix Version/s: (was: 2.1) 2.4 Component/s: (was: POM) Complexity: (was: Intermediate) Key: MDEPLOY-63 (was: MNG-1699) Project: Maven 2.x Deploy Plugin (was: Maven 2) > Allow disabling deployment for artifacts that should not be deployed > > > Key: MDEPLOY-63 > URL: http://jira.codehaus.org/browse/MDEPLOY-63 > Project: Maven 2.x Deploy Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol > Fix For: 2.4 > > > In my cargo build I have some projects producing artifacts that are purely > used for functional tests. I'd like a way to tell m2 not to deploy those when > "mvn deploy" is called at the top level. > jdcasey suggested on IRC: " I'd say you would need a flag in the > deploy plugin's config, or a or something..." -- 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-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1694: -- Fix Version/s: (was: 2.1) 2.x > Build execution order control in fine grained projects. > --- > > Key: MNG-1694 > URL: http://jira.codehaus.org/browse/MNG-1694 > Project: Maven 2 > Issue Type: Wish > Components: Reactor and workspace >Reporter: Mark Proctor > Fix For: 2.x > > > Currently in multi module projects you can only work in 2 modes. > 1) Build everything > 2) Build a single module, IF you have built and installed all its dependency > modules > I would like to be able to work the following way: > 1) Build everything > 2) Build an individual module, will build all the modules prior to it in the > reactor list. > 3) Build a module module and all modules after it in the reactor list, will > build missing prior modules. > Use Case > 1) perform checkout and build > 2) module fails > 3) keep fixing module and running just its unit tests > 3) once all its unit tests pass build it and all modules after it in the > reactor list. I don't need to build ones prior as they are unnaffected by the > changes. > In large mutli module projects this will save a LOT of time especially when > you are gearing up for deployment and want to check that everything works - > currently this is time consuming and repetitive, with much of the repetition > uneeded. -- 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-1692) Project scoped Repository
[ http://jira.codehaus.org/browse/MNG-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1692: -- Fix Version/s: (was: 2.1) 2.x would need to be framed as a proposal > Project scoped Repository > - > > Key: MNG-1692 > URL: http://jira.codehaus.org/browse/MNG-1692 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Reporter: Mark Proctor > Fix For: 2.x > > > In multi module builds I would like jars to not instally locally until I > instruct it and still be able to build individual modules. At the moment if I > try and build an invidiual module it insists on looking in the local repo. In > Maven 1 we worked around this by using jar override. > The use case for this is for when you are messing around with multiple > checkouts of the same version and don't want them to interact with each > other. With current M2 I either have to create different versions in the pom > for each checkout, when all changes are likely to end up in the "master" > checkout for a specific verison. Or I can specify the repo to be in the > project, but that means I have to checkout everything each time I want to > build something. > This could be achieve by using root/target as a project level repo for the > produced jars which would use the local repo for anything that it can't find > it the project repo. Only when I tell it to install will it copy the jars > from the project repo to the local repo. -- 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-2581) Mojo's with @execute don't get configured with executedProject
[
http://jira.codehaus.org/browse/MNG-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106500
]
Maria Odea Ching commented on MNG-2581:
---
Could this be possibly related to MNG-2061, or the other way around?
> Mojo's with @execute don't get configured with executedProject
> --
>
> Key: MNG-2581
> URL: http://jira.codehaus.org/browse/MNG-2581
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Kenney Westerhof
> Fix For: 2.1
>
>
> Not sure if this is a bug or an improvement, but here's a scenario:
> A custom plugin defines a MavenProject property with a timestamp. That
> timestamp
> is used in ${project.artifactId}-${timestamp}.
> During the normal plugin execution, this field is evaluated correctly.
> When running mvn assembly:assembly, the normal (forked) lifecycle also
> functions correctly.
> But the assembly Mojo is configured with the original MavenProject, that
> doesn't have the ${timestamp} property,
> so the parameter on the assembly mojo will be "someArtifact-null".
> A tough problem, but it goes further: Ideally you never want to use
> ${project} as a parameter, but
> the objects fields directly. Say you want to use the source roots and define
> that as a parameter. Then you
> never get access the generated-sources unless you manually examine the
> executedProject.
> Right now, mojo's have to use different logic depending on whether they
> specify @execute phase="X",
> (and examine fields of the executedProject).
> Can we drop the original MavenProject object and replace that with
> executedProject instance, so we only have
> 1 instance of MavenProject?
> Or, if there are plugins that MUST use the original MavenProject, or use both
> MavenProject instances (we might
> want to scan all existing mojo's to see what they do), can we add
> a plugin flag that specifies that that mojo must be configured using the
> executedProject 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: (MNG-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106498 ] Brett Porter commented on MNG-1682: --- this might already be fixed in trunk, if not 2.0.7. Can anyone verify? > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows NT; JDK 1.5 >Reporter: Nigel Magnay > Fix For: 2.1 > > Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- 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-1649) Allow plugins to depend upon other plugin's goals
[ http://jira.codehaus.org/browse/MNG-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106496 ] Brett Porter commented on MNG-1649: --- Mark - want to do a proposal for this one? > Allow plugins to depend upon other plugin's goals > - > > Key: MNG-1649 > URL: http://jira.codehaus.org/browse/MNG-1649 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: 2.1 > > > Need to resolve the use-case discussed on dev: > http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1671) dependant plugins need to be built before any runMaven calls
[ http://jira.codehaus.org/browse/MNG-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1671. - Resolution: Won't Fix Fix Version/s: (was: 2.1) no longer relevant > dependant plugins need to be built before any runMaven calls > > > Key: MNG-1671 > URL: http://jira.codehaus.org/browse/MNG-1671 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Reporter: Brett Porter > > need to do interim builds of anything in the jar lifecycle before any > runMaven() calls to avoid downloading in the instance that we are building > the plugins from source. -- 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-1609) Force update of files in the repo if checksum has been updated
[ http://jira.codehaus.org/browse/MNG-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1609: -- Fix Version/s: (was: 2.1) 2.x > Force update of files in the repo if checksum has been updated > -- > > Key: MNG-1609 > URL: http://jira.codehaus.org/browse/MNG-1609 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.x > > > Maven should support an option "-ccu, --check-checksum-update" that looks in > the remote repositories for updated checksums and redownloads the > corresponding file (artifact, pom, ...). Especially pom updates are currently > really cumbersome, since every user has to clean them in his local repo. -- 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-1569) Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare
[ http://jira.codehaus.org/browse/MNG-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1569: -- Fix Version/s: (was: 2.1) 2.x John - did you think this is important for 2.1? > Make build process info read-only to mojos, and provide mechanism for > explicit out-params for mojos to declare > -- > > Key: MNG-1569 > URL: http://jira.codehaus.org/browse/MNG-1569 > Project: Maven 2 > Issue Type: New Feature > Components: Design, Patterns & Best Practices >Affects Versions: 2.0 >Reporter: John Casey >Priority: Trivial > Fix For: 2.x > > > We need to have the ability to look at a mojo descriptor and see how it will > change the build environment. This requires two things: > 1. Cut off the loophole allowing unauthorized mutation of build state by > making build state read-only to the mojo > 2. Provide an API/annotation-set to allow explicit export of values from a > mojo, where they will be incorporated into the build state. > This should enable things like determining whether a mojo generates sources, > or collecting the source directories (even generated ones) by scanning the > plugins configured for the build. -- 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-1567) improvements to complex mojo configuration
[ http://jira.codehaus.org/browse/MNG-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1567: -- Fix Version/s: (was: 2.1) 2.x will write a proposal next time > improvements to complex mojo configuration > -- > > Key: MNG-1567 > URL: http://jira.codehaus.org/browse/MNG-1567 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.x > > > currently, you can specify an object in the configuration that allows nesting > multiple levels of config. This is helpful, but it would be good to be able > to validate those portions of the configuration as well as set default > values, and make them extendable by making them fully fledged configured > component requirements. > basically: > - be able to specify expressions and default values within the fields of the > object, not just the top mojo, as long as it is in the same source tree as > the mojo (like extends) > - to be able to put a polymorphic object in there without an implementation > given in the pom. This might require selectors, and so might be best left > until a later version (se elinked issue for a use case) > I haven't tried, but it might already be possible to do this (from > components.xml), and we just need to wire up the tools to handle it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1563) how to write integration tests
[ http://jira.codehaus.org/browse/MNG-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1563: -- Fix Version/s: (was: 2.1) Documentation Deficit > how to write integration tests > -- > > Key: MNG-1563 > URL: http://jira.codehaus.org/browse/MNG-1563 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Reporter: Matthew Pocock > Fix For: Documentation Deficit > > > There doesn't seem to be a guide about either testing or integration testing. > It would be nice to see two guides: > plain vanilla junit tests: > how to write a simple one that will run in m2 > how to write one that uses the test suite API > integration testing: > test building e.g. plugin that does code generation > test resulting application e.g. command-line app or gui > test deployment e.g. to a test web service container > I have no idea what of this is currently implemented or even possible using > mvn, but then the documentation isn't giving my wishes any boundaries > either... -- 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-1505) Create an abstract source generation mojo
[ http://jira.codehaus.org/browse/MNG-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1505: -- Fix Version/s: (was: 2.1) Shared Components > Create an abstract source generation mojo > - > > Key: MNG-1505 > URL: http://jira.codehaus.org/browse/MNG-1505 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Requests >Reporter: Jason van Zyl > Fix For: Shared Components > > > There are many source generation mojos and a common base can't hurt. -- 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-1453) Exception error messages and i18n
[ http://jira.codehaus.org/browse/MNG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1453. - Resolution: Duplicate Fix Version/s: (was: 2.1) > Exception error messages and i18n > - > > Key: MNG-1453 > URL: http://jira.codehaus.org/browse/MNG-1453 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: all >Reporter: Corridor Software Developer > > Augment the exceptions thrown by components and plugins with a methodology > supporting internationlization (i18n) of error messages. > The framework would promote the use of readily translatable error message > tables by deprecating the use of the standard new Exception(message:String). > Each exception thrown by a plugin or component would have a code wrapped in > an error object for easy use. A JUnit test object would be available to > extend by component developers to immediately check for missing exception > strings. > For a working example, look to the xmlbeans-maven-plugin in the codohaus > subversion repository. > A patch will be attached for a single component for review, followed by a > comprehensive patch of the core. -- 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: (CONTINUUM-1431) NPE after pressing "relase project' icon on shell projects
NPE after pressing "relase project' icon on shell projects -- Key: CONTINUUM-1431 URL: http://jira.codehaus.org/browse/CONTINUUM-1431 Project: Continuum Issue Type: Bug Components: Integration - Shell Affects Versions: 1.1-beta-2 Reporter: Wojciech Meler After choosing release project on shell project you get NullPointerException. http://localhost:8080/continuum/releasePromptGoal.action?projectId=1&projectGroupId=1# java.lang.NullPointerException: groupId was null at org.apache.maven.artifact.ArtifactUtils.versionlessKey(ArtifactUtils.java:54) at org.apache.maven.continuum.web.action.ReleaseProjectAction.promptReleaseGoal(ReleaseProjectAction.java:72) 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 com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:147) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.i
[jira] Closed: (MNG-1438) Plugin of plugins (or CompositePlugin)
[ http://jira.codehaus.org/browse/MNG-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1438. - Resolution: Incomplete Fix Version/s: (was: 2.1) not sure what this is about, but could be another alternative to the plugin packs that is already being thrown around the dev@ list - will leave it up to that proposal. > Plugin of plugins (or CompositePlugin) > -- > > Key: MNG-1438 > URL: http://jira.codehaus.org/browse/MNG-1438 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Requests >Reporter: Jason van Zyl > > Chris, do you think you could pop in your original email? -- 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-1437) How to make additions to the POM and have it be backward/forward compatible
[ http://jira.codehaus.org/browse/MNG-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1437. - Resolution: Duplicate Fix Version/s: (was: 2.1) > How to make additions to the POM and have it be backward/forward compatible > --- > > Key: MNG-1437 > URL: http://jira.codehaus.org/browse/MNG-1437 > Project: Maven 2 > Issue Type: Task > Components: Design, Patterns & Best Practices >Reporter: Jason van Zyl >Priority: Trivial > > I would like to add categories and site staging information to the POM but > don't want to break everything. Brett and I have discussed this topic briefly > but we need the XML parsing mechanism to be a bit more flexible or we may > just have to embrace namespaces to make this work ... -- 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-1420) When profile selected in command line doesn't exist print a warning/error
[ http://jira.codehaus.org/browse/MNG-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1420: -- Fix Version/s: (was: 2.1) 2.0.x > When profile selected in command line doesn't exist print a warning/error > - > > Key: MNG-1420 > URL: http://jira.codehaus.org/browse/MNG-1420 > Project: Maven 2 > Issue Type: Improvement > Components: Errors, Profiles >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Minor > Fix For: 2.0.x > > -- 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-1418) When proxy host doesn't exist print a warning instead of silently ignore
[ http://jira.codehaus.org/browse/MNG-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1418. - Resolution: Duplicate Fix Version/s: (was: 2.1) pretty much a dupe of the other > When proxy host doesn't exist print a warning instead of silently ignore > > > Key: MNG-1418 > URL: http://jira.codehaus.org/browse/MNG-1418 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Trivial > > If the host of the proxy doesn't exist the proxy is ignored silently (eg. > somehost.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] Updated: (MNG-1381) best practices: testing strategies
[ http://jira.codehaus.org/browse/MNG-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1381: -- Fix Version/s: (was: 2.1) Documentation Deficit > best practices: testing strategies > -- > > Key: MNG-1381 > URL: http://jira.codehaus.org/browse/MNG-1381 > Project: Maven 2 > Issue Type: Task > Components: Design, Patterns & Best Practices >Affects Versions: 2.0 >Reporter: Vincent Massol > Fix For: Documentation Deficit > > > The wiki page used to collect feedback is: > http://docs.codehaus.org/display/MAVEN/Testing+Strategies -- 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-1330) direct support for mock classes
[ http://jira.codehaus.org/browse/MNG-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1330. - Resolution: Won't Fix Fix Version/s: (was: 2.1) It seems people have been able to get by fine without this - if you disagree please reopen (we should really thrash it over on the dev@ list if so). > direct support for mock classes > --- > > Key: MNG-1330 > URL: http://jira.codehaus.org/browse/MNG-1330 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Affects Versions: 2.0 >Reporter: Jorg Heymans > > 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] Closed: (MNG-1258) Add option to redownload poms
[ http://jira.codehaus.org/browse/MNG-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1258. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 2.1) we don't fix poms > Add option to redownload poms > - > > Key: MNG-1258 > URL: http://jira.codehaus.org/browse/MNG-1258 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 (RC) >Reporter: Carlos Sanchez >Assignee: Brett Porter > > 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: (MNG-1120) don't require if there is a valid schema element
[ http://jira.codehaus.org/browse/MNG-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106488 ] Brett Porter commented on MNG-1120: --- modello has this capability already, so could be easily implemented > don't require if there is a valid schema element > - > > Key: MNG-1120 > URL: http://jira.codehaus.org/browse/MNG-1120 > Project: Maven 2 > Issue Type: Bug > Components: POM >Reporter: Brett Porter >Priority: Minor > Fix For: 2.1 > > > This can't happen in 2.0.x. -- 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-3130) Maven fails if SNAPSHOT can not be downloaded
[ http://jira.codehaus.org/browse/MNG-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MNG-3130. - Resolution: Duplicate Duplicate with MNG-2695 > Maven fails if SNAPSHOT can not be downloaded > - > > Key: MNG-3130 > URL: http://jira.codehaus.org/browse/MNG-3130 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7 >Reporter: Jörg Hohwiller > > If a required artifact has a SNAPSHOT version, maven wants to get the latest > version of that artifact. If the SNAPSHOT is not available from a repository > (e.g. the repository is down, the artifact has been deleted or the client is > offline) the build fails even if the same SNAPSHOT version of that artifact > is already available in the local repository. Even worse this also happens if > maven is started in offline mode (-o). There seems to be no workaround. This > blocks our build since a custom repository crashed. > This issue seems to be related to: > MNG-2883 > MNG-2433 -- 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
