[jira] Commented: (MRM-100) Make ProxyConfiguration into a plexus configuration object
[ http://jira.codehaus.org/browse/MRM-100?page=comments#action_60966 ] Edwin Punzalan commented on MRM-100: This is already a plexus objject... just need to be able to configure it in components.xml. Right now, creating a components.xml for its configuration will be overwritten by the autogenerated components.xml from the plexus annotations. > Make ProxyConfiguration into a plexus configuration object > -- > > Key: MRM-100 > URL: http://jira.codehaus.org/browse/MRM-100 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > > -- 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-781) please replace maven-qalab-plugin 2.1 with this one - the last one was missing something vital
[ http://jira.codehaus.org/browse/MAVENUPLOAD-781?page=all ] Carlos Sanchez closed MAVENUPLOAD-781: -- Assign To: Carlos Sanchez Resolution: Fixed > please replace maven-qalab-plugin 2.1 with this one - the last one was > missing something vital > -- > > Key: MAVENUPLOAD-781 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-781 > Project: maven-upload-requests > Type: Bug > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-2.1-bundle.jar > > > Last night I inadvertantly made a bundle of the wrong version of my maven2 > qalab plugin. (see MAVENUPLOAD-780) > the attached file is the correct bundle. many apologies. -- 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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_60970 ] Grzegorz Slowikowski commented on MAVENUPLOAD-780: -- Sometimes I see here artifact versions that are not present yet on their sites. Yhis situation is here. Latest version of QALab is 1.7.2. I checked in project cvs - latest tag is QALAB_0_7_2. So, version 0.8 will be on ibiblio before on sourceforge? > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-105) Use cacheFailure configuraion in remote repositories
Use cacheFailure configuraion in remote repositories Key: MRM-105 URL: http://jira.codehaus.org/browse/MRM-105 Project: Maven Repository Manager Type: New Feature Components: remote proxy Reporter: Edwin Punzalan Currently a todo in the source code -- 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: (MPECLIPSE-85) Support for "lib" classpathentry
[ http://jira.codehaus.org/browse/MPECLIPSE-85?page=comments#action_60975 ]
James Shute commented on MPECLIPSE-85:
--
I have such a scenario. My project uses xmlbeans - for ease of deployment and
avoiding incompatibility issues I want the xmlbeans generated classes to be in
my jar.
This is easy to achieve with the main maven build, however it is not so easy to
integrate with Eclipse.
The most reliable way I have found (*) is to just add the jar that the xmlbeans
build creates as a reference in the eclipse project. I don't want this jar to
be public so putting it in the repository as suggested is not appropriate.
To achieve this with the eclipse plugin as it stands I've had to set the
maven.eclipse.classpath.include property to include my jar file, and then use a
in a post-goal to turn the reference type into a lib, which is a bit
ugly.
* I haven't been able to find any other approach that works for Eclipse that
doesn't delete all the .class files when you do a Project -> Clean
> Support for "lib" classpathentry
>
>
> Key: MPECLIPSE-85
> URL: http://jira.codehaus.org/browse/MPECLIPSE-85
> Project: maven-eclipse-plugin
> Type: New Feature
> Reporter: Flemming Seerup
> Assignee: fabrizio giustina
> Priority: Trivial
> Fix For: 1.10
>
>
> To generate lib classpath entries for jar files not in maven repositories, I
> have added the following code to classpath.jelly locally (after processing of
> maven.eclipse.conclasspath property):
> delim=",">${maven.eclipse.libclasspath}
>
>
>
--
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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_60976 ] Dave Sag commented on MAVENUPLOAD-780: -- I tried to tag the qalab cvs for the maven2 plugin i have written but got a disk-full error back from soureforge. the qalab guys sent me the bundles for the qalab core and the m1 plugin to be deployed as I am familiar with the process for m2. i'll get in touch with the qalab project lead and request he update the main site to be in sync. hope that's okay with you and explains any discrepancies. > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-12) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MWAR-12?page=comments#action_60977 ] Jan Grzelak commented on MWAR-12: - May this issue be included in roadmap for 2.0 version? I believe that many users waiting for this to be resolved (see also number of voters and watchers on this issue). Thank you. > Add resource filtering to war plugin > > > Key: MWAR-12 > URL: http://jira.codehaus.org/browse/MWAR-12 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Mark Hobson > Assignee: Brett Porter > Attachments: AbstractWarMojo.patch, MWAR-12.patch, ResourcesMojo.patch, > test.zip > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'd like to patch the war plugin to perform resource filtering as per the > resources plugin. This is a trivial patch but would duplicate the following > code from the resources plugin: > PropertyUtils > ReflectionProperties > ResourcesMojo.copyFile(File, File) > These look like handy util methods that could be incorporated into > plexus-utils - what do the developers think? > Also not sure how resource filtering will be affected by MNG-788. -- 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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_60978 ] Grzegorz Slowikowski commented on MAVENUPLOAD-780: -- Some time ago I came to a conclusion that is't not too hard to upload some kind of "troyan" boundle to ibiblio. Your request is a good example. Carlos has no possibility to verify your boundle, what it really contains. There is no distribution on sourceforge to compare with. > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- 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: (MJAVADOC-28) [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name
[ http://jira.codehaus.org/browse/MJAVADOC-28?page=all ] Martin Desruisseaux updated MJAVADOC-28: Attachment: test.zip > [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name > - > > Key: MJAVADOC-28 > URL: http://jira.codehaus.org/browse/MJAVADOC-28 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: Windows XP > Reporter: Martin Desruisseaux > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: test.zip > > Time Spent: 1 hour, 30 minutes >Remaining: 0 minutes > > See or link tags of the kind [EMAIL PROTECTED] org.mypackage} doesn't work > with maven-javadoc-plugin (we get a "Tag @link: reference not found: > org.mypackage" warning), while it work when using the javadoc tool from the > command line or from an Ant script. I suspect that this is related to the way > maven-javadoc-plugin work, which provides a list of source files as a @files > argument. > A possible workaround is to provide a way to use the maven-javadoc-plugin > through the javadoc's -subpackages option, instead of letting > maven-javadoc-plugin creates a @files. It would gives more control to the > user, would allows the current parameter to work (this > parameter is currently useless since it is ignored when the files to process > are provided in @files), and would solve the problem reported in this JIRA > issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_60982 ] Carlos Sanchez commented on MAVENUPLOAD-780: This is an open source project that relies in trust between people. While we try to do our best regarding security, it's not practical right now to enforce a complex security mechanism which would cause a huge overload. i'm pretty sure there're companies that can take care of that issues ( I could give you names ;) ) > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- 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-2149) Why have aggregator projects? Can't we just add tags in normal pom.xml files and have them behave transitively?
Why have aggregator projects? Can't we just add tags in normal
pom.xml files and have them behave transitively?
-
Key: MNG-2149
URL: http://jira.codehaus.org/browse/MNG-2149
Project: Maven 2
Type: Wish
Components: Reactor and workspace
Versions: 2.0.2
Reporter: David Boden
Priority: Critical
At the moment, we have to have an aggregator xml file with
pom in order to build multiple modules.
Why can't my ss_base_applet module contain:
../ss_base_shared
This would mean that whenever ss_base_applet was built, it built ss_base_shared
too (taking into account the dependency definitions to work out the order).
There would, of course, need to be a command line switch to say ("don't build
sub modules"). It already exists!
-N,--non-recursiveDo not recurse into sub-projects
Here's my current aggregator pom. I'd much prefer to define these transitively
in the same way that I can define the dependencies transitively:
../SSBuild
../FET_S
../ss_base_shared
../ss_offering_shared
../ss_offering_lib
../ss_base_applet
../sales_station_lib
../sales_station_applet
../SS
../cds_ss_shared
../cds_ss_applet
../cds_ss_lib
../CDSSS
../CDSSS-ear
../gov_ss_base_shared
../gov_ss_base_applet
../egb_ss_lib
../credit_ss_lib
../ss_cats_lib
../ss_ecn_handler
../egb_ss_ecn_handler
../egb_ss_shared
../egb_ss_applet
../credit_ss_applet
../credit_ss_shared
../EgbSS
../EgbSS-ear
--
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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_60983 ] Dave Sag commented on MAVENUPLOAD-780: -- I think also, given that it's easy to verify that I am a member of the project team from the contributor URL, it's highly unlikely I would poison my own project. also given anyone requesting uploading of bundles will, in most cases, be providing such details and will also be a logged in user of this jira server, there is a clear trail of accountability. > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-106) Keep only one http proxy configuration and have each repository whether to use it or not
Keep only one http proxy configuration and have each repository whether to use it or not Key: MRM-106 URL: http://jira.codehaus.org/browse/MRM-106 Project: Maven Repository Manager Type: Improvement Components: remote proxy Reporter: Edwin Punzalan -- 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-36) SurefireBooter's use of colon ":" character for delimeting classpath results in drive letter to be parsed as a seperate classpath entry
SurefireBooter's use of colon ":" character for delimeting classpath results in drive letter to be parsed as a seperate classpath entry --- Key: SUREFIRE-36 URL: http://jira.codehaus.org/browse/SUREFIRE-36 Project: surefire Type: Bug Reporter: John Tolentino Assigned to: Jason van Zyl Attachments: maven-surefire.diff D:\classpath1:C:\classpath2:C:\classpath3 is parsed as 6 Classpath strings: D \classpath1 C \classpath2 C \classpath3 The colon ":" delimeter is used both in the generated properties file and parsing. Attached patch resolves this issue. Might also be related to MSUREFIRE-43. -- 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: (MSUREFIRE-43) Surefire fails to start when the local repository and the project (pom.xml) lives in different window drives
[ http://jira.codehaus.org/browse/MSUREFIRE-43?page=comments#action_60984 ]
John Tolentino commented on MSUREFIRE-43:
-
Might be related to SUREFIRE-36. Already submitted a patch. Please check if the
problem persists after patch is applied.
> Surefire fails to start when the local repository and the project (pom.xml)
> lives in different window drives
>
>
> Key: MSUREFIRE-43
> URL: http://jira.codehaus.org/browse/MSUREFIRE-43
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.1.2
> Environment: Windows XP
> Java 1.5.0_06
> Maven 2.0.1
> Surefire fork mode: once
> Reporter: Martin Desruisseaux
>
>
> We have the following situation:
> - Local repository in {{C:\Documents and Settings\user\.m2}}
> - A Maven 2 project in {{P:\MyProject}}.
> - Surefire fork mode set to "once".
> In this configuration, surefire fails with this (somewhat misleading) error
> message:
> {quote}
> Setting reports dir: {{P:\MyProject\target/surefire-reports}}
> BUILD ERROR
> There are some test failure.
> {quote}
> This message is misleading because it suggests that some user's tests failed,
> while actually Surefile didn't executed a single one. It even failed before
> to create the {{surefire-reports}} directory! So we have no indication about
> the cause, and printing the stack trace with the {{-e}} option doesn't help
> much (I suspect that this is because the stack trace was actually produced by
> a different virtual machine instance, and was not passed to the JVM running
> Maven). Running Maven with the {{-X}} option provides more hints however. We
> can see that Maven try to executes the following command:
> {{java -Xmx512M -enableassertions -classpath
> "C:\...snip...\.m2\repository\org\apache\maven\surefire\surefire-booter\1.5.2\surefire-booter-1.5.2.jar;
> C:\Java\Apache\Maven2\bin\..\core\plexus-utils-1.0.5.jar"
> org.apache.maven.surefire.SurefireBooter P:\MyProject}}
> Running this command manually gives the following output:
> {code}
> ClassLoader: typeclass sun.misc.Launcher$ExtClassLoader, value=...snip...
>: file:/C:/Java/1.5/jre/lib/ext/sunjce_provider.jar
>: file:/C:/Java/1.5/jre/lib/ext/sunpkcs11.jar
>(...snip...)
> ClassLoader: typeclass sun.misc.Launcher$AppClassLoader, value=...snip...
>: file:/C:/Documents ...snip... /.m2/repository/ ...snip..
> ./surefire-booter-1.5.2.jar
>: file:/C:/Java/Apache/Maven2/core/plexus-utils-1.0.5.jar
> ClassLoader: typeclass org.apache.maven.surefire.IsolatedClassLoader,
> value=...snip...
>: file:/P:/MyProjects/
>(...snip...)
>: file:/P:/Documents and
> Settings/user/.m2/repository/...snip.../surefire-1.5.2.jar
> Exception in thread "main" java.lang.ClassNotFoundException:
> org.apache.maven.surefire.Surefire
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>(...snip...)
> {code}
> As you can see, the path for {{surefire-1.5.2.jar}} wrongly refer to the
> drive letter {{P:}}. It should be {{C:}} 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] Updated: (MRM-106) Keep only one http proxy configuration and have each repository whether to use it or not
[ http://jira.codehaus.org/browse/MRM-106?page=all ] Edwin Punzalan updated MRM-106: --- Assign To: Edwin Punzalan Remaining Estimate: 1 hour Original Estimate: 1 hour > Keep only one http proxy configuration and have each repository whether to > use it or not > > > Key: MRM-106 > URL: http://jira.codehaus.org/browse/MRM-106 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour > Remaining: 1 hour > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=comments#action_60986 ] John Tolentino commented on MWAR-24: I agree. But since the full path with filename is specified, we can substitute other container config's path to the context.xml path right? So a non-container-specific solution would be calling the parameter as containerConfig (or something similar) instead. > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- 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: (MDEPLOY-26) Deploy to an interal repository, different from the one definied in the pom.xml
Deploy to an interal repository, different from the one definied in the pom.xml --- Key: MDEPLOY-26 URL: http://jira.codehaus.org/browse/MDEPLOY-26 Project: Maven 2.x Deploy Plugin Type: New Feature Versions: 2.1 Reporter: Geoffrey De Smet Fix For: 2.3 Use-case 1 I (not a developper) checkout Codehaus Mojo's jasperreports plugin and want to install it in my company remote repository. The pom.xml is read-only of the jasperreports (because I might create patches later). Use-case 2 I checkout spring-richclient and want to deploy the latest snapshot in my company remote repository. However the configured repistory in the pom.xml is another one. I cannot use the repo of spring-richclient, because they sometimes break backwards compability at the moment in their snapshots. mvn deploy:deploy will try to deploy it to the repository defined in the pom.xml mvn deploy:deploy-file is to much hassle with the exported pom, ..., especially in a multiproject mvn deploy -DdeploymentRepository=scp://myInteralRepository does not work, deploymentRepository is ignored. A solution would be with mvn deploy -DsomeParameter=scp://myInteralRepository See also the user mailing list thread "mvn deploy external project to internal remote repository" -- 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: (MJAVADOC-56) excludePackageNames should accept wildars
[ http://jira.codehaus.org/browse/MJAVADOC-56?page=all ] Maria Odea Ching updated MJAVADOC-56: - Remaining Estimate: 6 hours Original Estimate: 6 hours > excludePackageNames should accept wildars > - > > Key: MJAVADOC-56 > URL: http://jira.codehaus.org/browse/MJAVADOC-56 > Project: Maven 2.x Javadoc Plugin > Type: Improvement > Reporter: Michael Böckling > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > > Original Estimate: 6 hours > Remaining: 6 hours > > We want o exclude *.internal* packages from Javadoc generation, but the > current implementation only permits fully qualified package names. An ANT > style exclude pattern would be nice, but I gues that depends on > FileUtils.getFilesFromExtension() supporting an exclusions argument? Never > understood anyway why (the imho pretty nice) ANT DirectoryScanner is not > used, and plextools reinvent the wheel... -- 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-2150) Dependencies crash with NullPointerException on system dependencies
Dependencies crash with NullPointerException on system dependencies
---
Key: MNG-2150
URL: http://jira.codehaus.org/browse/MNG-2150
Project: Maven 2
Type: Bug
Components: Dependencies
Versions: 2.0.2
Environment: Crash happens on windows and Linux.
Reporter: Julian Payne
In my pom I have the following dependency:
jre
javaws
1.5.0
jar
system
${java.home}/lib/javaws.jar
This dependency is correctly resolved and found but when I run "site-deploy"
the "dependencies" report crashes as shown below:
[INFO] Generate "Dependencies" report.
[INFO] -
---
[ERROR] FATAL ERROR
[INFO] -
---
[INFO] null
[INFO] -
---
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:82)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:63)
at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo
sitory(DefaultMavenProjectBuilder.java:386)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposito
ry(DefaultMavenProjectBuilder.java:351)
at org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRe
nderer.getMavenProjectFromRepository(DependenciesReport.java:362)
at org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRe
nderer.renderBody(DependenciesReport.java:242)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render(Abstrac
tMavenReportRenderer.java:65)
at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(
DependenciesReport.java:157)
at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMaven
Report.java:98)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] John Tolentino reopened MWAR-24: Rename parameter to a non-container specific identifier. > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- 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: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] John Tolentino updated MWAR-24: --- Attachment: MWAR-24-maven-war-plugin.diff > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-24-maven-war-plugin.diff, contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- 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: (MRM-106) Keep only one http proxy configuration and have each repository whether to use it or not
[ http://jira.codehaus.org/browse/MRM-106?page=all ] Edwin Punzalan closed MRM-106: -- Resolution: Fixed > Keep only one http proxy configuration and have each repository whether to > use it or not > > > Key: MRM-106 > URL: http://jira.codehaus.org/browse/MRM-106 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour > Remaining: 1 hour > -- 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: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] John Tolentino updated MWAR-24: --- Attachment: MWAR-24-maven-war-plugin.diff > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-24-maven-war-plugin.diff, MWAR-24-maven-war-plugin.diff, > contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- 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: (MRM-106) Keep only one http proxy configuration and have each repository whether to use it or not
[ http://jira.codehaus.org/browse/MRM-106?page=all ] Edwin Punzalan updated MRM-106: --- Remaining Estimate: 0 minutes (was: 1 hour) > Keep only one http proxy configuration and have each repository whether to > use it or not > > > Key: MRM-106 > URL: http://jira.codehaus.org/browse/MRM-106 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour >Time Spent: 30 minutes > Remaining: 0 minutes > -- 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: (CONTINUUM-610) Add section about building recursively from parent to FAQ and provide more information on adding shell projects
[ http://jira.codehaus.org/browse/CONTINUUM-610?page=all ] Emmanuel Venisse closed CONTINUUM-610: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 Applied. Thanks. > Add section about building recursively from parent to FAQ and provide more > information on adding shell projects > --- > > Key: CONTINUUM-610 > URL: http://jira.codehaus.org/browse/CONTINUUM-610 > Project: Continuum > Type: Improvement > Components: Documentation > Reporter: Mang Lau > Assignee: Emmanuel Venisse > Priority: Minor > Fix For: 1.0.3 > Attachments: shell-info.patch, site-changes.patch > > > Updated the following: > about.fml > - updated "How do I write documentation for Continuum?" section > faq.fml > - added section about building recursively from parent > *Note:* I had the same [issue|http://jira.codehaus.org/browse/CONTINUUM-506] > as Dennis when generating the site. > getting started - index.apt > - provided more detail on adding shell projects -- 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: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] John Tolentino updated MWAR-24: --- Attachment: (was: MWAR-24-maven-war-plugin.diff) > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-24-maven-war-plugin.diff, contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-107) Remove unnecessary maven-proxy classes from the remote-proxy
Remove unnecessary maven-proxy classes from the remote-proxy Key: MRM-107 URL: http://jira.codehaus.org/browse/MRM-107 Project: Maven Repository Manager Type: Improvement Components: remote proxy Reporter: Edwin Punzalan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] Edwin Punzalan closed MWAR-24: -- Resolution: Fixed > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-24-maven-war-plugin.diff, contextXml.patch > > Time Spent: 3 hours, 15 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- 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: (CONTINUUM-412) Add a "Build Now" link after each build definition
[ http://jira.codehaus.org/browse/CONTINUUM-412?page=all ] Emmanuel Venisse closed CONTINUUM-412: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 Done. > Add a "Build Now" link after each build definition > -- > > Key: CONTINUUM-412 > URL: http://jira.codehaus.org/browse/CONTINUUM-412 > Project: Continuum > Type: Wish > Components: Web interface > Versions: 1.0 > Reporter: David Blevins > Assignee: Emmanuel Venisse > Priority: Minor > Fix For: 1.0.3 > > > It would be great to have a "Build Now" link on the same line as each build > definition on a project's "Info" screen. Then it would be possible to force > a build of a specific build definition in a project. > This also solves another thing that I found it was oddly not possible to kick > off a build from any of the project detail screens (Info, Builds, Working > Copy). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-34) Add resources to source folders instead of module libraries
Add resources to source folders instead of module libraries --- Key: MIDEA-34 URL: http://jira.codehaus.org/browse/MIDEA-34 Project: Maven 2.x Idea Plugin Type: Bug Versions: 2.0 Reporter: Manfred Geiler Priority: Critical Attachments: idea-1.patch Having the resources as module libraries does not make much sense. Instead the resources dir(s) should be added as normal idea source folders, so that editing of properties files, xml files, etc. is possible. see applied patch Regards, Manfred -- 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: (MSITE-103) finish refactoring of category summary pages and index page report
[ http://jira.codehaus.org/browse/MSITE-103?page=all ] Brett Porter closed MSITE-103: -- Resolution: Fixed > finish refactoring of category summary pages and index page report > -- > > Key: MSITE-103 > URL: http://jira.codehaus.org/browse/MSITE-103 > Project: Maven 2.x Site Plugin > Type: Task > Reporter: Brett Porter > Assignee: Brett Porter > Priority: Blocker > Fix For: 2.0 > > Original Estimate: 2 hours >Time Spent: 6 hours > Remaining: 0 minutes > -- 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: (MSITE-58) Ability to assign a report to choosen navigation menu
[ http://jira.codehaus.org/browse/MSITE-58?page=all ] Brett Porter closed MSITE-58: - Assign To: Brett Porter Resolution: Fixed Fix Version: 2.0 > Ability to assign a report to choosen navigation menu > -- > > Key: MSITE-58 > URL: http://jira.codehaus.org/browse/MSITE-58 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Michal Maczka > Assignee: Brett Porter > Priority: Minor > Fix For: 2.0 > > > It will be nice to have a possibiliy of deciding per report basis where (in > which menu) given report will appear in the left side navigation instead of > putting all reports into one bag (reports menu). -- 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: (WAGON-32) Implement WebDAV Provider
[ http://jira.codehaus.org/browse/WAGON-32?page=comments#action_61003 ] Cédric Vidal commented on WAGON-32: --- Being able to upload to a maven repository using webdav would be really usefull !! Come on, this feature deserves a medium or even high priority ;) > Implement WebDAV Provider > - > > Key: WAGON-32 > URL: http://jira.codehaus.org/browse/WAGON-32 > Project: wagon > Type: New Feature > Reporter: Joakim Erdfelt > Assignee: Joakim Erdfelt > Priority: Minor > > > Implement a WebDAV provider for wagon. > url syntax would be - dav://hostname/path/to/resource/ > client library to come from the Apache Slide 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: (MANTLR-5) added source scanning so grammar configuration no longer required
added source scanning so grammar configuration no longer required - Key: MANTLR-5 URL: http://jira.codehaus.org/browse/MANTLR-5 Project: Maven 2.x Antlr Plugin Type: Improvement Reporter: Jesse McConnell Attachments: antlr.patch I was testing the NoSecurityManager mechanism of getting around system.exit() in the antlr tool's main method and noticed that this plugin had to have the grammar specified in the configuration so I wired in the stale source scanner from my other plugins works like a charm, you can either specify the grammar or you can rely on the stale source scanner to find them like before, will not reexecute antlr if the source grammar hasn't changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-35) Module Libraries and WebModule libraries to package should not have a name attribute
Module Libraries and WebModule libraries to package should not have a name attribute Key: MIDEA-35 URL: http://jira.codehaus.org/browse/MIDEA-35 Project: Maven 2.x Idea Plugin Type: Bug Versions: 2.0 Reporter: Manfred Geiler Priority: Blocker Attachments: idea-2.patch Idea 5.x does not seem to support name attributes in module library definitions. At least it leads to buggy behavior when WebModule settings are involved. There is no way to add a module library with a name from within IDEA. So what the plugin is using here is an undocumented feature that leads to strange results. The solution is to add the module libraries without the name attribute and to add the WebModule containerElements without a name too. Instead the jar URL is added to the containerElement. see applied patch Cheers, Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-35) Module Libraries and WebModule libraries to package should not have a name attribute
[ http://jira.codehaus.org/browse/MIDEA-35?page=comments#action_61005 ] Geoffrey De Smet commented on MIDEA-35: --- This might be the reason of the TODO in my patch (which is already applied): IntelliJ would ignore the setting to copy a library to WEB-INF/lib. > Module Libraries and WebModule libraries to package should not have a name > attribute > > > Key: MIDEA-35 > URL: http://jira.codehaus.org/browse/MIDEA-35 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Blocker > Attachments: idea-2.patch > > > Idea 5.x does not seem to support name attributes in module library > definitions. At least it leads to buggy behavior when WebModule settings are > involved. > There is no way to add a module library with a name from within IDEA. So what > the plugin is using here is an undocumented feature that leads to strange > results. > The solution is to add the module libraries without the name attribute and to > add the WebModule containerElements without a name too. Instead the jar URL > is added to the containerElement. > see applied patch > Cheers, > Manfred -- 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-56) Refactor DirectoryMojo so it can be run either stand-alone or attached
[ http://jira.codehaus.org/browse/MASSEMBLY-56?page=comments#action_61007 ] John Casey commented on MASSEMBLY-56: - What about naming it something like "directory-in-lifecycle" or something. I know it's an ugly name, but it's not like this is something people should be typing on the command line...in fact, it's designed *not* to be used from the command line. I think the important thing with the name is that it shouldn't reflect anything about attachment, since the attachment isn't really the defining factor for separating this from the normal :directory mojo...instead, maybe it should reflect the fact that it's meant to run as part of a lifecycle, rather than on its own. Come to think of it, perhaps we should rename the assembly:attached mojo to reflect this same thing, since I think the use case is the same. As for whether we need this mojo or not, my only concern is that the assembly:directory mojo might launch a forked lifecycle that would run up to the 'package' phase if it were bound directly into the lifecycle itself. This would be pretty inefficient, since what you really want is to tell Maven that the prerequisites for this mojo will be filled during the course of the normal lifecycle. *Is* it the case that the :directory mojo would fork a new lifecycle if it were bound to the 'package' phase? I *think* the infinite looping should be fixed by now, possibly as late as the 2.0.3 code. If this mojo doesn't fork a new lifecycle, then we shouldn't bother creating the mojo described by this issue; it's a moot point. > Refactor DirectoryMojo so it can be run either stand-alone or attached > -- > > Key: MASSEMBLY-56 > URL: http://jira.codehaus.org/browse/MASSEMBLY-56 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.1 > Reporter: John Didion > Fix For: 2.1 > Attachments: MASSEMBLY-56.patch > > > Pretty straight-forward. Just make the directory goal into two goals (like > assembly and attached), one that can be run stand-alone and one that can be > run attached to a lifecycle phase. -- 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-56) Refactor DirectoryMojo so it can be run either stand-alone or attached
[ http://jira.codehaus.org/browse/MASSEMBLY-56?page=comments#action_61009 ] John Casey commented on MASSEMBLY-56: - Ok, I just verified that binding assembly:directory to the 'package' phase will indeed cause a forked lifecycle. This means we *do* need another mojo that performs the same tasks as :directory, but which will execute within the confines of the current lifecycle, rather than forking a new one. I'd probably be in favor of naming it something like "directory-inline" or something, to denote that it's meant to operate inline within a lifecycle. > Refactor DirectoryMojo so it can be run either stand-alone or attached > -- > > Key: MASSEMBLY-56 > URL: http://jira.codehaus.org/browse/MASSEMBLY-56 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.1 > Reporter: John Didion > Fix For: 2.1 > Attachments: MASSEMBLY-56.patch > > > Pretty straight-forward. Just make the directory goal into two goals (like > assembly and attached), one that can be run stand-alone and one that can be > run attached to a lifecycle phase. -- 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: (CONTINUUM-324) State images have /continuum web context hardcoded in their URL
[ http://jira.codehaus.org/browse/CONTINUUM-324?page=all ] Emmanuel Venisse closed CONTINUUM-324: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 Fixed. > State images have /continuum web context hardcoded in their URL > --- > > Key: CONTINUUM-324 > URL: http://jira.codehaus.org/browse/CONTINUUM-324 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0-alpha-4 > Reporter: Mark Hobson > Assignee: Emmanuel Venisse > Priority: Minor > Fix For: 1.0.3 > > > It appears that whereever $state.generate() is used, the resultant image src > has the default web context path of '/continuum' hardcoded in. Hence status > images break when continuum is installed to a different context. -- 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-68) Ability to view how the site would look without generating the entire site
[ http://jira.codehaus.org/browse/MSITE-68?page=comments#action_61013 ] Brett Porter commented on MSITE-68: --- reports and all are done. Basically just need to clean up to close this issue out. > Ability to view how the site would look without generating the entire site > -- > > Key: MSITE-68 > URL: http://jira.codehaus.org/browse/MSITE-68 > Project: Maven 2.x Site Plugin > Type: New Feature > Reporter: Arik Kfir > Assignee: Brett Porter > Priority: Trivial > Fix For: 2.0 > > Original Estimate: 3 hours >Time Spent: 1 hour > Remaining: 2 hours > > It would be nice to be able to run something like "m2 site:run" which would > start a process that serves the site dynamically. If you know Apache Forrest, > its similar to "forrest run" (as opposed to "forrest site" - which is like > "m2 site:site"). > The use case here, is that when writing documentation, it is frustrating to > having to generate the entire site every time you make a change - if you > simply want to preview the results. A better approach would be a Jetty (or > Tomcat?) process that receives the request from a browser, and generates the > content lazily. It would make writing m2-style docs a breeze. > In Maven 1 it would have been almost impossible, but with m2 - it might be > possible. > The only caveat I see here is having to know what report to run against each > URL. The only way I see to solve this is having reports expose (via > annotations?) the list of files they generate, but that has disadvantages as > well. > Non-the-less - this would be a killer helper plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-626) Unable to checkout source if scmurl has spaces at the end
Unable to checkout source if scmurl has spaces at the end - Key: CONTINUUM-626 URL: http://jira.codehaus.org/browse/CONTINUUM-626 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: cvs, starteam Reporter: Dan Tran Fix For: 1.0.3 When scmurl has white space at the end, continuum fails to checkout source here is an example of cvs Provider message: The cvs command failed. Command output: --- cvs server: cannot find module `oi ' - ignored cvs [checkout aborted]: cannot expand modules --- When scmurl has leading white spaces, contiuum rejects it. Can we just do a trim()? -- 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-627) Add a section on installing Continuum as a service
Add a section on installing Continuum as a service -- Key: CONTINUUM-627 URL: http://jira.codehaus.org/browse/CONTINUUM-627 Project: Continuum Type: Improvement Components: Documentation Versions: 1.0.3, 1.0.2 Reporter: Mang Lau Priority: Trivial Fix For: 1.0.3 Attachments: install-services.patch This is a patch with instructions on installing Continuum as a service in Windows. The section was added to the _Getting Started Guide_. -- 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-84) Check in release.properties into CVS during the tag then remove
Check in release.properties into CVS during the tag then remove --- Key: MRELEASE-84 URL: http://jira.codehaus.org/browse/MRELEASE-84 Project: Maven 2.x Release Plugin Type: Improvement Environment: windows 2000 Reporter: Todd Nine Is it possible to add an enhancement that will check in the release.properties before tagging takes place? Alternatively it could be added and tagged after the tagging of the initial project to ensure the tag went smoothly This way any developer can pull down the source with a give tag, say foo-1_0_5, and perform a mvn release:perform to quickly create a build. A good use would be if the local maven 2 repository is lost due to system failure, the artifacts could easily be re-created from the SCM tag. Todd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-12) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MWAR-12?page=comments#action_61018 ] Scott Tavares commented on MWAR-12: --- Hi, I'm trying to test Brian's patch out but I'm getting an error: [INFO] Building Maven Webapp Archetype [INFO]task-segment: [package] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/codehaus/plexus/util/FileUtils$FilterWrapper [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org/codehaus/plexus/util/FileUtils$FilterWrapper at org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:217) at org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:174) at org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:91) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.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) At first I thought this may be from not having the dependency on plexus-utils set correctly but I confirmed that it is. Does any one have any suggections for me? here is the POM of the maven-resources-plugin: maven-plugin-parent org.apache.maven.plugins 2.0 4.0.0 maven-resources-plugin maven-plugin Maven Resources Plugin 2.2-SNAPSHOT org.apache.maven maven-project commons-io commons-io 1.0 org.apache.maven maven-model 2.0 org.codehaus.plexus plexus-utils 1.2-SNAPSHOT and the POM for the test project i'm trying to build: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.mycompany.app my-webapp war 1.0-SNAPSHOT Maven Webapp Archetype http://maven.apache.org junit junit 3.8.1 test my-webapp src/main/filters/database.properties true src/main/webapp */.properties */.xml */.vm true src/main/webapp */ */.properties */.xml */.vm TIA -Scott- > Add resource filtering to war plugin > > > Key: MWAR-12 > URL: http://jira.codehaus.org/browse/MWAR-12 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Mark Hobson > Assignee: Brett Porter > Attachments: AbstractWarMojo.patch, MWAR-12.patch, ResourcesMojo.patch, > test.zip > > Original Estimate: 15
[jira] Commented: (MRELEASE-84) Check in release.properties into CVS during the tag then remove
[ http://jira.codehaus.org/browse/MRELEASE-84?page=comments#action_61021 ] Dan Tran commented on MRELEASE-84: -- scm:bootstrap can reproduced your build based a label. > Check in release.properties into CVS during the tag then remove > --- > > Key: MRELEASE-84 > URL: http://jira.codehaus.org/browse/MRELEASE-84 > Project: Maven 2.x Release Plugin > Type: Improvement > Environment: windows 2000 > Reporter: Todd Nine > > > Is it possible to add an enhancement that will check in the > release.properties before tagging takes place? Alternatively it could be > added and tagged after the tagging of the initial project to ensure the tag > went smoothly This way any developer can pull down the source with a give > tag, say foo-1_0_5, and perform a mvn release:perform to quickly create a > build. A good use would be if the local maven 2 repository is lost due to > system failure, the artifacts could easily be re-created from the SCM tag. > Todd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-720) JavaCC 4.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-720?page=all ] Jesse McConnell reopened MAVENUPLOAD-720: - sorry, looks like the original bundle must have been bad, the javacc jars are missing.. the bundle in the url above should now be good > JavaCC 4.0 > -- > > Key: MAVENUPLOAD-720 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-720 > Project: maven-upload-requests > Type: Task > Reporter: Jesse McConnell > Assignee: Carlos Sanchez > > > http://www.perendengue.com/stuff/javacc-4.0-bundle.jar > https://javacc.dev.java.net > javacc 4.0 release needed for updated javacc-maven-plugin to support java 5 -- 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: (MIDEA-33) Use path variables instead of absolute path to the Maven repository
[ http://jira.codehaus.org/browse/MIDEA-33?page=all ] updated MIDEA-33: -- Attachment: maven-idea-plugin.patch > Use path variables instead of absolute path to the Maven repository > --- > > Key: MIDEA-33 > URL: http://jira.codehaus.org/browse/MIDEA-33 > Project: Maven 2.x Idea Plugin > Type: New Feature > Reporter: Aleksandr Tarutin > Attachments: maven-idea-plugin.patch > > > IDEA can use variables just as well as Eclipse. They can be configured from > the Path Variables screen in the configuration and used in the .ipr or .iml > files as $M2_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: (MIDEA-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=comments#action_61037 ] Aleksandr Tarutin commented on MIDEA-34: Nice! It works for me. > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Critical > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-36) Multi-module vs. Single-module projects
[ http://jira.codehaus.org/browse/MIDEA-36?page=comments#action_61038 ] Aleksandr Tarutin commented on MIDEA-36: The plugin always creates module file in project directory. > Multi-module vs. Single-module projects > --- > > Key: MIDEA-36 > URL: http://jira.codehaus.org/browse/MIDEA-36 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Aleksandr Tarutin > > > In IDEA's single module project the module files (.iml) are created at the > same level that the project file (.ipr). > For multi-mudile projects the directory containing the project file does not > contain module files but rather contains module subdirectories each > containing the module file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-36) Multi-module vs. Single-module projects
Multi-module vs. Single-module projects --- Key: MIDEA-36 URL: http://jira.codehaus.org/browse/MIDEA-36 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Aleksandr Tarutin In IDEA's single module project the module files (.iml) are created at the same level that the project file (.ipr). For multi-mudile projects the directory containing the project file does not contain module files but rather contains module subdirectories each containing the module file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=comments#action_61039 ] Brett Porter commented on MIDEA-34: --- this seems to be an age old debate and patches seem to keep changing the behaviour. I hate the resources-as-a-library, but I want to research why it was made that way and document it once and for all before changing it back. I seem to remember it addresses some limitation in using as a source folder as it used to be. > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Critical > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-37) Add functionality to create EAR modules.
Add functionality to create EAR modules. Key: MIDEA-37 URL: http://jira.codehaus.org/browse/MIDEA-37 Project: Maven 2.x Idea Plugin Type: Improvement Reporter: Aleksandr Tarutin Add functionality to create EAR modules as per TODO added in IdeaModuleMojo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-36) Multi-module vs. Single-module projects
[ http://jira.codehaus.org/browse/MIDEA-36?page=comments#action_61042 ] Brett Porter commented on MIDEA-36: --- we can make this optional ,however it is desired behaviour. It includes all the files not included by the other projects (eg, the root pom) in intellij. this allows a global commit to commit everything, forexample > Multi-module vs. Single-module projects > --- > > Key: MIDEA-36 > URL: http://jira.codehaus.org/browse/MIDEA-36 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Aleksandr Tarutin > > > In IDEA's single module project the module files (.iml) are created at the > same level that the project file (.ipr). > For multi-mudile projects the directory containing the project file does not > contain module files but rather contains module subdirectories each > containing the module file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-10) Filtering should handle java.io.File values
[ http://jira.codehaus.org/browse/MRESOURCES-10?page=comments#action_61044
]
Jason Dillon commented on MRESOURCES-10:
Filters are useless until this has been fixed.
> Filtering should handle java.io.File values
> ---
>
> Key: MRESOURCES-10
> URL: http://jira.codehaus.org/browse/MRESOURCES-10
> Project: Maven 2.x Resources Plugin
> Type: Improvement
> Reporter: Mike Perham
>
>
> I'm trying to use filters along with ${basedir} to setup my unit test Derby
> database. Derby must have a unique directory to build its database in and
> this becomes a problem in multi-module builds.
> Currently I'm doing this:
> {code:xml}
> class="org.apache.commons.dbcp.BasicDataSource">
>name="driverClassName">org.apache.derby.jdbc.EmbeddedDriver
>name="url">jdbc:derby:target/test/testdb/${pom.artifactId};create=true
>
> {code}
> But I'd like to do this:
> {code:xml}
> class="org.apache.commons.dbcp.BasicDataSource">
>name="driverClassName">org.apache.derby.jdbc.EmbeddedDriver
>name="url">jdbc:derby:${basedir}/target/test/testdb;create=true
>
> {code}
> When I try to do the latter, I get this:
> java.lang.ClassCastException: java.io.File
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
> at java.io.Reader.read(Reader.java:100)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
> at
> org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
--
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-104) There is no way to specify the input encoding of site documents
[ http://jira.codehaus.org/browse/MSITE-104?page=all ] Brett Porter updated MSITE-104: --- Fix Version: 2.0 > There is no way to specify the input encoding of site documents > > > Key: MSITE-104 > URL: http://jira.codehaus.org/browse/MSITE-104 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Naoki Nose > Fix For: 2.0 > > > In Japan,it's necessary to specify the input encoding of site document > different from the system default, > because there is two commonly used encodings in Japanese > environment(Shift_JIS and EUC-JP). > But current maven-site-plugin doesn't provide the way to specify the input > encoding of site documents explicitly. > We need to specify it in POM. -- 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: (MRM-107) Remove unnecessary maven-proxy classes from the remote-proxy
[ http://jira.codehaus.org/browse/MRM-107?page=all ] Edwin Punzalan updated MRM-107: --- Assign To: Edwin Punzalan Remaining Estimate: 3 hours Original Estimate: 3 hours > Remove unnecessary maven-proxy classes from the remote-proxy > > > Key: MRM-107 > URL: http://jira.codehaus.org/browse/MRM-107 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 3 hours > Remaining: 3 hours > -- 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: (MJAVADOC-56) excludePackageNames should accept wildars
[ http://jira.codehaus.org/browse/MJAVADOC-56?page=all ] Maria Odea Ching updated MJAVADOC-56: - Attachment: MJAVADOC-56-maven-javadoc-plugin.patch > excludePackageNames should accept wildars > - > > Key: MJAVADOC-56 > URL: http://jira.codehaus.org/browse/MJAVADOC-56 > Project: Maven 2.x Javadoc Plugin > Type: Improvement > Reporter: Michael Böckling > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-56-maven-javadoc-plugin.patch > > Original Estimate: 6 hours > Remaining: 6 hours > > We want o exclude *.internal* packages from Javadoc generation, but the > current implementation only permits fully qualified package names. An ANT > style exclude pattern would be nice, but I gues that depends on > FileUtils.getFilesFromExtension() supporting an exclusions argument? Never > understood anyway why (the imho pretty nice) ANT DirectoryScanner is not > used, and plextools reinvent the wheel... -- 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: (MJAVADOC-56) excludePackageNames should accept wildars
[ http://jira.codehaus.org/browse/MJAVADOC-56?page=all ] Allan Ramirez closed MJAVADOC-56: - Resolution: Fixed Applied Patch. thanks! > excludePackageNames should accept wildars > - > > Key: MJAVADOC-56 > URL: http://jira.codehaus.org/browse/MJAVADOC-56 > Project: Maven 2.x Javadoc Plugin > Type: Improvement > Reporter: Michael Böckling > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-56-maven-javadoc-plugin.patch > > Original Estimate: 6 hours >Time Spent: 5 hours, 30 minutes > Remaining: 30 minutes > > We want o exclude *.internal* packages from Javadoc generation, but the > current implementation only permits fully qualified package names. An ANT > style exclude pattern would be nice, but I gues that depends on > FileUtils.getFilesFromExtension() supporting an exclusions argument? Never > understood anyway why (the imho pretty nice) ANT DirectoryScanner is not > used, and plextools reinvent the wheel... -- 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-8) Assembly plugin fails to resolve dependency when it tries to package the application
[ http://jira.codehaus.org/browse/MASSEMBLY-8?page=comments#action_61051 ] Allan Ramirez commented on MASSEMBLY-8: --- I think this issue is related to MASSEMBLY-68 > Assembly plugin fails to resolve dependency when it tries to package the > application > > > Key: MASSEMBLY-8 > URL: http://jira.codehaus.org/browse/MASSEMBLY-8 > Project: Maven 2.x Assembly Plugin > Type: Bug > Environment: windows XP Prof, Maven 2.0, maven-assembly-plugin 2.0 > Reporter: Anuerin Diaz > Assignee: Allan Ramirez > Fix For: 2.1 > > > When invoking goals in the assembly plugin, it tries to build the application > modules. However it fails when trying to resolve the dependencies because the > artifacts of the base modules are not yet installed in the local repository. > It seems that the plugin is not able to read the reactor/storage that tthe > normal compiler environment uses. > Issuing the package command on the project works so the fix should be such > that the assembly plugin utilitze the same mechanism that "mvn package" uses > for building the application, or else dont attempt to build the application > and just assume that the artifacts are already built and only needs to be > packaged as described in the "assembly descriptor". -- 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-609) Continuum deployment repository
[ http://jira.codehaus.org/browse/CONTINUUM-609?page=all ] Brett Porter updated CONTINUUM-609: --- Remaining Estimate: 3 hours Original Estimate: 3 hours > Continuum deployment repository > --- > > Key: CONTINUUM-609 > URL: http://jira.codehaus.org/browse/CONTINUUM-609 > Project: Continuum > Type: Improvement > Components: Core system > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 1.0.3 > > Original Estimate: 3 hours > Remaining: 3 hours > > What I was thinking of was having Continuum be configured to have a > repository that is the default location for deploying JARs to and that > can be served up without requiring an additional web server. This would > make configuration of a "snapshot repository" much simpler. > I'm thinking this wouldn't be required in the POM at all - that even > though the goals are "clean install", that Continuum would deploy to > this repository itself after the build completed successfully. Using > "deploy" wouldn't be desirable because you might accidentally wind up > deploying a release which is probably not what you want. > I was thinking this is purely a deployment repository, so would not be the > "local repository" for continuum at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-609) Continuum deployment repository
[ http://jira.codehaus.org/browse/CONTINUUM-609?page=all ] Brett Porter closed CONTINUUM-609: -- Resolution: Fixed > Continuum deployment repository > --- > > Key: CONTINUUM-609 > URL: http://jira.codehaus.org/browse/CONTINUUM-609 > Project: Continuum > Type: Improvement > Components: Core system > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 1.0.3 > > Original Estimate: 3 hours >Time Spent: 2 hours, 30 minutes > Remaining: 0 minutes > > What I was thinking of was having Continuum be configured to have a > repository that is the default location for deploying JARs to and that > can be served up without requiring an additional web server. This would > make configuration of a "snapshot repository" much simpler. > I'm thinking this wouldn't be required in the POM at all - that even > though the goals are "clean install", that Continuum would deploy to > this repository itself after the build completed successfully. Using > "deploy" wouldn't be desirable because you might accidentally wind up > deploying a release which is probably not what you want. > I was thinking this is purely a deployment repository, so would not be the > "local repository" for continuum at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
