[jira] Commented: (WAGON-116) Proxy authentication not authenticating with settings
[ http://jira.codehaus.org/browse/WAGON-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135059#action_135059 ] Tim Scott commented on WAGON-116: - We're having a similar problem with a proxy server requiring the setting of http_proxy as an environment variable. Is this not a way to encode the NT domain into the value? eg: http://DOMAIN%5CUSERNAME:[EMAIL PROTECTED]:PROXYPORT or: http://USERNAME%40FQDN:[EMAIL PROTECTED]:PROXYPORT > Proxy authentication not authenticating with settings > - > > Key: WAGON-116 > URL: http://jira.codehaus.org/browse/WAGON-116 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http > Environment: Linux with BlueCoat firewall/proxy >Reporter: Mykel Alvis > Fix For: 1.x > > Attachments: myfile.txt > > > On a windows machine, authenticated on an NT domain, the proxy username and > password appear to be sufficient for getting the lightweight http wagon to > download artifacts. > On a linux machine, which is connected to the domain's network but not > authenticated on the domain, the same settings do not work. > To further compound the confusion of the situation, > setting http_proxy with the specified username and password using >export http_proxy=http://USERNAME:[EMAIL PROTECTED]:PROXYPORT > allows me to use wget on an artifact's URL and retrieve it from the command > line, indicating an issue with the proxy settings for java (since a compiled > app from the command line successfully navigates the proxy). > There appears to be no additional logging available. > Attached is the output of mvn -X that shows the trace. > Currently checking out the trunk sources to attempt further debugging. -- 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: (MECLIPSE-425) NPE in install-plugins when processing JARs without a manifest file
[ http://jira.codehaus.org/browse/MECLIPSE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Schneider updated MECLIPSE-425: -- Attachment: InstallPluginsMojo.patch Patch for this issue. JARs without a manifest will be ignored. > NPE in install-plugins when processing JARs without a manifest file > --- > > Key: MECLIPSE-425 > URL: http://jira.codehaus.org/browse/MECLIPSE-425 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.5.1 > Environment: Windows XP Professional SP2 >Reporter: Roland Schneider > Attachments: InstallPluginsMojo.patch, mvn_eclipse_npe_log.txt > > > The goal "install-plugins" throws a NullPointerException when processing JARs > that don't have a manifest file. > See attached file for details. -- 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: (MECLIPSE-425) NPE in install-plugins when processing JARs without a manifest file
[ http://jira.codehaus.org/browse/MECLIPSE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135063#action_135063 ] Roland Schneider commented on MECLIPSE-425: --- Additions for Environment: maven-2.0.8 and Java 6 > NPE in install-plugins when processing JARs without a manifest file > --- > > Key: MECLIPSE-425 > URL: http://jira.codehaus.org/browse/MECLIPSE-425 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.5.1 > Environment: Windows XP Professional SP2 >Reporter: Roland Schneider > Attachments: InstallPluginsMojo.patch, mvn_eclipse_npe_log.txt > > > The goal "install-plugins" throws a NullPointerException when processing JARs > that don't have a manifest file. > See attached file for details. -- 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: (MENFORCER-17) add a new rule to enforce that no repositories are defined in the poms.
[ http://jira.codehaus.org/browse/MENFORCER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135070#action_135070 ] Jerome Lacoste commented on MENFORCER-17: - Brian, can you enlighten as to why this is a bad practise ? What should developers do ? settings.xml + proxy server ? > add a new rule to enforce that no repositories are defined in the poms. > --- > > Key: MENFORCER-17 > URL: http://jira.codehaus.org/browse/MENFORCER-17 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > > repositories in the poms are against best practices -- 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: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MPLUGIN-114: -- Component/s: API > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[
http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135076#action_135076
]
Benjamin Bentmann commented on MPLUGIN-114:
---
In version 2.4 and 2.4.1 of the maven-plugin-tools-api the line
PluginXdocGenerator.java:95 is
{code:java}
for ( Iterator it = pluginDescriptor.getMojos().iterator(); it.hasNext(); )
{code}
so either the plugin descriptor or its mojo collection seems to be null.
Is there a possibility to get your POM and a full debug output from Maven? Are
you working on an open-source project that I could checkout by myself to
reproduce this?
> PluginXdocGenerator NullPointerException
>
>
> Key: MPLUGIN-114
> URL: http://jira.codehaus.org/browse/MPLUGIN-114
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: API
>Affects Versions: 2.3
>Reporter: Garvin LeClaire
>
> When creating a site I get the following stack trace:
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95)
> at
> org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224)
> at
> org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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)
> [INFO]
>
> [INFO] Total time: 33 seconds
> [INFO] Finished at: Wed May 14 23:36:51 EDT 2008
> [INFO] Final Memory: 41M/63M
> I have tried and get the same results with version of the site plg-in back to
> 2.0-beta-3
> Any suggestions??
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MSITE-325 to MPLUGIN-114: - Affects Version/s: (was: 2.0-beta-6) 2.3 Key: MPLUGIN-114 (was: MSITE-325) Project: Maven 2.x Plugin Tools (was: Maven 2.x Site Plugin) > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-376) 'Username isn't defined.' when generating SCM report if CVS port number is specified in SCM URL
[ http://jira.codehaus.org/browse/SCM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135090#action_135090 ] Geert Pante commented on SCM-376: - with pipes, it works: scm:cvs|pserver|[EMAIL PROTECTED]:2401|/data01/cvsroot_xps|VCG_XPS/uBaseXps, So the bug is probably in the URL parsing part, url.parse(separator) should get a little smarter :-) > 'Username isn't defined.' when generating SCM report if CVS port number is > specified in SCM URL > --- > > Key: SCM-376 > URL: http://jira.codehaus.org/browse/SCM-376 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs, maven-scm-site >Affects Versions: 1.0 >Reporter: Geert Pante >Priority: Minor > > I have an CVS connection URL defined as follows: > scm:cvs:pserver:[EMAIL PROTECTED]:2401:/data01/cvsroot_bkh:VCG_BKH/uBaseBkh > When I try mvn site, the stage 'Generating "Source Repository" report.' fails > as shown below. > If I remove the :2401, it works OK. > [INFO] Generating "Source Repository" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Username isn't defined. > [INFO] > > [INFO] Trace > java.lang.IllegalArgumentException: Username isn't defined. > at > org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRootForCvsPass(CvsScmProviderRepository.java:105) > at > org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRoot(CvsScmProviderRepository.java:73) > at > org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.developerAccessCVS(ScmReport.java:479) > at > org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderDeveloperAccessSection(ScmReport.java:323) > at > org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:186) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:87) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) -- 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: (MASSEMBLY-326) unpack = false does not work
unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- 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: (MECLIPSE-381) Support code templates settings
[
http://jira.codehaus.org/browse/MECLIPSE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135116#action_135116
]
Jérémy Soula commented on MECLIPSE-381:
---
Il would be nice too to add in the configuration all the 'Code Style' section
('Clean up', 'Code templates', 'formatter', 'Organize imports') as they are all
exportable.
> Support code templates settings
> ---
>
> Key: MECLIPSE-381
> URL: http://jira.codehaus.org/browse/MECLIPSE-381
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: Core : Workspace settings
>Reporter: Martin Höller
>
> It would be nice to allow configuration of code code templates for the
> workspace just as it is currently possible with code formatters. Something
> like this in the -section:
> someUrl
--
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-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135117#action_135117 ] John Casey commented on MASSEMBLY-326: -- can you tell me which operating system you're on? This isn't an error I've ever seen before...it seems like a problem in the tar command itself, like maybe one of the files it's trying to add is messed up somehow. > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2061) javassist-3.4.GA
javassist-3.4.GA Key: MAVENUPLOAD-2061 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2061 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Attachments: javassist-3.4.GA-bundle.jar Upload javassist.jar, needed for hibernate-entitymanager-3.3.2.GA Contents of bundle was taken directly from jboss repo: http://repo1.maven.org/maven2/jboss/javassist/3.4.ga/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2062) hibernate-entitymanager-3.3.2.GA
hibernate-entitymanager-3.3.2.GA Key: MAVENUPLOAD-2062 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2062 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Attachments: hibernate-entitymanager-3.3.2.GA-bundle.jar Contents of bundle were taken directly from jboss repo except for sources jar which I created from svn tag: http://repository.jboss.org/maven2/org/hibernate/hibernate-entitymanager/3.3.2.GA/ If you choose to copy from jboss repo instead of using bundle, at least include the sources.jar from the bundle. -- 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-2062) hibernate-entitymanager-3.3.2.GA
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135120#action_135120 ] Tomislav Stojcevich commented on MAVENUPLOAD-2062: -- Depends on http://jira.codehaus.org/browse/MAVENUPLOAD-2061 > hibernate-entitymanager-3.3.2.GA > > > Key: MAVENUPLOAD-2062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2062 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: hibernate-entitymanager-3.3.2.GA-bundle.jar > > > Contents of bundle were taken directly from jboss repo except for sources jar > which I created from svn tag: > http://repository.jboss.org/maven2/org/hibernate/hibernate-entitymanager/3.3.2.GA/ > If you choose to copy from jboss repo instead of using bundle, at least > include the sources.jar from the bundle. -- 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-2061) javassist-3.4.GA
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135119#action_135119 ] Tomislav Stojcevich commented on MAVENUPLOAD-2061: -- Oops, wrong jboss repo url, use this one since hibernate-entitymanager makes this dependency: http://repository.jboss.org/maven2/javassist/javassist/3.4.GA/ > javassist-3.4.GA > > > Key: MAVENUPLOAD-2061 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2061 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: javassist-3.4.GA-bundle.jar > > > Upload javassist.jar, needed for hibernate-entitymanager-3.3.2.GA > Contents of bundle was taken directly from jboss repo: > http://repo1.maven.org/maven2/jboss/javassist/3.4.ga/ -- 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-116) Proxy authentication not authenticating with settings
[ http://jira.codehaus.org/browse/WAGON-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135122#action_135122 ] Mykel Alvis commented on WAGON-116: --- Yes. The USERNAME in the above example required that. You can also do it by export HTTP_PROXY='http://DOMAIN\USER:[EMAIL PROTECTED]:PORT' or export HTTP_PROXY="http://DOMAIN\\USER:[EMAIL PROTECTED]:PORT" First one appears more generic across shells (except for "export", of course) It would maybe be nice if there were a parameter to set for this in the provider, rather than having to juggle escaped backslashes for windows, but that's just an idea. > Proxy authentication not authenticating with settings > - > > Key: WAGON-116 > URL: http://jira.codehaus.org/browse/WAGON-116 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http > Environment: Linux with BlueCoat firewall/proxy >Reporter: Mykel Alvis > Fix For: 1.x > > Attachments: myfile.txt > > > On a windows machine, authenticated on an NT domain, the proxy username and > password appear to be sufficient for getting the lightweight http wagon to > download artifacts. > On a linux machine, which is connected to the domain's network but not > authenticated on the domain, the same settings do not work. > To further compound the confusion of the situation, > setting http_proxy with the specified username and password using >export http_proxy=http://USERNAME:[EMAIL PROTECTED]:PROXYPORT > allows me to use wget on an artifact's URL and retrieve it from the command > line, indicating an issue with the proxy settings for java (since a compiled > app from the command line successfully navigates the proxy). > There appears to be no additional logging available. > Attached is the output of mvn -X that shows the trace. > Currently checking out the trunk sources to attempt further debugging. -- 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: (ARCHETYPE-135) add a variabl containing package in a path format
[
http://jira.codehaus.org/browse/ARCHETYPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jean-Prost reopened ARCHETYPE-135:
Well, I guess there is a problem.
The variable ${packageInPathFormat} is created and then usable, but the value
is not correct. It still shows dots instead of slashes. Can you check ?
> add a variabl containing package in a path format
> -
>
> Key: ARCHETYPE-135
> URL: http://jira.codehaus.org/browse/ARCHETYPE-135
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 2.0-alpha-2
>Reporter: Dominique Jean-Prost
> Fix For: 2.0-alpha-3
>
>
> Actually, there is a variable "package" than can be used in the file during
> generation.
> It could be great if there was another variable than contained the package in
> a path format. Example :
> package = com.foo
> packageInPathFormat=com/foo
> This new variable could be used in resources path.
--
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-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135131#action_135131 ] Marco Brandizi commented on MASSEMBLY-326: -- sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 Yes, should be a problem with packaging. I've tried to remove tar.bz2, leaving zip, but a 'lib' file (not directory) is created. If i do "unzip -l lib" I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory... > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135131#action_135131 ] zakmck edited comment on MASSEMBLY-326 at 5/16/08 10:02 AM: sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove tar.bz2, leaving zip, but a 'lib' file (not directory) is created. If i do "unzip -l lib" I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. was (Author: zakmck): sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 Yes, should be a problem with packaging. I've tried to remove tar.bz2, leaving zip, but a 'lib' file (not directory) is created. If i do "unzip -l lib" I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory... > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135131#action_135131 ] zakmck edited comment on MASSEMBLY-326 at 5/16/08 10:03 AM: I have the envirnoment: Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove tar.bz2, leaving zip, but a 'lib' file (not directory) is created. If i do "unzip -l lib" I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. was (Author: zakmck): sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove tar.bz2, leaving zip, but a 'lib' file (not directory) is created. If i do "unzip -l lib" I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-157) webResources paths NOT resolved relative to pom.xml but relative to 'current directory'
webResources paths NOT resolved relative to pom.xml but relative to 'current directory' --- Key: MWAR-157 URL: http://jira.codehaus.org/browse/MWAR-157 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0 Environment: windows Reporter: koen handekyn in the documentation it is stated that directories are relative to the pom.xml which is how it should be indeed. however, the runtime behaviour is that webResources directories are resolved relative to the 'current working directory'. myup-web/src/main/web-resources -- 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-157) webResources paths NOT resolved relative to pom.xml but relative to 'current directory'
[ http://jira.codehaus.org/browse/MWAR-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135134#action_135134 ] koen handekyn commented on MWAR-157: Maven version: 2.0.9 Java version: 1.5.0_12 OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" > webResources paths NOT resolved relative to pom.xml but relative to 'current > directory' > --- > > Key: MWAR-157 > URL: http://jira.codehaus.org/browse/MWAR-157 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: windows >Reporter: koen handekyn > > in the documentation it is stated that directories are relative to the > pom.xml which is how it should be indeed. > however, the runtime behaviour is that webResources directories are resolved > relative to the 'current working directory'. > > > > myup-web/src/main/web-resources > > -- 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-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135136#action_135136 ] John Casey commented on MASSEMBLY-326: -- Can you attach your assembly descriptor, or a sanitized version of it if it contains sensitive information? I'd like to see how you're using outputDirectory vs. outputFileNameMapping... It's strange...I use OS X as well, and create tar.bz2, tar.gz, and .zip files all the time...I've never seen this. > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- 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-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135137#action_135137 ] Marco Brandizi commented on MASSEMBLY-326: -- It is attached, is bin.xml. > unpack = false does not work > > > Key: MASSEMBLY-326 > URL: http://jira.codehaus.org/browse/MASSEMBLY-326 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: OS/X 10.4, JDK1.5 >Reporter: Marco Brandizi >Priority: Blocker > Attachments: bin.xml, log.txt > > > I use the assembly attached to build a distributable version of a Java > command line tool. I'd like to have a lib/ directory with the jars the > project depends on, so that I may include them via a BASH script. > with unpack = false, I get the error in the attach. -- 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-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135140#action_135140
]
Paul Gier commented on MNG-3328:
For better compatibility with the current maven model, the syntax for this
should look more like this:
{noformat}
my-prop-1
some-value
my-prop-2
another-value
{noformat}
If either of these properties match the given value, the profile should be
activated.
In addition, the other activators (os, jvm, file, etc) should also be allowed
to have multiple values.
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: http://jira.codehaus.org/browse/MNG-3328
> Project: Maven 2
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
>
>
> some-value
> another-value
>
>
> This would provide more flexibility in profile activation.
--
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: (MENFORCER-42) Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository
[
http://jira.codehaus.org/browse/MENFORCER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135147#action_135147
]
Michael Brackx commented on MENFORCER-42:
-
This is blocking as it prevents releasing (release:prepare).
> Maven-Enforcer-Plugin fails in multimodule project when artifacts not in
> repository
> ---
>
> Key: MENFORCER-42
> URL: http://jira.codehaus.org/browse/MENFORCER-42
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.0-alpha-3, 1.0
> Environment: Tested with Maven 2.0.7 and 2.0.8 on Linux with Java 1.5
>Reporter: Martin Höller
>Assignee: Brian Fox
> Attachments: enforcer-test.tar.gz
>
>
> Create a new simple multimodule-project and call {{mvn validate}} at the
> toplevel. This leads to a build failure if none of the multimodule-artifacts
> are in your local repository.
> Attached is a simple test project for reproducing this bug.
--
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-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135148#action_135148
]
Paul Gier commented on MNG-3571:
Currently it's both. You can use exclamation or minus to deactivate a profile.
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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: (MPMD-64) verbose output not useful for inner classes
[
http://jira.codehaus.org/browse/MPMD-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPMD-64.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
With PMD 4.2.1, I observe the following output
{noformat}
[INFO] [pmd:check {execution: default}]
[INFO] PMD Failure: org.Main$LocalClass:10 ...
[INFO] PMD Failure: org.Main:15 ...
[INFO] PMD Failure: org.Main$InnerClass:22 ...
{noformat}
i.e. the top-level class and the line number are properly given, so thanks to
Xavier for his work over on PMD!
> verbose output not useful for inner classes
> ---
>
> Key: MPMD-64
> URL: http://jira.codehaus.org/browse/MPMD-64
> Project: Maven 2.x PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 2.2
>Reporter: Sean Bridges
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.4
>
> Attachments: version_update.txt
>
>
> With verbose output on, a pmd error in an inner class will produce output
> like,
> [INFO] PMD Failure: foo.bar.Anonymous$1:182
> Rule:SignatureDeclareThrowsException Priority:3 A method/constructor
> shouldn't explicitly throw java.lang.Exception.
> Rather than printing the class name, it would be more useful to print out the
> file name.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135146#action_135146
]
Paul Benedict commented on MNG-3571:
So which is it? MNG-3545 comments say it is plus and minus. This issue says
exclamation mark.
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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: (MENFORCER-42) Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository
[
http://jira.codehaus.org/browse/MENFORCER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135153#action_135153
]
Benjamin Bentmann commented on MENFORCER-42:
Seems to be related to the mail thread [Enforcer Plugin and Dependency
Resolution|http://www.nabble.com/Enforcer-Plugin-and-Dependency-Resolution-td15588057.html].
> Maven-Enforcer-Plugin fails in multimodule project when artifacts not in
> repository
> ---
>
> Key: MENFORCER-42
> URL: http://jira.codehaus.org/browse/MENFORCER-42
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.0-alpha-3, 1.0
> Environment: Tested with Maven 2.0.7 and 2.0.8 on Linux with Java 1.5
>Reporter: Martin Höller
>Assignee: Brian Fox
> Attachments: enforcer-test.tar.gz
>
>
> Create a new simple multimodule-project and call {{mvn validate}} at the
> toplevel. This leads to a build failure if none of the multimodule-artifacts
> are in your local repository.
> Attached is a simple test project for reproducing this bug.
--
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: (MENFORCER-42) Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository
[
http://jira.codehaus.org/browse/MENFORCER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135155#action_135155
]
Brian Fox commented on MENFORCER-42:
are you using enforce-once? if so, this is deprecated in the next release as we
can't make maven work correctly. In lieu of this, i added results caching to
speed things up.
> Maven-Enforcer-Plugin fails in multimodule project when artifacts not in
> repository
> ---
>
> Key: MENFORCER-42
> URL: http://jira.codehaus.org/browse/MENFORCER-42
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.0-alpha-3, 1.0
> Environment: Tested with Maven 2.0.7 and 2.0.8 on Linux with Java 1.5
>Reporter: Martin Höller
>Assignee: Brian Fox
> Attachments: enforcer-test.tar.gz
>
>
> Create a new simple multimodule-project and call {{mvn validate}} at the
> toplevel. This leads to a build failure if none of the multimodule-artifacts
> are in your local repository.
> Attached is a simple test project for reproducing this bug.
--
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: (MENFORCER-31) Incorrect documentation for writing a custom rule
[
http://jira.codehaus.org/browse/MENFORCER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MENFORCER-31:
---
Fix Version/s: 1.0
> Incorrect documentation for writing a custom rule
> -
>
> Key: MENFORCER-31
> URL: http://jira.codehaus.org/browse/MENFORCER-31
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Rule API
>Affects Versions: 1.0-alpha-3
>Reporter: Ben Lidgey
>Assignee: Brian Fox
> Fix For: 1.0
>
>
> The documentation at
> http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html has
> the wrong dependencies and code examples for creating a custom rule.
> It defines
> {code:xml}
>
> org.apache.maven.enforcer
> enforcer-api
> ${api.version}
>
> {code}
> instead of
> {code:xml}
>
> org.apache.maven.shared
> maven-enforcer-rule-api
> 1.0-alpha-2
>
> {code}
> and so the code examples are incorrect because:
> # Incorrect imports:
> #* The imports are for
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRule}}
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRuleException}}
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRuleHelper}}
> #* instead of
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRule}}
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRuleException}}
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRuleHelper}}.
> #* Implementing {{import org.apache.maven.enforcer.rule.api.EnforcerRule}}
> causes the custom plugin invocation to fail with an ArrayStoreException as
> the expected type is {{import
> org.apache.maven.shared.enforcer.rule.api.EnforcerRule}} instead.
> # It shows implementing {{public String getCacheId()}}, {{public boolean
> isCacheable()}}, {{public boolean isResultValid( EnforcerRule arg0 )}} which
> are no longer needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MENFORCER-37) 'noSnapshots' rule do not check version of parent
[ http://jira.codehaus.org/browse/MENFORCER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MENFORCER-37: --- Fix Version/s: 1.0 > 'noSnapshots' rule do not check version of parent > - > > Key: MENFORCER-37 > URL: http://jira.codehaus.org/browse/MENFORCER-37 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Tomasz Pik >Assignee: Brian Fox > Fix For: 1.0 > > > 'noSnapshots' is passing when parent is defined to be SNAPSHOT, IMHO parent > is also a dependency so it should be checked and rule should throw an error > if parent is a SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MENFORCER-38) Enforcer rules for AlwaysPass and AlwaysFail
[ http://jira.codehaus.org/browse/MENFORCER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MENFORCER-38: --- Fix Version/s: 1.0 > Enforcer rules for AlwaysPass and AlwaysFail > > > Key: MENFORCER-38 > URL: http://jira.codehaus.org/browse/MENFORCER-38 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Reporter: Ben Lidgey >Assignee: Brian Fox > Fix For: 1.0 > > Attachments: MavenEnforcerAlwaysRules.zip > > > As discussed on email, here is my first attempt at submitting some code! > It implements two rules: one always passes and the other always fails. They > are useful for checking the Enforcer rules config and possible failing the > build if a certain profile is used by setting the AlwaysFail rule in that > profile. -- 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: (MENFORCER-39) Allow simplified range checking
[ http://jira.codehaus.org/browse/MENFORCER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-39. -- Resolution: Won't Fix You can already do this as 1.0.0 means [1.0.0,) (i tweaked the interpretation of this syntax only) but we shouldn't deviate from the standard syntax any further. > Allow simplified range checking > --- > > Key: MENFORCER-39 > URL: http://jira.codehaus.org/browse/MENFORCER-39 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-3, 1.0 >Reporter: Paul Benedict >Assignee: Brian Fox >Priority: Minor > > The rule "[1.0.0,)" means at least 1.0.0 inclusive and anything greater. The > comma should be optional for single-value ranges. It can be inferred simply > from the brackets and braces what the intention is. So "[1.0.0)" should also > be a valid version range. -- 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: (MENFORCER-35) Add new rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MENFORCER-35: --- Fix Version/s: 1.0 > Add new rule RequireSkinVersion > --- > > Key: MENFORCER-35 > URL: http://jira.codehaus.org/browse/MENFORCER-35 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Fix For: 1.0 > > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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: (MENFORCER-43) RequireReleaseDeps - allow to execute "onlyWhenRelease"
[
http://jira.codehaus.org/browse/MENFORCER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MENFORCER-43:
---
Fix Version/s: 1.0
> RequireReleaseDeps - allow to execute "onlyWhenRelease"
> ---
>
> Key: MENFORCER-43
> URL: http://jira.codehaus.org/browse/MENFORCER-43
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.0-alpha-3
>Reporter: Jacob Robertson
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 1.0
>
> Attachments: onlyWhenRelease.patch.txt
>
>
> When I setup a project to use the enforcer plugin, I would like to setup the
> requireReleaseDeps rule. However, while I am in "snapshot" mode with my
> project, I'm not that concerned about whether that project depends on
> snapshots. For example, I may have a small suite of projects which are being
> developed at the same time. They may also share a common parent. (Just like
> the maven enforcer projects do) Especially in the case where I place the
> maven enforcer plugin configuration in that parent pom, it wouldn't make
> sense for me to have to "comment out" the requireReleaseDeps rule during my
> snapshot development, only to have to switch it back at release time.
> Rather, what I want to express is "enforce the requireReleaseDeps rule, but
> only when I'm a release".
> The pom snippet would look like
> {code}
>
> true
> true
>
> {code}
> I have attached a patch that shows what I'm thinking, and the updated test
> case to show that it works as expected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MENFORCER-30) RequirePluginVersions breaks when using project.parent.groupId and project.parent.version.
[
http://jira.codehaus.org/browse/MENFORCER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MENFORCER-30:
---
Fix Version/s: 1.0
> RequirePluginVersions breaks when using project.parent.groupId and
> project.parent.version.
> --
>
> Key: MENFORCER-30
> URL: http://jira.codehaus.org/browse/MENFORCER-30
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Trivial
> Fix For: 1.0
>
>
> We were using a obsolete but working child pom file, like:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> org.example.petstore
> petstore
> 0.2-SNAPSHOT
>
> ${project.parent.groupId}
> petstore-common
> 0.2-SNAPSHOT
> jar
> Common module
> The Common module.
>
> The rule will fail, when the child is not in the local or a remote
> repository, because ${project.parent.groupId} and org.example.petstore are
> not the same and the artifact can not be found.
--
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: (MENFORCER-29) Enforcer complains about its own version
[
http://jira.codehaus.org/browse/MENFORCER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MENFORCER-29:
---
Fix Version/s: 1.0
> Enforcer complains about its own version
>
>
> Key: MENFORCER-29
> URL: http://jira.codehaus.org/browse/MENFORCER-29
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.0
> Environment: GNU/Linux
>Reporter: Hilco Wijbenga
>Assignee: Brian Fox
> Fix For: 1.0
>
> Attachments: pom.xml
>
>
> The attached POM uses the latest version of the Enforcer (revision 611262),
> i.e. 1.0-SNAPSHOT. I've called it 1.0-Local-1, so that's what's defined in
> the POM.
> If I use the Enforcer normally, without a profile, everything works
> beautifully. The attached POM, however, tries to use the Enforcer from a
> profile ("enforce"). If you now try something like "mvn compile -Penforce" it
> complains about its own version not being set, even though it's specified
> *twice*.
--
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-54) Scm Wagon not expanding ${user.home}
[
http://jira.codehaus.org/browse/WAGON-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135160#action_135160
]
Ian Springer commented on WAGON-54:
---
Can you please release wagon-scm 1.0-alpha6? I really would like to have the
fix for this issue in a released version.
Thanks,
Ian
> Scm Wagon not expanding ${user.home}
>
>
> Key: WAGON-54
> URL: http://jira.codehaus.org/browse/WAGON-54
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-scm
>Affects Versions: 1.0-alpha-5
> Environment: windows xp, maven 2.0.4
>Reporter: Jean Deruelle
>Assignee: Brett Porter
> Fix For: 1.0-alpha-6
>
>
> when trying to deploy a jar to a svn repository , wagon-scm doesn't translate
> ${user.home} (because of space in the user home's windows path?) and create
> this directory in the current directory
> ...
>
>
> svn-repository
> scm:svn:https://[EMAIL
> PROTECTED]/svn/maven2-repository/trunk/repository
>
>
>
>
> org.apache.maven.wagon
> wagon-scm
> 1.0-alpha-5
>
>
> Here is the log :
> [INFO] [deploy:deploy]
> Uploading:
> scm:svn:https://maven2-repository.dev.java.net/svn/maven2-repository/trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0/maven-slee-du-plugin-1.0.jar
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository
> [INFO] Command line: svn add --non-recursive ${user.home}/.m2/repository/org
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\1.0
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive checkout
> https://maven2-repository.dev.java.net/svn/maven2-repository/
> trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0 1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive commit --file
> C:\DOCUME~1\T405732\LOCALS~1\Temp\maven-scm-465347372.commit
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error deploying artifact: Unable to commit file svn:
> 'C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\ma
> ven-slee-du-plugin' is not a 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: (MNG-3580) FATAL ERROR and NPE on start
FATAL ERROR and NPE on start Key: MNG-3580 URL: http://jira.codehaus.org/browse/MNG-3580 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) J9VM - 20080415_018762_LHdSMr JIT - r9_20080415_1520 GC - 20080415_AA) JCL - 20080412_01 Reporter: Erik Putrycz Any mvn command does give me the following error message [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Business Rules Extractor [INFO] Business Rules Extractor core functions [INFO] COBOL Parser and ANTLR Tools [INFO] Business Rules Extractor data model [INFO] Documentation Extractor module [INFO] Extractor module [INFO] Business Rules Navigator WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building Business Rules Extractor [INFO]task-segment: [install] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) at java.lang.reflect.Method.invoke(Method.java:612) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Fri May 16 13:10:16 EDT 2008 [INFO] Final Memory: 6M/19M [INFO] -- 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 o
[jira] Commented: (MENFORCER-39) Allow simplified range checking
[ http://jira.codehaus.org/browse/MENFORCER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135170#action_135170 ] Paul Benedict commented on MENFORCER-39: Any reason why you don't want to simplify it? I must admit, [1.0.0,) is just an elongated way of specifying a version number in a natural fashion. > Allow simplified range checking > --- > > Key: MENFORCER-39 > URL: http://jira.codehaus.org/browse/MENFORCER-39 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-3, 1.0 >Reporter: Paul Benedict >Assignee: Brian Fox >Priority: Minor > > The rule "[1.0.0,)" means at least 1.0.0 inclusive and anything greater. The > comma should be optional for single-value ranges. It can be inferred simply > from the brackets and braces what the intention is. So "[1.0.0)" should also > be a valid version range. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2063) iText 2.1.2 released
iText 2.1.2 released Key: MAVENUPLOAD-2063 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2063 Project: maven-upload-requests Issue Type: Task Reporter: Bruno Lowagie Hello, I have just released iText 2.1.2. You can download different bundles from this URL: http://itext.ugent.be/library/maven/ This is the core bundle: http://itext.ugent.be/library/maven/itext-2.1.2-bundle.jar There are also 3 bundles for subprojects: RUPS, Toolbox and RTF. best regards, Bruno -- 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: (MECLIPSE-451) EJB projects are not correctly referenced in .component
[
http://jira.codehaus.org/browse/MECLIPSE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135174#action_135174
]
Gabriele Contini commented on MECLIPSE-451:
---
sorry a typo in the last few lines of code. Here is how i modified the
org.eclipse.wst.common.component to make it work:
{code:xml}
EjbModule_12684337
uses
{code}
> EJB projects are not correctly referenced in .component
>
>
> Key: MECLIPSE-451
> URL: http://jira.codehaus.org/browse/MECLIPSE-451
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
>Reporter: Gabriele Contini
>Priority: Critical
>
> There is a problem generating wtp 2.0 configuration for multi-module j2ee
> applications using ejb 3.0.
> Here is my project structure.
> {noformat}
> myapp
>|--ear
>| |-- .settings
>| ||--- org.eclipse.wst.common.component
>| |
>| |-- pom.xml
>|--ejb
>| |-- pom.xml
>|
>|
> {noformat}
> here is a snippet from: myapp/ejb/pom.xml
> {code:xml}
>
> myapp-ejb
> ejb
> ...
> {code}
> here is a snippet from: myapp/ear/pom.xml
> {code:xml}
>
> ${pom.groupId}
> myapp-ejb
> ${pom.version}
> ejb
>
> {code}
> and here is a snippet from the generated org.eclipse.wst.common.component
> file in the ear project.
> {code:xml}
> handle="module:/resource/myapp-ejb/myapp-ejb">
> EjbModule_9473961
> uses
>
> {code}
> Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
> Whereas the generated application.xml the module is referenced with .jar
> extension:
> {code:xml}
>
> ---
>
> myapp-ejb.jar
>
> {code}
> I tried to override the application.xml with a custom one, but it seems that
> jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
> To make it work i modified by hand the generated
> org.eclipse.wst.common.component file in the ear project like this:
> {code:xml}
> handle="module:/resource/unirepo-core/unirepo-core">
> EjbModule_12684337
> uses
>
> {code}
> At the moment this file must be modified by hand every time i generate the
> eclipse configuration.
--
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-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated
[
http://jira.codehaus.org/browse/MNG-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135184#action_135184
]
Nate Good commented on MNG-1943:
I have just experienced this issue in a more critical use case. Here are the
details. Please let me know if you need more information.
${buildVersion} is a property defined in a profile in settings.xml and is used
in all poms.
bar
foo.bar
${buildVersion}
It seems that the problem presents itself when a project depends on an artifact
that has a parent with a non-literal value; and the parent pom is not located
on the filesystem.
Example:
pom.xml - This is the master pom that all others inherit from
Project A
pom.xml - Inherits from master pom
A.x
pom.xml - inherits from ProjectA/pom.xml
Project B
pom.xml - depends on A.x
if you run maven on ProjectB and A.x is located in a remote repository it will
fail because ${buildVersion} in A.x/pom.xml will not be interpolated before it
is used to lookup the pom.
Here is the resulting stack trace (from version 2.0.9):
Caused by: org.apache.maven.project.ProjectBuildingException:
Cannot find parent: foo.bar:xyz-pom for project:
foo.bar:prompting-client:jar:${buildVersion} for project
foo.bar:zyx-client:jar:${buildVersion}
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:106)
Is this scheduled to be fixed in the next maven release?
> MavenProject::getParent() returns a MavenProject that is NOT interpolated
> -
>
> Key: MNG-1943
> URL: http://jira.codehaus.org/browse/MNG-1943
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: John Allen
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: mng-1943-test.zip
>
>
> Plugin developers repeatedly use ${project}.getParent().someMethod() yet
> getParent() returns a project that has not been interpolated. This obviously
> needs to be fixed but may I also suggest that all plugin acceptance testing
> is revisted to ensure that the tests use POMs that are littered with property
> expressions and not literals.
--
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-230) not filtering resources, but does filter
[
http://jira.codehaus.org/browse/MASSEMBLY-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135195#action_135195
]
Oleg Alexeyev commented on MASSEMBLY-230:
-
According to my experiments, fileSets filter files ok when a sub-module in a
multi-module project is being built directly. But they do not filter files
properly if I build a parent project.
> not filtering resources, but does filter
> --
>
> Key: MASSEMBLY-230
> URL: http://jira.codehaus.org/browse/MASSEMBLY-230
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: Windows XP Maven 2.0.5
>Reporter: Mick Knutson
> Fix For: 2.2
>
>
> In my assembly descriptor, this does not filter my resources:
>
> ${basedir}/src/main/resources/deploy
> true
> true
> /
>
> *.sh
> *.bat
>
> 0544
>
> But this DOES filter the same resources just fine:
>
>
>
> ${basedir}/src/main/resources/deploy/deploy.sh.txt
> deploy
> test.sh
> true
> unix
> 0554
>
>
> I have tried 2.2-beta-1 and 2.1 of the plugin and it acts the same way.
> A workaround is to just specify each file individually, but I have dozens of
> files and the descriptor is going to get quite cluttered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-230) not filtering resources, but does filter
[
http://jira.codehaus.org/browse/MASSEMBLY-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135195#action_135195
]
blacklion edited comment on MASSEMBLY-230 at 5/16/08 4:45 PM:
--
According to my experiments, fileSets filter files ok when a sub-module in a
multi-module project is being built directly. But they do not filter files
properly if I build a parent project.
Does anybody have a workaround for that other than using individual files?
was (Author: blacklion):
According to my experiments, fileSets filter files ok when a sub-module in
a multi-module project is being built directly. But they do not filter files
properly if I build a parent project.
> not filtering resources, but does filter
> --
>
> Key: MASSEMBLY-230
> URL: http://jira.codehaus.org/browse/MASSEMBLY-230
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: Windows XP Maven 2.0.5
>Reporter: Mick Knutson
> Fix For: 2.2
>
>
> In my assembly descriptor, this does not filter my resources:
>
> ${basedir}/src/main/resources/deploy
> true
> true
> /
>
> *.sh
> *.bat
>
> 0544
>
> But this DOES filter the same resources just fine:
>
>
>
> ${basedir}/src/main/resources/deploy/deploy.sh.txt
> deploy
> test.sh
> true
> unix
> 0554
>
>
> I have tried 2.2-beta-1 and 2.1 of the plugin and it acts the same way.
> A workaround is to just specify each file individually, but I have dozens of
> files and the descriptor is going to get quite cluttered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-188) -top command line argument is passed even when java version is <1.6, generating a warning
-top command line argument is passed even when java version is <1.6, generating
a warning
-
Key: MJAVADOC-188
URL: http://jira.codehaus.org/browse/MJAVADOC-188
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Environment: jdk 1.5
Reporter: Cleber Zarate
Priority: Trivial
The -top argument is being passed when we're using a version smaller than 1.6.
Then the following warning is generated:
"[WARNING] -top option is not supported on Java version < 1.6. Ignore this
option."
This warning shouldn't be thrown since we're not setting the -top parameter in
the POM, so there's no way to ignore it.
On AbstractJavadocMojo.java, line 1492, the following method is called:
addArgIfNotEmpty( arguments, "-top", JavadocUtil.quotedArgument( top ), false,
false, SINCE_JAVADOC_1_6 );
however, this method checks the version first, and then checks if the argument
is null, like the following:
if ( isJavaDocVersionAtLeast( requiredJavaVersion ) )
{
addArgIfNotEmpty( arguments, key, value, repeatKey, splitValue );
}
else
{
if ( getLog().isWarnEnabled() )
{
getLog().warn( key + " option is not supported on Java version
< " + requiredJavaVersion
+ ". Ignore this option." );
}
}
}}
Specifically for this command line argument, the method should check the
version before calling addArgIfNotEmpty, thus removing the warning if we're not
explicitly passing the argument in a jdk < 1.6
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-112) Respect line breaks from Javadoc when generating help goal
[
http://jira.codehaus.org/browse/MPLUGIN-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPLUGIN-112.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4.2
Done in [r657239|http://svn.apache.org/viewvc?view=rev&revision=657239]. The
plain text help now also properly mimics preformatted text and lists.
> Respect line breaks from Javadoc when generating help goal
> --
>
> Key: MPLUGIN-112
> URL: http://jira.codehaus.org/browse/MPLUGIN-112
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Plugin Plugin
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 2.4.2
>
>
> The help goal is currently eating up all line breaks which makes something
> like
> {noformat}
> Line of text here.
> Another line, introducing some properties snippet:
>
> # this is some property that does intersting things
> my.very.cool.property=value
>
> {noformat}
> not really human-readable upon ouput by the help goal.
> We should
> - output line breaks for every {{}} and {{}} element
> - output line breaks for every literal line break from a {{}} block.
--
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: (WAGON-45) Unable to deploy site to svn, html files contain inconsistent new lines
[ http://jira.codehaus.org/browse/WAGON-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-45: -- Fix Version/s: (was: 1.0-beta-1) 1.0-beta-3 > Unable to deploy site to svn, html files contain inconsistent new lines > --- > > Key: WAGON-45 > URL: http://jira.codehaus.org/browse/WAGON-45 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-scm >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez >Assignee: Carlos Sanchez > Fix For: 1.0-beta-3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-41) Wagon SCM does not add correctly new files
[ http://jira.codehaus.org/browse/WAGON-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-41: -- Fix Version/s: (was: 1.0-beta-1) 1.0-beta-3 > Wagon SCM does not add correctly new files > -- > > Key: WAGON-41 > URL: http://jira.codehaus.org/browse/WAGON-41 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-scm >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 1.0-beta-3 > > Time Spent: 9 hours, 30 minutes > Remaining Estimate: 0 minutes > > If the directory to deploy the site to exists, but the files don't, the > deploy doesn't add new files. > The problem is that tries to add files target/checkout/* using > target/checkout as working dir, so the scm add fails, but Wagon doesn't check > for failure in the add command, so neither does it deploy or show the error. > We need to: > cover that case in unit tests (better if done at wagon-test level) > make wagon fail when the add command fails > make wagon add the right file name relative from the working dir -- 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: (WAGON-54) Scm Wagon not expanding ${user.home}
[
http://jira.codehaus.org/browse/WAGON-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated WAGON-54:
--
Fix Version/s: (was: 1.0-alpha-6)
1.0-beta-3
> Scm Wagon not expanding ${user.home}
>
>
> Key: WAGON-54
> URL: http://jira.codehaus.org/browse/WAGON-54
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-scm
>Affects Versions: 1.0-alpha-5
> Environment: windows xp, maven 2.0.4
>Reporter: Jean Deruelle
>Assignee: Brett Porter
> Fix For: 1.0-beta-3
>
>
> when trying to deploy a jar to a svn repository , wagon-scm doesn't translate
> ${user.home} (because of space in the user home's windows path?) and create
> this directory in the current directory
> ...
>
>
> svn-repository
> scm:svn:https://[EMAIL
> PROTECTED]/svn/maven2-repository/trunk/repository
>
>
>
>
> org.apache.maven.wagon
> wagon-scm
> 1.0-alpha-5
>
>
> Here is the log :
> [INFO] [deploy:deploy]
> Uploading:
> scm:svn:https://maven2-repository.dev.java.net/svn/maven2-repository/trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0/maven-slee-du-plugin-1.0.jar
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository
> [INFO] Command line: svn add --non-recursive ${user.home}/.m2/repository/org
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\1.0
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive checkout
> https://maven2-repository.dev.java.net/svn/maven2-repository/
> trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0 1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive commit --file
> C:\DOCUME~1\T405732\LOCALS~1\Temp\maven-scm-465347372.commit
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error deploying artifact: Unable to commit file svn:
> 'C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\ma
> ven-slee-du-plugin' is not a 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] Commented: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135206#action_135206 ] Garvin LeClaire commented on MPLUGIN-114: - I am using the GMaven stuff to work on the Find-bugs-plugin. If I try to generate a site for the sample GMaven plugins I get the same stack dump. Looking at the code above there is a bug in it since there is not a null check before working on the iterator. It seem this was brought up some time ago in [MNG-2087|http://jira.codehaus.org/browse/MNG-2087] . It looks as though it may have been fixed and then the problem was reintroduced later. > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garvin LeClaire updated MPLUGIN-114: Attachment: pom.xml Here is a copy of the pom I am using. > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire > Attachments: pom.xml > > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (MENFORCER-39) Allow simplified range checking
[ http://jira.codehaus.org/browse/MENFORCER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135211#action_135211 ] Brian Fox commented on MENFORCER-39: What you're asking for is already done. Just use 1.0.0 and that means 1.0.0 or greater. > Allow simplified range checking > --- > > Key: MENFORCER-39 > URL: http://jira.codehaus.org/browse/MENFORCER-39 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-3, 1.0 >Reporter: Paul Benedict >Assignee: Brian Fox >Priority: Minor > > The rule "[1.0.0,)" means at least 1.0.0 inclusive and anything greater. The > comma should be optional for single-value ranges. It can be inferred simply > from the brackets and braces what the intention is. So "[1.0.0)" should also > be a valid version range. -- 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
