Re: [jira] Commented: (MNG-556) NPE in MavenProject class
yes it did: http://jira.codehaus.org/browse/MNG-565 was the ticket and patch. -- Kris Bravo Corridor Software, Inc. http://www.corridor-software.us > [ http://jira.codehaus.org/browse/MNG-556?page=comments#action_42735 ] > > John Casey commented on MNG-556: > > > I thought I saw a fix for this go flying by in the commit emails. I'll > verify and fix if it hasn't already been done. > >> NPE in MavenProject class >> - >> >> Key: MNG-556 >> URL: http://jira.codehaus.org/browse/MNG-556 >> Project: Maven 2 >> Type: Bug >> Components: maven-project >> Versions: 2.0-beta-1 >> Reporter: Vincent Siveton >> Assignee: John Casey >> Fix For: 2.0-beta-1 >> Attachments: mavenproject.patch >> >> >> A NPE could be thrown in some circumstances (ie by the javadoc plugin) >> in the MavenProject class. >> getArtifacts() could be null. >> Lets see the patch. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: >http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-576) Support of EAR lifecycle
[ http://jira.codehaus.org/browse/MNG-576?page=comments#action_42739 ] J. Matthew Pryor commented on MNG-576: -- I am pretty sure this is the same basic problem that has frustrated my attempts to write an M2 plugin to support Eclipse PDE artifacts. The only way I can register a plugin to handle a new packaging type is to modify maven-core/src/main/resources/META-INF/plexus/components.xml. Clearly this is not at all what plugin developers would want to do > Support of EAR lifecycle > > > Key: MNG-576 > URL: http://jira.codehaus.org/browse/MNG-576 > Project: Maven 2 > Type: Improvement > Components: maven-plugins, maven-core > Versions: 2.0-alpha-3 > Reporter: Stephane Nicoll > Assignee: John Casey > Priority: Blocker > Fix For: 2.0-beta-1 > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > The following patches integrates the ear plugin into a m2 lifecycle so that > m2 package / install / deploy / etc goals could be used with an 'ear' > packaging. > First patch is to be applied on maven-core to register ear lifecycle > Second patch is to be applied on maven-plugins/maven-ear-plugin to add > support of generateApplicationXml flag which states whether application.xml > should be generated or not (default is true). > This relates to MNG-563 where the original discussion took 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-479) unable to override the default central repository
[ http://jira.codehaus.org/browse/MNG-479?page=comments#action_42738 ] John Casey commented on MNG-479: Actually, I disagree. I believe that this could be a very useful feature in certain circumstances. For example, if a company wishes to have ultimate control over what is and isn't used in their projects (whether for security, IP, or other reasons), then a logical first step might be to run m2 in an isolated environment and never access the default central repository. In this case, they would even mirror those artifacts found on ibiblio that they want to use - perhaps after somehow vetting them for security or IP concerns. If we disallow overriding of the central repository, then the best experience they can expect is to have error after error in their build process because they have a firewall or router that blocks connections to ibiblio. There are perfectly valid use cases for not using the default central repository. > unable to override the default central repository > - > > Key: MNG-479 > URL: http://jira.codehaus.org/browse/MNG-479 > Project: Maven 2 > Type: Bug > Components: maven-core > Versions: 2.0-alpha-2 > Environment: WinXP > Reporter: Edwin Punzalan > Assignee: John Casey > Priority: Minor > Fix For: 2.0-beta-1 > > > Adding to my pom.xml: > > > > central > custom repository > http://maven.company.com/maven2 > > > > did not override the central repository but instead uses the above configured > repository as backup/mirror. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-576) Support of EAR lifecycle
[ http://jira.codehaus.org/browse/MNG-576?page=all ] John Casey updated MNG-576: --- Priority: Blocker (was: Minor) Escalating the priority on this, since patching maven-core isn't appropriate for new packaging handlers. The object of the game is to allow new type/package handlers to be added on the fly without modifying maven-core. However, unless I'm mistaken, these new lifecycle mappings will not be available simply by adding the type-handler plugin to the mix. This will require some design time, so I'm going to make it a high priority. > Support of EAR lifecycle > > > Key: MNG-576 > URL: http://jira.codehaus.org/browse/MNG-576 > Project: Maven 2 > Type: Improvement > Components: maven-plugins, maven-core > Versions: 2.0-alpha-3 > Reporter: Stephane Nicoll > Assignee: John Casey > Priority: Blocker > Fix For: 2.0-beta-1 > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > The following patches integrates the ear plugin into a m2 lifecycle so that > m2 package / install / deploy / etc goals could be used with an 'ear' > packaging. > First patch is to be applied on maven-core to register ear lifecycle > Second patch is to be applied on maven-plugins/maven-ear-plugin to add > support of generateApplicationXml flag which states whether application.xml > should be generated or not (default is true). > This relates to MNG-563 where the original discussion took 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-282) mojos should be able to declare project independence
[ http://jira.codehaus.org/browse/MNG-282?page=comments#action_42736 ] John Casey commented on MNG-282: perhaps when a mojo declares @requiresProject == false: if that mojo is the only one in the task list we can skip iteration through the project hierarchy and simply execute at the current location. > mojos should be able to declare project independence > > > Key: MNG-282 > URL: http://jira.codehaus.org/browse/MNG-282 > Project: Maven 2 > Type: Bug > Components: maven-plugin-tools, maven-plugin-descriptor > Versions: 2.0-alpha-1 > Reporter: Brett Porter > Fix For: 2.0-beta-1 > > > currently, a dummy project is created if there is none, or the project is > passed on. > mojo's like archetype:create will never care about the current project > (unless they were to modify the existing definition, perhaps). > However, they run in to problems, because it runs across all submodules of > the currnet project when you really just intend to create one under the > current directory. > For this to happen - the relationship between goals and reactor may need to > be reversed as has been looked at in another issue. > It may be that the goal just needs to not be executed inside the reactor? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-223) URL validator doesn't accept url http://myserver/mypath
URL validator doesn't accept url http://myserver/mypath --- Key: CONTINUUM-223 URL: http://jira.codehaus.org/browse/CONTINUUM-223 Project: Continuum Type: Bug Reporter: Emmanuel Venisse Fix For: 1.0-beta-1 http://localhost/pom.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] Commented: (MNG-556) NPE in MavenProject class
[ http://jira.codehaus.org/browse/MNG-556?page=comments#action_42735 ] John Casey commented on MNG-556: I thought I saw a fix for this go flying by in the commit emails. I'll verify and fix if it hasn't already been done. > NPE in MavenProject class > - > > Key: MNG-556 > URL: http://jira.codehaus.org/browse/MNG-556 > Project: Maven 2 > Type: Bug > Components: maven-project > Versions: 2.0-beta-1 > Reporter: Vincent Siveton > Assignee: John Casey > Fix For: 2.0-beta-1 > Attachments: mavenproject.patch > > > A NPE could be thrown in some circumstances (ie by the javadoc plugin) in the > MavenProject class. > getArtifacts() could be null. > Lets see the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-581) Add target/classes director to compiler:compile classpath
[ http://jira.codehaus.org/browse/MNG-581?page=comments#action_42733 ] David Jencks commented on MNG-581: -- Just including the generated classes in target/classes seems to be adequate for m1. I think a fix for this is needed in m2. To me asking xmlbeans to jar up its binary artifacts only to discard the jar is ludicrous. I think this problem should be fixed, not retracted. > Add target/classes director to compiler:compile classpath > - > > Key: MNG-581 > URL: http://jira.codehaus.org/browse/MNG-581 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: any OS, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > > > An upcoming plugin called during generate-sources produces class files in the > classes output directory and sources in the generated-sources directory. > While the plugin should be responsible for adding generated-sources to the > compileSourceRoot, it may be worthwhile to have the target classes directory > in the classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-581) Add target/classes director to compiler:compile classpath
[ http://jira.codehaus.org/browse/MNG-581?page=comments#action_42732 ] Corridor Software Developer commented on MNG-581: - Someone please check me, but I believe this won't do any good now that I have another look at it. MavenProject.getCompileClasspathElements weeds out any items that aren't jar files. The call to isAddedToClasspath only returns true for jar's, ejb jars and ejb-client jars. As it stands now though, I still need a solution to the following problem: Apache XML Beans produces class files during generate-sources which need to end up on the classpath when the compile step is reached. If they are not jar'ed up, getCompileClasspathElements will not return them in the set. One potential solution is to use the XMLBean compiler's support for producing a jar file, then add this to the MavenProject artifacts list. But for now, I'd like to retract this defect. > Add target/classes director to compiler:compile classpath > - > > Key: MNG-581 > URL: http://jira.codehaus.org/browse/MNG-581 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: any OS, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > > > An upcoming plugin called during generate-sources produces class files in the > classes output directory and sources in the generated-sources directory. > While the plugin should be responsible for adding generated-sources to the > compileSourceRoot, it may be worthwhile to have the target classes directory > in the classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-435) Please upload cglib-nodep-2.1_2
Please upload cglib-nodep-2.1_2 --- Key: MAVENUPLOAD-435 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-435 Project: maven-upload-requests Type: Task Reporter: Chris Nokleberg http://cglib.sf.net/ http://cglib.sourceforge.net/team-list.html CGLIB is a code generation library which can extend Java classes and implement interfaces at runtime. This artifact has no dependencies. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-434) Please upload cglib-2.1_2
Please upload cglib-2.1_2 - Key: MAVENUPLOAD-434 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-434 Project: maven-upload-requests Type: Task Reporter: Chris Nokleberg http://cglib.sf.net/ http://cglib.sourceforge.net/team-list.html CGLIB is a code generation library which can extend Java classes and implement interfaces at runtime. This artifact depends on ASM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-524) [regression] non o.a.m.plugins grouped plugins not discovered from POM when executed from command line
[ http://jira.codehaus.org/browse/MNG-524?page=all ] John Casey closed MNG-524: -- Resolution: Fixed see it0031 > [regression] non o.a.m.plugins grouped plugins not discovered from POM when > executed from command line > -- > > Key: MNG-524 > URL: http://jira.codehaus.org/browse/MNG-524 > Project: Maven 2 > Type: Bug > Components: maven-core > Reporter: Brett Porter > Assignee: John Casey > Fix For: 2.0-beta-1 > > > I broke this by removing the resolution of all plugins in the pom for every > goal to avoid the unnecessary dependency resolution. > If you run "modello:xdoc" on the command line in maven-model, it doesn't know > to try the modello plugin in the POM. I think that the prefix to ID lookup as > part of another bug will fix this. > Workaround: fully qualified goal name > (org.codehaus.modello:modello-maven-plugin:1.0-alpha-3:xdoc) > Please add an integration test also. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r216013 - in /maven/components/trunk: maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/ maven-core-it/it0013/ maven-core-it/it0015/ maven-core-it/it0020/ maven-core-it/it0021/ maven-plugins/ maven-plugins/m...
Author: jdcasey
Date: Tue Jul 12 13:08:21 2005
New Revision: 216013
URL: http://svn.apache.org/viewcvs?rev=216013&view=rev
Log:
Fixing problem with using distributionManagement repository definition for
download of plugins.xml metadata.
Now, in order to build a maven plugin, you need two things:
1. a repository defined in distributionManagment
2. a repository defined in which has the same id as the one in
distributionManagement.
This is necessary, since in most cases SSH will be used in the
distributionManagement definition for uploading the plugin...which means that
the download of the existing plugins.xml file might not be available for users
trying to run an install. SSH requires authentication information, and users
(particularly those running the bootstrap) might not have this auth info.
Modified:
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.java
maven/components/trunk/maven-core-it/it0013/pom.xml
maven/components/trunk/maven-core-it/it0015/pom.xml
maven/components/trunk/maven-core-it/it0020/pom.xml
maven/components/trunk/maven-core-it/it0021/pom.xml
maven/components/trunk/maven-plugins/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/ValidatePluginPomMojo.java
maven/components/trunk/maven-plugins/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/metadata/GenerateUpdatedMappingMojo.java
maven/components/trunk/maven-plugins/pom.xml
Modified:
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.java?rev=216013&r1=216012&r2=216013&view=diff
==
---
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.java
(original)
+++
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.java
Tue Jul 12 13:08:21 2005
@@ -6,12 +6,9 @@
import org.apache.maven.wagon.TransferFailedException;
import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.util.FileUtils;
-import org.codehaus.plexus.util.IOUtil;
import java.io.File;
-import java.io.FileReader;
import java.io.IOException;
-import java.io.Reader;
import java.util.HashMap;
import java.util.Map;
@@ -46,8 +43,6 @@
{
wagonManager.getRepositoryMetadata( metadata, remote,
metadataFile );
-verifyLocalRepositoryFile( metadataFile );
-
metadata.setFile( metadataFile );
}
catch ( TransferFailedException e )
@@ -60,13 +55,6 @@
throw new RepositoryMetadataManagementException( metadata,
"Remote repository metadata not found.",
e );
}
-catch ( IOException e )
-{
-throw new RepositoryMetadataManagementException(
- metadata,
- "Download
of repository metadata resulted in an invalid file.",
- e );
-}
}
}
}
@@ -137,29 +125,6 @@
realignedPath = "/REPOSITORY-INF/" + remoteId + realignedPath;
return new File( local.getBasedir(), realignedPath );
-}
-
-private void verifyLocalRepositoryFile( File metadataFile )
-throws IOException
-{
-Reader metadataReader = null;
-
-try
-{
-metadataReader = new FileReader( metadataFile );
-
-char[] cbuf = new char[16];
-
-while ( metadataReader.read( cbuf ) > -1 )
-{
-// do nothing...just verify that it can be read.
-}
-}
-finally
-{
-IOUtil.close( metadataReader );
-}
-
}
}
Modified: maven/components/trunk/maven-core-it/it0013/pom.xml
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-core-it/it0013/pom.xml?rev=216013&r1=216012&r2=216013&view=diff
==
--- maven/components/trunk/maven-core-it/it0013/pom.xml (original)
+++ maven/components/trunk/maven-core-it/it0013/pom.xml Tue Jul 12 13:08:21 2005
@@ -22,7 +22,7 @@
- test-repo
+ central
Test Repository
file:/tmp/testRepo
Modified: maven/components/trunk/ma
[jira] Created: (CONTINUUM-222) Update modello model UpdateScmResult to capture new information provided by Maven SCM
Update modello model UpdateScmResult to capture new information provided by Maven SCM - Key: CONTINUUM-222 URL: http://jira.codehaus.org/browse/CONTINUUM-222 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-1 Emmanuel, I would like to capture the information you added to the changeset so that I can display more information about the changed files in the web UI. You might want to chat with Trygve about the collapse of UpdateScmResult and CheckoutScmResult. Though I think it might be good to keep these separate. -- 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-581) Add target/classes director to compiler:compile classpath
Add target/classes director to compiler:compile classpath - Key: MNG-581 URL: http://jira.codehaus.org/browse/MNG-581 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Environment: any OS, jdk 1.4.2_06 Reporter: Corridor Software Developer Priority: Minor An upcoming plugin called during generate-sources produces class files in the classes output directory and sources in the generated-sources directory. While the plugin should be responsible for adding generated-sources to the compileSourceRoot, it may be worthwhile to have the target classes directory in the classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get Maven plug-in to operate in the context of Eclipse Workspace
On Tuesday 12 July 2005 20:47, Miks Rozenbergs wrote: > So the question is how to call Maven from Eclipse providing Maven plug-in > (which we are about to develop) with access to Eclipse Workspace and > Eclipse plug-in classes? Is there anything out there already? As far as I can tell, M2 is written for use embedded in other systems. OSGi would be one of them. I guess you should look at the Embedder class, and possibly at the Continuum project in order to get more hints. I'm not sure if it is easy to modify the plexus container (using the Avalon framework as the container contract) in order to plug in OSGi bundles providing bundles as components into the Plexus Service Manager, looking up through OSGi when it can't find required services for a component. That would possibly allow to mix OSGi bundles with Avalon components, providing "native" plugging into OSGi and Eclipse. Probably JVZ can give more info on that? /peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get Maven plug-in to operate in the context of Eclipse Workspace
Hello everybody! We are investigating the use of Maven (M2) as a way to describe dependancies between various components making up our Web applications and do builds. Components are developed using our own in-house development and configuration tools which already have implemented code generation, packaging, etc. tasks, so, all we need is to create simple Maven plug-in (-s) calling those tasks. However the catch is that all our development tools are tightly integrated into Eclipse and require running Eclipse Workspace with all the Eclipse plug-ins loaded in order to perform code generation, packaging etc. So the question is how to call Maven from Eclipse providing Maven plug-in (which we are about to develop) with access to Eclipse Workspace and Eclipse plug-in classes? Is there anything out there already? Best Regards. Miks Rozenbergs Exigen Group www.exigengroup.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r215987 - /maven/maven-1/plugins/trunk/clover/xdocs/properties.xml
Author: carlos Date: Tue Jul 12 10:51:24 2005 New Revision: 215987 URL: http://svn.apache.org/viewcvs?rev=215987&view=rev Log: Fixed name of check properties Modified: maven/maven-1/plugins/trunk/clover/xdocs/properties.xml Modified: maven/maven-1/plugins/trunk/clover/xdocs/properties.xml URL: http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/clover/xdocs/properties.xml?rev=215987&r1=215986&r2=215987&view=diff == --- maven/maven-1/plugins/trunk/clover/xdocs/properties.xml (original) +++ maven/maven-1/plugins/trunk/clover/xdocs/properties.xml Tue Jul 12 10:51:24 2005 @@ -152,7 +152,7 @@ - maven.clover.target + maven.clover.check.target Yes Test coverage % under which the build will fail when @@ -163,7 +163,7 @@ - maven.clover.packages + maven.clover.check.packages Yes Comma-separated list of packages that you wish to check for @@ -174,11 +174,11 @@ - maven.clover.targets + maven.clover.check.targets Yes Comma-separated list of test coverage % that you wish to check for -each packages specified by maven.clover.packages when +each packages specified by maven.clover.check.packages when clover:check is called. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-580) possibility too change the directory of web.xml
[ http://jira.codehaus.org/browse/MNG-580?page=all ] Emmanuel Venisse closed MNG-580: Resolution: Fixed org.apache.maven.plugins maven-war-plugin PATH_TO_WEB.XML > possibility too change the directory of web.xml > --- > > Key: MNG-580 > URL: http://jira.codehaus.org/browse/MNG-580 > Project: Maven 2 > Type: Wish > Versions: 2.0-alpha-3 > Reporter: jeremi Joslin > Priority: Minor > > > add the possibility to change the path of web.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-579) a dependency of type tld is not added to the package
[ http://jira.codehaus.org/browse/MNG-579?page=all ] Kenney Westerhof updated MNG-579: - Attachment: MNG-579.patch this patch fixes the tld handling. Sample pom to test it: 4.0.0 maven-tests war-tld war 2.0-beta-1-SNAPSHOT spring spring 1.0.2 runtime tld maven-war-plugin src/webapp/WEB-INF/web.xml > a dependency of type tld is not added to the package > > > Key: MNG-579 > URL: http://jira.codehaus.org/browse/MNG-579 > Project: Maven 2 > Type: Bug > Components: maven-plugins > Versions: 2.0-alpha-3 > Environment: Windows XP SP2 jdk 5.0 > Reporter: Dennis Geurts > Priority: Minor > Attachments: MNG-579.patch > > > the project package is set to 'war' > a dependency is added as follows: > > spring > spring > 1.0.2 > runtime > tld > > running 'm2 clean:clean package' > does NOT add the spring-1.0.2.tld to the war file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-580) possibility too change the directory of web.xml
possibility too change the directory of web.xml --- Key: MNG-580 URL: http://jira.codehaus.org/browse/MNG-580 Project: Maven 2 Type: Wish Versions: 2.0-alpha-3 Reporter: jeremi Joslin Priority: Minor add the possibility to change the path of web.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - checkout] Tue Jul 12 11:29:20 EDT 2005
Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050712.112920.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-579) a dependency of type tld is not added to the package
a dependency of type tld is not added to the package Key: MNG-579 URL: http://jira.codehaus.org/browse/MNG-579 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-alpha-3 Environment: Windows XP SP2 jdk 5.0 Reporter: Dennisg Geurts Priority: Minor the project package is set to 'war' a dependency is added as follows: spring spring 1.0.2 runtime tld running 'm2 clean:clean package' does NOT add the spring-1.0.2.tld to the war file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-578) dependencies otherthan of type jar are added to the .classpath
dependencies otherthan of type jar are added to the .classpath -- Key: MNG-578 URL: http://jira.codehaus.org/browse/MNG-578 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-alpha-3 Environment: windows XP SP2 jdk 5.0 Reporter: Dennisg Geurts Priority: Minor If in the pom.xml a dependency of type 'tld' is added, this file is also added to the .classpath file eg. spring spring 1.0.2 runtime tld results in: ... ... ... this will result in a non-functional eclipse 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-577) surefire plugin doesn't generate a report
surefire plugin doesn't generate a report - Key: MNG-577 URL: http://jira.codehaus.org/browse/MNG-577 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Reporter: Yann Le Du For the moment, maven-surefire-plugin doesn't generate a report (as junit-report used to do in Maven 1). If we try to include surefire in the reports list of the pom, we get a ClassCastException : java.lang.ClassCastException: org.apache.maven.test.SurefirePlugin -| at org.apache.maven.doxia.DoxiaMojo.categorizeReports(DoxiaMojo.java:332) ... -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42706 ] Stephane Nicoll commented on MNG-563: - See MNG-576. > Add generation of application.xml in EAR plugin > --- > > Key: MNG-563 > URL: http://jira.codehaus.org/browse/MNG-563 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Reporter: Vincent Massol > Assignee: Vincent Massol > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > It sems the current version in SVN trunk does not support generating the > application.xml file. It does support adding EAR modules though. Generating > application.xml would allow not having to hardcode the modules nor the > version in the application.xml file. For example: > > 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd";> > > Simple EAR for testing > > > simple-war-0.6-SNAPSHOT.war > /simpleweb > > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-576) Support of EAR lifecycle
Support of EAR lifecycle Key: MNG-576 URL: http://jira.codehaus.org/browse/MNG-576 Project: Maven 2 Type: Improvement Components: maven-plugins, maven-core Versions: 2.0-alpha-3 Reporter: Stephane Nicoll Priority: Minor Fix For: 2.0-beta-1 Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch The following patches integrates the ear plugin into a m2 lifecycle so that m2 package / install / deploy / etc goals could be used with an 'ear' packaging. First patch is to be applied on maven-core to register ear lifecycle Second patch is to be applied on maven-plugins/maven-ear-plugin to add support of generateApplicationXml flag which states whether application.xml should be generated or not (default is true). This relates to MNG-563 where the original discussion took 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mixed plugins and functional tests for plugins? (was RE: [m2] Clvoer plugin location (was RE: [m2] Forking a customlifecycle in a report plugin?))
Best Regards Global Identity A/S, Jens Fournais CEO Bygstubben 3 | DK-2950 Vedbaek | Denmark Phone: +45 45 99 31 | E-mail: [EMAIL PROTECTED] Please visit our website at: http://www.elibitum.com "Vincent Massol" <[EMAIL PROTECTED]> 07-07-2005 19:40 Please respond to "Maven Developers List" To "'Maven Developers List'" cc Subject RE: Mixed plugins and functional tests for plugins? (was RE: [m2] Clvoer plugin location (was RE: [m2] Forking a customlifecycle in a report plugin?)) > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: mercredi 6 juillet 2005 10:38 > To: Maven Developers List > Subject: Re: Mixed plugins and functional tests for plugins? (was RE: [m2] > Clvoer plugin location (was RE: [m2] Forking a customlifecycle in a report > plugin?)) [snip] > > > I still think it would make more sense to make these functional tests > > > normal JUnit tests and instead of having a tester plugin just have a > > > simple tool for embedding Maven 2 because you still need to do > assertions > > > after you've executed Maven. > > Got a opinion on this? Sure, that sounds good. The tester plugin was just meant to be a little wrapper around this idea. But I'm fine to start with your idea of this simple tool and take it from there. > > The tester plugin would not have any assertion itself (apart from the > > executing project failing). The tests are done by the executing plugin > and > > the verifier plugin can be used to perform high level assertions. > > Isn't the executing plugin the "real" plugin itself? Sorry, my fault. I meant "executing project" and not "executing plugin". -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-571) Improve plugin-overview and fix site.xml
[ http://jira.codehaus.org/browse/MNG-571?page=all ] Jason van Zyl closed MNG-571: - Resolution: Fixed Patch applied. > Improve plugin-overview and fix site.xml > > > Key: MNG-571 > URL: http://jira.codehaus.org/browse/MNG-571 > Project: Maven 2 > Type: Task > Components: documentation > Versions: 2.0-alpha-3 > Reporter: Tim O'Brien > Fix For: 2.0-beta-1 > Attachments: patch.txt > > > Another documentation patch, this one focuses on the plugin-overview.apt and > site.xml. Trying to develop the introduction to plug-ins, what are they, > what's a 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r215942 - in /maven/components/trunk/maven-site/src/site: apt/guides/releasing.apt apt/plugin-overview.apt site.xml
Author: jvanzyl
Date: Tue Jul 12 05:06:17 2005
New Revision: 215942
URL: http://svn.apache.org/viewcvs?rev=215942&view=rev
Log:
o applying http://jira.codehaus.org/browse/MNG-571
Thanks to Tim.
Modified:
maven/components/trunk/maven-site/src/site/apt/guides/releasing.apt
maven/components/trunk/maven-site/src/site/apt/plugin-overview.apt
maven/components/trunk/maven-site/src/site/site.xml
Modified: maven/components/trunk/maven-site/src/site/apt/guides/releasing.apt
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-site/src/site/apt/guides/releasing.apt?rev=215942&r1=215941&r2=215942&view=diff
==
--- maven/components/trunk/maven-site/src/site/apt/guides/releasing.apt
(original)
+++ maven/components/trunk/maven-site/src/site/apt/guides/releasing.apt Tue Jul
12 05:06:17 2005
@@ -33,3 +33,38 @@
-
m2 release:perform
-DtagBase=svn+ssh://svn.codehaus.org/home/projects/plexus/scm
-
+
+~~ -
+~~ o had to update each component manually to change the version
+~~ o had to change the depMan element in the top-level POM
+~~ both tedious and error prone
+~~ o had to change the assembly file name
+~~ o had to change the webpapp file name
+
+~~ sign the release
+
+-
+#!/bin/sh
+
+rel=$1
+
+if [ -z "$rel" ]; then
+ echo usage: $0 release
+exit 1
+fi
+
+exts="tar.gz tar.bz2 zip"
+if [ -f "$rel.exe" ]; then
+ exts="$exts exe"
+ fi
+
+ for i in $exts; do md5sum $rel.$i | sed 's/ .*$//g' >$rel.$i.md5; done
+
+ for i in $exts; do gpg --armor --output $rel.$i.asc --detach-sig
+$rel.$i; done
+-
+
+~~ o deploy to /www/www.apache.org/dist/maven/binaries
+
+~~ o even though we have said each module needs to specify its own version that
+~~ is really a pita. maybe there is a better way we can deal with that.
Modified: maven/components/trunk/maven-site/src/site/apt/plugin-overview.apt
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-site/src/site/apt/plugin-overview.apt?rev=215942&r1=215941&r2=215942&view=diff
==
--- maven/components/trunk/maven-site/src/site/apt/plugin-overview.apt
(original)
+++ maven/components/trunk/maven-site/src/site/apt/plugin-overview.apt Tue Jul
12 05:06:17 2005
@@ -26,10 +26,66 @@
Maven consists of a core engine which provides basic project-processing
capabilities and build-process management, and a host of plugins which are
- used to execute the actual build tasks.
+ used to execute the actual build tasks.
-~~ Additional intro material here.
+** What is a Plugin?
+
+ "Maven" is really just a core framework for a collection of
+ Maven Plugins. In other words, plugins are where much of the real action is
+ performed, plugins are used to: create jar files, create war files, compile
+ code, unit test code, create project documentation, and on and on. Almost
+ any action that you can think of performing on a project is implemented as
+ a Maven plugin.
+
+ Plugins are the central feature of Maven that allow for the reuse of
+ common build logic across multiple projects. They do this by executing an
+ "action" (i.e. creating a WAR file or compiling unit tests) in the context
+ of a project's description - the Project Object Model (POM). Plugin behavior
+ can be customized through a set of unique parameters which are exposed by a
+ description of each plugin goal (or Mojo).
+
+ One of the simplest plugins in Maven 2.0 is the Clean Plugin. The
+ {{{http://maven.apache.org/maven2/plugins/maven-clean-plugin/}Maven
+ Clean plugin}} (maven-clean-plugin) is responsible for removing the target
+ directory of a Maven 2 project. When you run "m2 clean:clean", Maven 2
executes
+ the "clean:clean" goal as defined in the Clean plug-in, and the target
directory
+ is removed. The Clean plugin
+
{{{http://maven.apache.org/maven2/plugins/maven-clean-plugin/clean-mojo.html}defines
+ a parameter}} which can be used to customize plugin behavior, this parameter
is
+ called outputDirectory and it defaults to ${project.build.directory}.
+
+** What is a Mojo ()?
+
+ A Mojo is really just a goal in Maven 2, and plug-ins consist of
+ any number of goals (Mojos). Mojos can be defined as annotated Java classes
or
+ as a XML plugin script if a plugin is defined in Marmalade. A Mojo
specifies
+ metadata about a goal: a goal name, which phase of the lifecycle it fits
into,
+ and the parameters it is expecting.
+
+ MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for
+ "Plain". Mojo is also an iteresting word (see
{{{http://www.answers.com/mojo&r=67}definition}}.
+ From {{{http://www.wikipedia.org}Wikipedia}}, a "mojo" is defined as:
+ "...a small bag worn by a person under the clothes (also known as a mojo
hand).
+ Such bags were thought to have supernatu
[jira] Closed: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=all ] Vincent Massol closed MNG-563: -- Assign To: Vincent Massol Resolution: Won't Fix Generation of application.xml is already implemented. See MNG-148. Stephane, open a new issue if you want for integrating it in the lifecycle. > Add generation of application.xml in EAR plugin > --- > > Key: MNG-563 > URL: http://jira.codehaus.org/browse/MNG-563 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Reporter: Vincent Massol > Assignee: Vincent Massol > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > It sems the current version in SVN trunk does not support generating the > application.xml file. It does support adding EAR modules though. Generating > application.xml would allow not having to hardcode the modules nor the > version in the application.xml file. For example: > > 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd";> > > Simple EAR for testing > > > simple-war-0.6-SNAPSHOT.war > /simpleweb > > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-431) Upload request for NLOG4J 1.2.14 and SLF4J 1.0-beta4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-431?page=comments#action_42703 ] Nick Faiz commented on MAVENUPLOAD-431: --- Hi, Any word on using the attached POM (check the zip) to place nlog4j.1.2.14 on the maven repository? As soon as it is listed somewhere we can begin to incorporate slf4j logging in Apache DS. Let me know if the dependencies are okay. If they are I will complete POMs for the slf4j jars, also. Nick > Upload request for NLOG4J 1.2.14 and SLF4J 1.0-beta4 > > > Key: MAVENUPLOAD-431 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-431 > Project: maven-upload-requests > Type: Task > Reporter: Alex Karasulu > Attachments: nlog4j-1.2.14.zip > > > These files have been listed below rather than using a bundle. The bundle > path is really a URL to our repo at safehaus where we keep these files. They > are not maven based projects so we do not have a project.xml to do this. > http://maven.safehaus.org/nlog4j/jars/nlog4j-1.2.14.jar > http://maven.safehaus.org/slf4j/jars/slf4j-jdk14-1.0-beta4.jar > http://maven.safehaus.org/slf4j/jars/slf4j-nop-1.0-beta4.jar > http://maven.safehaus.org/slf4j/jars/slf4j-simple-1.0-beta4.jar > Thanks, > Alex -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42701 ] Stephane Nicoll commented on MNG-563: - Vincent, I don't agree. Application.xml generation is there since the first version of the plugin, see MNG-148. This issue is *NOT* about application.xml generation: if you look the patches, it just adds a new ear lifecycle and a flag to enable/disable application.xml generation (but not generation itself). I think issues should reflect exactly what has been done. > Add generation of application.xml in EAR plugin > --- > > Key: MNG-563 > URL: http://jira.codehaus.org/browse/MNG-563 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Reporter: Vincent Massol > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > It sems the current version in SVN trunk does not support generating the > application.xml file. It does support adding EAR modules though. Generating > application.xml would allow not having to hardcode the modules nor the > version in the application.xml file. For example: > > 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd";> > > Simple EAR for testing > > > simple-war-0.6-SNAPSHOT.war > /simpleweb > > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42699 ] Stephane Nicoll commented on MNG-563: - Someone with Edit right, could you please change the issue's summary. This is not about generating the application.xml ; this is about the ear lifecycle integration in m2. > Add generation of application.xml in EAR plugin > --- > > Key: MNG-563 > URL: http://jira.codehaus.org/browse/MNG-563 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Reporter: Vincent Massol > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > It sems the current version in SVN trunk does not support generating the > application.xml file. It does support adding EAR modules though. Generating > application.xml would allow not having to hardcode the modules nor the > version in the application.xml file. For example: > > 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd";> > > Simple EAR for testing > > > simple-war-0.6-SNAPSHOT.war > /simpleweb > > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42700 ] Vincent Massol commented on MNG-563: Stephane, I don't think the issue(s summary should be changed. I was not able to find any issue about generating the EAR application.xml so let's decide that this is the issue about this. Also, I don't want to change the description too which is really about "generation of application.xml" and not the lifecycle. Let's keep it. I don't think it'll cause any harm and it'd good to have an issue for any development task that happens. > Add generation of application.xml in EAR plugin > --- > > Key: MNG-563 > URL: http://jira.codehaus.org/browse/MNG-563 > Project: Maven 2 > Type: New Feature > Components: maven-plugins > Versions: 2.0-alpha-3 > Reporter: Vincent Massol > Attachments: maven-core-ear-lifecycle.patch, maven-ear-lifecycle.patch > > > It sems the current version in SVN trunk does not support generating the > application.xml file. It does support adding EAR modules though. Generating > application.xml would allow not having to hardcode the modules nor the > version in the application.xml file. For example: > > 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd";> > > Simple EAR for testing > > > simple-war-0.6-SNAPSHOT.war > /simpleweb > > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-575) Add a way to configure permissions on deployed files
Add a way to configure permissions on deployed files Key: MNG-575 URL: http://jira.codehaus.org/browse/MNG-575 Project: Maven 2 Type: Improvement Components: maven-artifact Versions: 2.0-alpha-3 Reporter: Kenney Westerhof [actually maven-artifact-manager..?] Since my umask = 077, m2 deploy stores files in the remote repository that aren't accessible by httpd. I need to provide file permissions in the repository configuration in the pom or in the settings.xml server definitions (perhaps the repo's, but permissions should go with authentication information I think). Wagon already supports filemode and group settings on it's Repositories. DefaultWagonManager doesn't provide a way to fill those settings. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-574) Add version info to plugins.xml and cache that in plugin-registry.xml
Add version info to plugins.xml and cache that in plugin-registry.xml - Key: MNG-574 URL: http://jira.codehaus.org/browse/MNG-574 Project: Maven 2 Type: Improvement Reporter: Kenney Westerhof Priority: Minor By caching that information locally, maven only has to check one url to see if a plugin is up-to-date, rather than open a connection for each plugin encountered. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-573) Last artifactId under project/plugins/plugin overrides project/artifactId
Last artifactId under project/plugins/plugin overrides project/artifactId - Key: MNG-573 URL: http://jira.codehaus.org/browse/MNG-573 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-beta-1, 2.0-alpha-3 Environment: m2 alpha 3 and latest from SVN Reporter: Carlos Sanchez When calling install with this pom it gets installed under $REPO/org\apache\maven\plugins\maven-surefire-plugin\1.2.1\maven-surefire-plugin-1.2.1.pom 4.0.0 springframework spring-parent 1.2.1 pom org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 org.apache.maven.plugins maven-surefire-plugin test **/*Tests.* The bug also happens when removing the packaging tag. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
