[jira] Issue Comment Edited: (MNG-3546) command line cannot overwrite pom properties
[
http://jira.codehaus.org/browse/MNG-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146949#action_146949
]
tdiesler edited comment on MNG-3546 at 9/4/08 1:29 AM:
-
Also, a property defined in profiles.xml is not seen in module profile
activation
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/profiles-1.0.0.xsd";>
jboss-home-profile
user.name
/home/tdiesler/svn/jbossas/tags/JBoss_4_2_2_GA/build/output/jboss-4.2.2.GA
foo
{code}
{code}
no-jboss-bind-address
!jboss.bind.address
localhost
{code}
The effective pom should show foo for all modules, but does not
{code}
[EMAIL PROTECTED] trunk]$ mvn help:effective-pom | grep jboss.bind.address
foo
foo
foo
foo
foo
foo
foo
foo
foo
foo
no-jboss-bind-address
!jboss.bind.address
localhost
localhost
{code}
was (Author: tdiesler):
Also, a property defined in profiles.xml does not override a property
defined in a module profile
> command line cannot overwrite pom properties
>
>
> Key: MNG-3546
> URL: http://jira.codehaus.org/browse/MNG-3546
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 2.0.9
>Reporter: Thomas Diesler
> Fix For: 2.0.x
>
>
> With a pom like this
>
> localhost
>
> and a command line like this
> mvn -Pjboss422 -Djboss.bind.address=foo clean test-compilecxf.xml
> I get a filtered resource like this
>address='http://localhost:8080/jaxws-cxf-descriptor'
>
> implementor='org.jboss.test.ws.jaxws.cxf.descriptor.DescriptorEndpointImpl'>
>
>
>
>
>
>
> Note, the bind address is localhost
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-3546) command line cannot overwrite pom properties
[ http://jira.codehaus.org/browse/MNG-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146949#action_146949 ] Thomas Diesler commented on MNG-3546: - Also, a property defined in profiles.xml does not override a property defined in a module profile > command line cannot overwrite pom properties > > > Key: MNG-3546 > URL: http://jira.codehaus.org/browse/MNG-3546 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.9 >Reporter: Thomas Diesler > Fix For: 2.0.x > > > With a pom like this > > localhost > > and a command line like this > mvn -Pjboss422 -Djboss.bind.address=foo clean test-compilecxf.xml > I get a filtered resource like this >address='http://localhost:8080/jaxws-cxf-descriptor' > > implementor='org.jboss.test.ws.jaxws.cxf.descriptor.DescriptorEndpointImpl'> > > > > > > > Note, the bind address is localhost -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEJB-32) Add set classifier to client classifier
Add set classifier to client classifier
---
Key: MEJB-32
URL: http://jira.codehaus.org/browse/MEJB-32
Project: Maven 2.x Ejb Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Libor Kramolis
I user classifier to distinguish ejb artefact for IBM WAS
(*was6*) or JBoss (*jboss*)
and also I let ejb plugin to generate client.
But now I can build 2 different ejb file for each deployment environment but it
is not possible to distinguish what was client file generated for. There is no
was6 or jboss in client jar file name.
*I think ejb bodule should concatenate set classifier and "client" suffix to
produce 4 different files for 2 different classifiers*, e.g:
{quote}
my-ejb-1.0.0-was6.jar
my-ejb-1.0.0-was6-client.jar
my-ejb-1.0.0-jboss.jar
my-ejb-1.0.0-jboss-client.jar
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MDEP-180) Copy-dependencies useRepositoryLayout doesn't match with maven layout
Copy-dependencies useRepositoryLayout doesn't match with maven layout - Key: MDEP-180 URL: http://jira.codehaus.org/browse/MDEP-180 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0 Reporter: Marvin Froeder Assignee: Brian Fox When I'm using useRepositoryLayout is a small issue on version folders: Folder should be called 0.3.0-SNAPSHOT Instead of the folder is created as 0.3.0-20080903.153705-125 And on artifacts names: Artifact should be called maven-osgi-compiler-plugin-0.3.0-20080904.004710-136.jar Instead of maven-osgi-compiler-plugin-0.3.0-SNAPSHOT.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146938#action_146938
]
Vincent Siveton commented on SCM-406:
-
I got this issue. Here are some workarounds from dkulp and olamy:
{noformat}
# mvn release:prepare
=> fails
# svn up -r head
# mvn release:prepare -Dresume
{noformat}
using latest svn in your path and call svn cleanup (if you used TortoiseSVN,
kill the TSVNCache too)
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSHADE-41) Allow processing of META-INF/services entries
Allow processing of META-INF/services entries - Key: MSHADE-41 URL: http://jira.codehaus.org/browse/MSHADE-41 Project: Maven 2.x Shade Plugin Issue Type: New Feature Reporter: Jason van Zyl When there are multiple implementations of services spread across several JARs that get shaded we need to append the services entries into one entry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHADE-39) Allow processing of MANIFEST.MF files
[ http://jira.codehaus.org/browse/MSHADE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MSHADE-39. --- Resolution: Fixed Manifest processor added. > Allow processing of MANIFEST.MF files > - > > Key: MSHADE-39 > URL: http://jira.codehaus.org/browse/MSHADE-39 > Project: Maven 2.x Shade Plugin > Issue Type: New Feature >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 1.2 > > > Allow for the arbitrary addition of manifest attributes. Also take care of > the special case where you just want to specify a main-class attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-202) Can't download archetype-catalog.xml via proxy connection
Can't download archetype-catalog.xml via proxy connection - Key: ARCHETYPE-202 URL: http://jira.codehaus.org/browse/ARCHETYPE-202 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-2 Environment: Windows XP 2002 SP3, Maven version 2.0.9, Java 1.6.0_06, internet connection via proxy. Reporter: Leonid E. Egorov Priority: Minor According "Your first Cocoon application using Maven 2" (http://cocoon.apache.org/2.2/1159_1_1.html) after execution: mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org user should enter into dialog about selecting archetype but nothing happen. Error message: D:\MySolutions\java\cocoon\demo>mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:generate] (aggregator-style) [INFO] [INFO] Preparing archetype:generate [INFO] No goals needed for project - skipping [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on => 'false'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] Setting property: resource.manager.logwhenfound => 'false'. [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [WARNING] Error reading archetype catalog http://cocoon.apache.org org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:203) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.getArchetypesByCatalog(DefaultArchetypeSelector.java:249) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.selectArchetype(DefaultArchetypeSelector.java:74) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.net.NoRouteToHostException: No route to host: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net.www.http.Http
[jira] Updated: (SCM-342) scm:tag should support flat project layout
[ http://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated SCM-342: Fix Version/s: (was: 1.1.1) I am not comfortable to remove the @aggregator. > scm:tag should support flat project layout > -- > > Key: SCM-342 > URL: http://jira.codehaus.org/browse/SCM-342 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Affects Versions: 1.0 > Environment: Windows XP, Eclipse 3.3 >Reporter: Duncan Doyle > Attachments: flatProjectTagPatch.txt > > > I have a Maven2 Flat Project Layout as described here: > http://maven.apache.org/guides/mini/guide-ide-eclipse.html > Basically my directory layout is as follows: > /MavenRoot/pom.xml (this is the SuperPom) > /Module1/pom.xml > /Module2/pom.xml > /Module3/pom.xml > Modules 1,2 and 3 are specified in the section of the SuperPom > (e.g() ../Module1). Each POM contains its own CVS connection > URL. > When I execute the scm:tag goal on the SuperPom in the MavenRoot project, > only the MavenRoot project gets tagged. The same behaviour can be seen with > the scm:update goal, which was fixed by providing a scm:update-subprojects > goal. > I would like to see this behaviour fixed in the SCM plugin, while Maven2 > advices a Flat Project Layout when working with Eclipse. At this moment I > can't use the tag goal at all (it should be executed automatically by > CruiseControl on a succesfull build). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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=146932#action_146932 ] Vincent Siveton commented on SCM-376: - I added a test case in [r691838|http://svn.apache.org/viewvc?rev=691838&view=rev] Could you review it? > '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] Commented: (MENFORCER-50) Version rule with dashes are not inspected correctly
[ http://jira.codehaus.org/browse/MENFORCER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146929#action_146929 ] Paul Benedict commented on MENFORCER-50: Why can't this be slated for an enhancement? Eventually, I am sure there will be an opportunity to fix this. > Version rule with dashes are not inspected correctly > > > Key: MENFORCER-50 > URL: http://jira.codehaus.org/browse/MENFORCER-50 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Paul Benedict >Assignee: Brian Fox > > I know it's possible to say [2.0,) for anything within the 2.0 series. > The same was not possible with the latest Maven 2.1 release: > [2.1.0-M1,) does not pass for version 2.1.0-M1-RC12 > I should be accepting anything within the M1 build 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] Closed: (SCM-246) p4 command reports most or all errors on stderr but maven-scm-provider-perforce throws away stderr
[ http://jira.codehaus.org/browse/SCM-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-246. --- Assignee: Vincent Siveton Resolution: Fixed Fixed in [r691823|http://svn.apache.org/viewvc?rev=691823&view=rev] Since I am not a Perforce user, please test it. > p4 command reports most or all errors on stderr but > maven-scm-provider-perforce throws away stderr > -- > > Key: SCM-246 > URL: http://jira.codehaus.org/browse/SCM-246 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce > Environment: I tested this with whatever version came down by default > & then with the lastest svn trunk. The fixes & affects versions available in > this issue form don't seem to match the versions available. > [EMAIL PROTECTED] maven-scm-provider-perforce]$ p4 -V > Perforce - The Fast Software Configuration Management System. > Copyright 1995-2006 Perforce Software. All rights reserved. > Rev. P4/LINUX24X86/2006.1/101890 (2006/06/21). > [EMAIL PROTECTED] maven-scm-provider-perforce]$ p4 info > User name: tparker > Client name: tua > Client host: tua.uiactive.com > Client unknown. > Current directory: > /u01/tomp/maven-scm/maven-scm-providers/maven-scm-provider-perforce > Client address: 172.18.1.29:52715 > Server address: sydb.bullant.local:1666 > Server root: P:\P4ROOT > Server date: 2006/10/31 16:47:50 +1100 AUS Eastern Daylight Time > Server version: P4D/NTX86/2005.2/93627 (2006/02/14) > Server license: Bullant Software (fka Bullant Technology - fna Softblocks > Pty.) 40 users (support expired 2006/10/04) >Reporter: Tom Parker >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: maven-scm-provider-perforce.patch > > > This applies to most or all commands in maven-scm-provider-perforce. I was > unable to fix some basic scm configuration issues until I downloaded the > maven-scm-provider-perforce source and hacked it to consume and report the p4 > command's stderr as well as stdout. > The attached patch fixes the problem for diff, checkin, checkout and tag. My > solution naively consumes stdout until it is finished and then consums > stderr. This isn't ideal if the output order is significant, but for the > errors situations I was dealing with, it worked fine. I had a brief search > for an InputStreamMultiplexer but found nothing. I have included todos to > improve this. > There is much potential for reuse between the classes in > maven-scm-provider-perforce, I have included todo's stating as such. > I have not fixed all the perforce commands. Sorry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SCM-411) Performance: logger calls are not optimal
[
http://jira.codehaus.org/browse/SCM-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-411.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1.1
fixed in [r69181|http://svn.apache.org/viewvc?rev=691810&view=rev]
> Performance: logger calls are not optimal
> -
>
> Key: SCM-411
> URL: http://jira.codehaus.org/browse/SCM-411
> Project: Maven SCM
> Issue Type: Task
> Components: maven-scm-api, maven-scm-provider-accurev,
> maven-scm-provider-bazaar, maven-scm-provider-clearcase,
> maven-scm-provider-cvs, maven-scm-provider-git, maven-scm-provider-local,
> maven-scm-provider-mercurial (hg), maven-scm-provider-monotone,
> maven-scm-provider-perforce, maven-scm-provider-pvcs,
> maven-scm-provider-starteam, maven-scm-provider-svn,
> maven-scm-provider-synergy, maven-scm-provider-vss
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> Several logger calls are getLogger().debug()
> Should be replace by:
> {noformat}
> if ( getLogger().isDebugEnabled() )
> {
> getLogger().debug( ... );
> }
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2198) Please upload simple-4.0.1 to central Maven 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146926#action_146926 ] Niall Gallagher commented on MAVENUPLOAD-2198: -- Hi, Can this be postponed? Version 4.0.1 of the project has a a pretty critical bug, I'd like to begin with a 4.0.2 upload (also I will be using a slightly different bundle name) which I will add in a couple of days. Regards, Niall (Project Owner) > Please upload simple-4.0.1 to central Maven 2 repo > -- > > Key: MAVENUPLOAD-2198 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2198 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: simple-web-4.0.1-bundle.jar, simple-web-4.0.1.jar > > > Simple ( http://www.simpleframework.org/ ) is self described as: "The goal of > Simple is to bring the power of simplicity to the world of server side Java. > The primary focus of the project is to provide a truly embeddable Java based > HTTP engine capable of handling enormous loads. Simple provides a truly > asynchronous service model, request completion is driven using an internal, > transparent, monitoring system. This allows Simple to vastly outperform most > popular Java based servers in a multi-tier environment, as it requires only a > very limited number of threads to handle very high quantities of concurrent > clients. Simple has consistently out performed both commercial and open > source Java Servlet engines and has a fully comprehensive API that is as > usable for experienced Java developers as it is for beginners. Best of all, > Simple is completely free, and is released under the terms of the GNU Lesser > General Public License, LGPL, which ensures its availability for use by open > source and proprietary developers alike." > Simple is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I will attempt to contact the developer to inform him of this. > Bundle attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-459) Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146924#action_146924 ] Dan Fabulich commented on SUREFIRE-459: --- Yes, file a separate issue. But before you do, be sure to read this: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html > Integration test using Jetty and JSP 2.1 fails after update to > maven-surefire-plugin 2.4 > > > Key: SUREFIRE-459 > URL: http://jira.codehaus.org/browse/SUREFIRE-459 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, plugin >Affects Versions: 2.4, 2.4.1 > Environment: Maven 2.0.8, Windows XP >Reporter: Nils-Helge Garli >Assignee: Dan Fabulich > Fix For: 2.4.3 > > > We have an integration test running in a Struts 2 sample application, and > after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is > failing. There's an issue registered in the Struts 2 JIRA explaining the > error: https://issues.apache.org/struts/browse/WW-2494 > I have no idea what's causing the error, but I suspect it has something to do > witn classloader configuration, as aparently no tld files are found inside > the jar files on the classpath. > It should be pretty easy to reproduce. Just checkout the Struts 2 code and > run 'mvn test' on the portlet example application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-411) Performance: logger calls are not optimal
Performance: logger calls are not optimal
-
Key: SCM-411
URL: http://jira.codehaus.org/browse/SCM-411
Project: Maven SCM
Issue Type: Task
Components: maven-scm-api, maven-scm-provider-accurev,
maven-scm-provider-bazaar, maven-scm-provider-clearcase,
maven-scm-provider-cvs, maven-scm-provider-git, maven-scm-provider-local,
maven-scm-provider-mercurial (hg), maven-scm-provider-monotone,
maven-scm-provider-perforce, maven-scm-provider-pvcs,
maven-scm-provider-starteam, maven-scm-provider-svn,
maven-scm-provider-synergy, maven-scm-provider-vss
Affects Versions: 1.1
Reporter: Vincent Siveton
Several logger calls are getLogger().debug()
Should be replace by:
{noformat}
if ( getLogger().isDebugEnabled() )
{
getLogger().debug( ... );
}
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCLEAN-33) Cannot Supress Default clean while still cleaning
[
http://jira.codehaus.org/browse/MCLEAN-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCLEAN-33:
Description:
We would like to configure clean in our parent pom to remove the log files in
logs in all our child modules. We've done that like this:
{code:xml}
maven-clean-plugin
2.1.1
${basedir}/logs
false
**/.svn
{code}
The problem is that when we want to clean an extra directory out of a module,
say for example, generated-sources:
{code:xml}
maven-clean-plugin
2.1.1
gensrc
clean
clean
generated-sources
false
{code}
We then see the following when we run "mvn clean":
{noformat}
[INFO] Building Generated Sources
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set:
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/logs (included: [],
excluded: [**/.svn])
[INFO] [clean:clean {execution: gensrc}]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set: generated-sources (included: [], excluded: [**/.svn])
[INFO]
{noformat}
It would be nice to suppress cleaning target a second time.
was:
We would like to configure clean in our parent pom to remove the log files in
logs in all our child modules. We've done that like this:
maven-clean-plugin
2.1.1
${basedir}/logs
false
**/.svn
The problem is that when we want to clean an extra directory out of a module,
say for example, generated-sources:
maven-clean-plugin
2.1.1
gensrc
clean
clean
generated-sources
false
We then see the following when we run "mvn clean":
FO] Building Generated Sources
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set:
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/logs (included: [],
excluded: [**/.svn])
[INFO] [clean:clean {execution: gensrc}]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set: generated-sources (included: [], excluded: [**/.svn])
[INFO] ---
[jira] Closed: (MCLEAN-30) Using a parent PoM to clean multiple modules, if one has a clean plugin defined for custom directories, custom directory will not be deleted even though it says it is
[ http://jira.codehaus.org/browse/MCLEAN-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCLEAN-30. --- Assignee: Benjamin Bentmann Resolution: Duplicate > Using a parent PoM to clean multiple modules, if one has a clean plugin > defined for custom directories, custom directory will not be deleted even > though it says it is > -- > > Key: MCLEAN-30 > URL: http://jira.codehaus.org/browse/MCLEAN-30 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Reporter: Brian Weiner >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: example.zip > > > In my current situation, I have a parent pom with multiple modules, the final > module creates an exploded war in a directory designed to be used by my web > server. I have defined a clean plugin to clean the directory I create. If I > clean from the child, the directory is deleted. If I call just the clean of > the child from the parent the directory is deleted, but if I call the clean > for all modules, it prints that the directory is deleted but all > files/directories still exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3741) CLONE maven-plugin-tools-api requires relative script root paths
[ http://jira.codehaus.org/browse/MNG-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3741. --- Resolution: Fixed This issue was fixed in RC12 > CLONE maven-plugin-tools-api requires relative script root paths > > > Key: MNG-3741 > URL: http://jira.codehaus.org/browse/MNG-3741 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.0-M1 > > > This affects maven-plugin-tools-* (maven-plugin-tools-api, mainly), at least > as far as 2.4.3+ (up to recent 2.4.4-SNAPSHOTs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCLEAN-36) filesets with an absolute path directory are ignored when !project.isExecutionRoot()
[
http://jira.codehaus.org/browse/MCLEAN-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MCLEAN-36.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.3
Fixed in [r691788|http://svn.apache.org/viewvc?view=rev&revision=691788], added
corresponding test in
[r691803|http://svn.apache.org/viewvc?view=rev&revision=691803].
> filesets with an absolute path directory are ignored when
> !project.isExecutionRoot()
>
>
> Key: MCLEAN-36
> URL: http://jira.codehaus.org/browse/MCLEAN-36
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Will Horn
>Assignee: Benjamin Bentmann
> Fix For: 2.3
>
> Attachments: mvn-test.zip
>
>
> Due to the fix for http://jira.codehaus.org/browse/MCLEAN-27, mvn clean will
> not delete a fileset with a directory represented by an absolute path when
> run from a parent directory. Instead it will automatically prepend the
> project directory path to the absolute path and silently do nothing after not
> find the directory. The logic responsible is in
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-clean-plugin-2.2/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java?revision=594869&view=markup
> getLog().info( "Deleting " + fileset );
> if ( !project.isExecutionRoot() )
> {
> String projectBasedir = StringUtils.replace(
> project.getBasedir().getAbsolutePath(), "\\", "/" );
> String filesetDir = StringUtils.replace(
> fileset.getDirectory(), "\\", "/" );
> if ( filesetDir.indexOf( projectBasedir ) == -1 )
> {
> fileset.setDirectory( projectBasedir + "/" +
> filesetDir );
> }
> }
> fileSetManager.delete( fileset );
> The issue can be seen in the attached test project. If a directory
> c:\mvntemp exists, then "mvn clean" from the base directory will not delete
> it. "mvn clean" from inside subproject will work since
> project.isExecutionRoot() is true and the above logic is not executed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3741) CLONE maven-plugin-tools-api requires relative script root paths
[ http://jira.codehaus.org/browse/MNG-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3741: Summary: CLONE maven-plugin-tools-api requires relative script root paths (was: CLONE -maven-project-api requires relative script root paths) > CLONE maven-plugin-tools-api requires relative script root paths > > > Key: MNG-3741 > URL: http://jira.codehaus.org/browse/MNG-3741 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.0-M1 > > > This affects maven-plugin-tools-* (maven-plugin-tools-api, mainly), at least > as far as 2.4.3+ (up to recent 2.4.4-SNAPSHOTs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-136) maven-plugin-tools-api requires relative script root paths
[ http://jira.codehaus.org/browse/MPLUGIN-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MPLUGIN-136: --- Summary: maven-plugin-tools-api requires relative script root paths (was: maven-project-api requires relative script root paths) > maven-plugin-tools-api requires relative script root paths > -- > > Key: MPLUGIN-136 > URL: http://jira.codehaus.org/browse/MPLUGIN-136 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Reporter: John Casey >Assignee: John Casey > Fix For: 2.4.4 > > > This affects maven-plugin-tools-* (maven-plugin-tools-api, mainly), at least > as far as 2.4.3+ (up to recent 2.4.4-SNAPSHOTs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MNG-3741) CLONE -maven-project-api requires relative script root paths
[ http://jira.codehaus.org/browse/MNG-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey moved MPLUGIN-139 to MNG-3741: - Fix Version/s: (was: 2.4.4) 2.1.0-M1 Component/s: (was: API) Plugins and Lifecycle Plugin API Complexity: Intermediate Key: MNG-3741 (was: MPLUGIN-139) Project: Maven 2 (was: Maven 2.x Plugin Tools) > CLONE -maven-project-api requires relative script root paths > > > Key: MNG-3741 > URL: http://jira.codehaus.org/browse/MNG-3741 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.0-M1 > > > This affects maven-plugin-tools-* (maven-plugin-tools-api, mainly), at least > as far as 2.4.3+ (up to recent 2.4.4-SNAPSHOTs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPLUGIN-139) CLONE -maven-project-api requires relative script root paths
CLONE -maven-project-api requires relative script root paths Key: MPLUGIN-139 URL: http://jira.codehaus.org/browse/MPLUGIN-139 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: API Reporter: John Casey Assignee: John Casey Fix For: 2.4.4 This affects maven-plugin-tools-* (maven-plugin-tools-api, mainly), at least as far as 2.4.3+ (up to recent 2.4.4-SNAPSHOTs). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3740) Plugin builds that reference earlier versions of themselves in the section of the POM result in StackOverflowError in 2.1.0-M1-RC12
[
http://jira.codehaus.org/browse/MNG-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3740.
---
Resolution: Fixed
> Plugin builds that reference earlier versions of themselves in the
> section of the POM result in StackOverflowError in 2.1.0-M1-RC12
> -
>
> Key: MNG-3740
> URL: http://jira.codehaus.org/browse/MNG-3740
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> The following seems to result from a project-reference cycle between a plugin
> project and itself. For instance, when the compiler plugin build configures
> an earlier version of the compiler plugin, a project reference is established
> between the compiler plugin and itself in the reactor. This results in a
> StackOverflowError when trying to calculate the concrete state for the
> compiler plugin project, since it's trying to traverse project references (to
> itself).
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Maven Plugins
> [INFO] Maven Remote Resources Plugin
> [INFO] Maven Ant Plugin
> [INFO] Maven AntRun Plugin
> [INFO] Maven Assembly Plugin
> [INFO] Maven Changelog Plugin
> [INFO] Maven Changes Report Plugin
> [INFO] Maven Checkstyle Plugin
> [INFO] Maven Clean Plugin
> [INFO] Maven Compiler Plugin
> [INFO] Maven Dependency Plugin
> [INFO] Maven Deploy Plugin
> [INFO] Maven DOAP Plugin
> [INFO] Maven Documentation Checker Plugin
> [INFO] Maven EAR Plugin
> [INFO] Maven Eclipse Plugin
> [INFO] Maven EJB Plugin
> [INFO] Maven GPG Plugin
> [INFO] Maven Help Plugin
> [INFO] Maven IDEA Plugin
> [INFO] Maven Install Plugin
> [INFO] Maven Invoker Plugin
> [INFO] Maven Javadoc Plugin
> [INFO] Maven JAR Plugin
> [INFO] Maven Linkcheck Plugin
> [INFO] Maven One Plugin
> [INFO] Maven Patch Plugin
> [INFO] Maven PMD Plugin
> [INFO] Maven RAR Plugin
> [INFO] Maven Repository Plugin
> [INFO] Maven Resources Plugin
> [INFO] Maven Shade Plugin
> [INFO] Maven Site Plugin
> [INFO] Maven Source Plugin
> [INFO] Maven Stage Plugin
> [INFO] Maven Toolchains Plugin
> [INFO] Maven Verifier Plugin
> [INFO] Maven WAR Plugin
> [INFO]
>
> [INFO] Building Maven Plugins
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from snapshots
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from snapshots
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from apache.snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from apache.snapshots
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.StackOverflowError
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918)
> ...
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder
[jira] Closed: (MCLEAN-31) Always resolve relative path against the project's base directory
[ http://jira.codehaus.org/browse/MCLEAN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCLEAN-31. --- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.3 Fixed in [r691788|http://svn.apache.org/viewvc?view=rev&revision=691788]. > Always resolve relative path against the project's base directory > - > > Key: MCLEAN-31 > URL: http://jira.codehaus.org/browse/MCLEAN-31 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 2.3 > > Attachments: clean.zip, relative-paths.patch, relative-paths.patch > > > Relative paths - which are often used by users for plugin configuration in > the POM - must always be resolved against the base directory of the current > project. By always I mean not just when run in a reactor build. > Attached is a patch to fix the mojo as well as a mini project to reveal the > bug. Just unpack the project, change your working directory to the parent > folder of its base directory or any other directory that does not contain the > POM and run Maven on the test POM from this working directory using its -f > switch. The plugin will not delete the "test-target" directory in the project > base directory but instead delete an equally named directory in the current > working directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-337) dependencySet with unpack=true cannot be used to make file permissions executable
[
http://jira.codehaus.org/browse/MASSEMBLY-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146881#action_146881
]
Kallin Nagelberg commented on MASSEMBLY-337:
I've encountered the same problem when trying to use 0700
. It appears to disregard that tag entirely when used within a dependencyset.
> dependencySet with unpack=true cannot be used to make file permissions
> executable
> -
>
> Key: MASSEMBLY-337
> URL: http://jira.codehaus.org/browse/MASSEMBLY-337
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9, Java 1.6_04, tested on both Windows XP and
> CentOS 4.1
>Reporter: John Crim
>Priority: Blocker
> Attachments: massembly-bug.tar.gz
>
>
> The attached tar.gz contains 2 simple test projects which exhibit this bug:
> # Project scripts-assembly generates
> {{scripts-assembly-1.0-SNAPSHOT-scripts.zip}}, which contains a single file,
> {{script.sh}}, with permissions {{-rwxr-xr-x}}
> # Project assembly-filemode-bug depends on project scripts-assembly. It
> extracts the scripts.zip file into its {{/bin}} directory when creating its
> assembly.
> {code:xml}
>
>
>
>
> bin
> true
>
> maven-bugs:scripts-assembly:zip:scripts
>
> 0755
>
>
> {code}
> The {{fileMode}} element does not have the desired effect. I'm not able to
> find a workaround with 2.2-beta-2 that enables me to set the executable bit
> on the scripts. From looking at other bugs in MASSEMBLY, I did try
> configuring the scripts-assembly project to output a zip (also tried tar.gz)
> containing the files with the executable bit set. This didn't change the
> outcome - the files in package #2 are still not executable.
> I consider this a highest priority bug, b/c I can find no way to get around
> this limitation and make script files from a dependency executable within an
> installable package. If I change to assembly plugin version 2.2-beta-1
> (which admittedly has a significant list of bugs I'd like to avoid), this
> works. I've also tried using other tar.gz for the assembly output of both
> projects, but it didn't affect the outcome.
> At this point I think my best path forward is to use assembly plugin version
> 2.2-beta-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MREPOSITORY-11) Javadoc not included in the bundle
[ http://jira.codehaus.org/browse/MREPOSITORY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146879#action_146879 ] Dennis Lundberg commented on MREPOSITORY-11: The "Fix Version" is for this plugin - not Maven itself. > Javadoc not included in the bundle > -- > > Key: MREPOSITORY-11 > URL: http://jira.codehaus.org/browse/MREPOSITORY-11 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven version: 2.0.7 > Java version: 1.4.2_13 > OS name: "windows xp" version: "5.1" arch: "x86" >Reporter: Julien HENRY >Assignee: Carlos Sanchez > Fix For: 2.1 > > > On a simple project, I run: > mvn clean source:jar javadoc:jar repository:bundle-create > As a result in target I get: > artifact-version.jar > artifact-version-bundle.jar > artifact-version-javadoc.jar > artifact-version-sources.jar > But in artifact-version-bundle.jar there are only: > META-INF > pom.xml > LICENSE.txt > artifact-version.jar > artifact-version-sources.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHARED-58) FileSetManager.delete() fails to delete dangling symlinks
[ http://jira.codehaus.org/browse/MSHARED-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MSHARED-58. Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: file-management 1.2.1 Fixed in [r691724|http://svn.apache.org/viewvc?view=rev&revision=691724] by updating to plexus-utils:1.5.6, added corresponding unit test in [r691750|http://svn.apache.org/viewvc?view=rev&revision=691750]. > FileSetManager.delete() fails to delete dangling symlinks > - > > Key: MSHARED-58 > URL: http://jira.codehaus.org/browse/MSHARED-58 > Project: Maven Shared Components > Issue Type: Bug > Components: file-management >Affects Versions: file-management 1.2 > Environment: Unix >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: file-management 1.2.1 > > > See PLXUTILS-28. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MENFORCER-50) Version rule with dashes are not inspected correctly
[
http://jira.codehaus.org/browse/MENFORCER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146876#action_146876
]
brianfox edited comment on MENFORCER-50 at 9/3/08 2:53 PM:
There are a few problems with this. First is i'm using the core maven code to
do this, and:
{noformat}
else if ( qualifier.length() <
otherVersion.qualifier.length() &&
otherVersion.qualifier.startsWith( qualifier ) )
{
// here, the longer one that otherwise match is
considered older
result = 1;
}
{noformat}
The code is explicitly saying that M1-RC12 is older than M1. I'm not about to
start monkeying with this code as it will blow up everyone.
If we continue with the RCs, we will eventually have an official M1, which will
be newer than the RCs, surely you wouldn't then want the range to include the
RCs.
Since if the length is the same, it comes down to natural string ordering of
the qualifier, you should use [2.1.0-M1-RC00,) to get your desired results
was (Author: brianfox):
There are a few problems with this. First is i'm using the core maven code
to do this, and:
else if ( qualifier.length() <
otherVersion.qualifier.length() &&
otherVersion.qualifier.startsWith( qualifier ) )
{
// here, the longer one that otherwise match is
considered older
result = 1;
}
The code is explicitly saying that M1-RC12 is older than M1. I'm not about to
start monkeying with this code as it will blow up everyone.
If we continue with the RCs, we will eventually have an official M1, which will
be newer than the RCs, surely you wouldn't then want the range to include the
RCs.
Since if the length is the same, it comes down to natural string ordering of
the qualifier, you should use [2.1.0-M1-RC00,) to get your desired results
> Version rule with dashes are not inspected correctly
>
>
> Key: MENFORCER-50
> URL: http://jira.codehaus.org/browse/MENFORCER-50
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0-alpha-3
>Reporter: Paul Benedict
>Assignee: Brian Fox
>
> I know it's possible to say [2.0,) for anything within the 2.0 series.
> The same was not possible with the latest Maven 2.1 release:
> [2.1.0-M1,) does not pass for version 2.1.0-M1-RC12
> I should be accepting anything within the M1 build 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] Closed: (MENFORCER-50) Version rule with dashes are not inspected correctly
[
http://jira.codehaus.org/browse/MENFORCER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-50.
--
Resolution: Won't Fix
There are a few problems with this. First is i'm using the core maven code to
do this, and:
else if ( qualifier.length() <
otherVersion.qualifier.length() &&
otherVersion.qualifier.startsWith( qualifier ) )
{
// here, the longer one that otherwise match is
considered older
result = 1;
}
The code is explicitly saying that M1-RC12 is older than M1. I'm not about to
start monkeying with this code as it will blow up everyone.
If we continue with the RCs, we will eventually have an official M1, which will
be newer than the RCs, surely you wouldn't then want the range to include the
RCs.
Since if the length is the same, it comes down to natural string ordering of
the qualifier, you should use [2.1.0-M1-RC00,) to get your desired results
> Version rule with dashes are not inspected correctly
>
>
> Key: MENFORCER-50
> URL: http://jira.codehaus.org/browse/MENFORCER-50
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0-alpha-3
>Reporter: Paul Benedict
>Assignee: Brian Fox
>
> I know it's possible to say [2.0,) for anything within the 2.0 series.
> The same was not possible with the latest Maven 2.1 release:
> [2.1.0-M1,) does not pass for version 2.1.0-M1-RC12
> I should be accepting anything within the M1 build 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: (MSHARED-58) FileSetManager.delete() fails to delete dangling symlinks
FileSetManager.delete() fails to delete dangling symlinks - Key: MSHARED-58 URL: http://jira.codehaus.org/browse/MSHARED-58 Project: Maven Shared Components Issue Type: Bug Components: file-management Affects Versions: file-management 1.2 Environment: Unix Reporter: Benjamin Bentmann See PLXUTILS-28. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-316) useProjectArtifact is documented but not in schema
[ http://jira.codehaus.org/browse/MASSEMBLY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146874#action_146874 ] John Casey commented on MASSEMBLY-316: -- I'm confused; you seem to be expecting useProjectArtifact to be configurable from within the POM, when it's an option on a dependencySet within the assembly descriptor and/or component descriptor file. Can you providing a test project that displays the problem you're having, so we can reproduce it? > useProjectArtifact is documented but not in schema > -- > > Key: MASSEMBLY-316 > URL: http://jira.codehaus.org/browse/MASSEMBLY-316 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Thomas Diesler > > I like to include a module's dependencies, but not the projectArtifact > itself. This functionality seem to be provided by 'useProjectArtifact' > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html > which is not defined in > http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd > and does not seem to work anymore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3740) Plugin builds that reference earlier versions of themselves in the section of the POM result in StackOverflowError in 2.1.0-M1-RC12
[
http://jira.codehaus.org/browse/MNG-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3740:
Assignee: John Casey
Fix Version/s: 2.1.0-M1
> Plugin builds that reference earlier versions of themselves in the
> section of the POM result in StackOverflowError in 2.1.0-M1-RC12
> -
>
> Key: MNG-3740
> URL: http://jira.codehaus.org/browse/MNG-3740
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> The following seems to result from a project-reference cycle between a plugin
> project and itself. For instance, when the compiler plugin build configures
> an earlier version of the compiler plugin, a project reference is established
> between the compiler plugin and itself in the reactor. This results in a
> StackOverflowError when trying to calculate the concrete state for the
> compiler plugin project, since it's trying to traverse project references (to
> itself).
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Maven Plugins
> [INFO] Maven Remote Resources Plugin
> [INFO] Maven Ant Plugin
> [INFO] Maven AntRun Plugin
> [INFO] Maven Assembly Plugin
> [INFO] Maven Changelog Plugin
> [INFO] Maven Changes Report Plugin
> [INFO] Maven Checkstyle Plugin
> [INFO] Maven Clean Plugin
> [INFO] Maven Compiler Plugin
> [INFO] Maven Dependency Plugin
> [INFO] Maven Deploy Plugin
> [INFO] Maven DOAP Plugin
> [INFO] Maven Documentation Checker Plugin
> [INFO] Maven EAR Plugin
> [INFO] Maven Eclipse Plugin
> [INFO] Maven EJB Plugin
> [INFO] Maven GPG Plugin
> [INFO] Maven Help Plugin
> [INFO] Maven IDEA Plugin
> [INFO] Maven Install Plugin
> [INFO] Maven Invoker Plugin
> [INFO] Maven Javadoc Plugin
> [INFO] Maven JAR Plugin
> [INFO] Maven Linkcheck Plugin
> [INFO] Maven One Plugin
> [INFO] Maven Patch Plugin
> [INFO] Maven PMD Plugin
> [INFO] Maven RAR Plugin
> [INFO] Maven Repository Plugin
> [INFO] Maven Resources Plugin
> [INFO] Maven Shade Plugin
> [INFO] Maven Site Plugin
> [INFO] Maven Source Plugin
> [INFO] Maven Stage Plugin
> [INFO] Maven Toolchains Plugin
> [INFO] Maven Verifier Plugin
> [INFO] Maven WAR Plugin
> [INFO]
>
> [INFO] Building Maven Plugins
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from snapshots
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from snapshots
> [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
> checking for updates from apache.snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from snapshots
> [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
> updates from apache.snapshots
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.StackOverflowError
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918)
> ...
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
> at
> org.apache.ma
[jira] Created: (MNG-3740) Plugin builds that reference earlier versions of themselves in the section of the POM result in StackOverflowError in 2.1.0-M1-RC12
Plugin builds that reference earlier versions of themselves in the
section of the POM result in StackOverflowError in 2.1.0-M1-RC12
-
Key: MNG-3740
URL: http://jira.codehaus.org/browse/MNG-3740
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.1.0-M1
Reporter: John Casey
Priority: Blocker
Fix For: 2.1.0-M1
The following seems to result from a project-reference cycle between a plugin
project and itself. For instance, when the compiler plugin build configures an
earlier version of the compiler plugin, a project reference is established
between the compiler plugin and itself in the reactor. This results in a
StackOverflowError when trying to calculate the concrete state for the compiler
plugin project, since it's trying to traverse project references (to itself).
{noformat}
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Plugins
[INFO] Maven Remote Resources Plugin
[INFO] Maven Ant Plugin
[INFO] Maven AntRun Plugin
[INFO] Maven Assembly Plugin
[INFO] Maven Changelog Plugin
[INFO] Maven Changes Report Plugin
[INFO] Maven Checkstyle Plugin
[INFO] Maven Clean Plugin
[INFO] Maven Compiler Plugin
[INFO] Maven Dependency Plugin
[INFO] Maven Deploy Plugin
[INFO] Maven DOAP Plugin
[INFO] Maven Documentation Checker Plugin
[INFO] Maven EAR Plugin
[INFO] Maven Eclipse Plugin
[INFO] Maven EJB Plugin
[INFO] Maven GPG Plugin
[INFO] Maven Help Plugin
[INFO] Maven IDEA Plugin
[INFO] Maven Install Plugin
[INFO] Maven Invoker Plugin
[INFO] Maven Javadoc Plugin
[INFO] Maven JAR Plugin
[INFO] Maven Linkcheck Plugin
[INFO] Maven One Plugin
[INFO] Maven Patch Plugin
[INFO] Maven PMD Plugin
[INFO] Maven RAR Plugin
[INFO] Maven Repository Plugin
[INFO] Maven Resources Plugin
[INFO] Maven Shade Plugin
[INFO] Maven Site Plugin
[INFO] Maven Source Plugin
[INFO] Maven Stage Plugin
[INFO] Maven Toolchains Plugin
[INFO] Maven Verifier Plugin
[INFO] Maven WAR Plugin
[INFO]
[INFO] Building Maven Plugins
[INFO]task-segment: [clean, install]
[INFO]
[INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
checking for updates from snapshots
[INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
checking for updates from snapshots
[INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
updates from snapshots
[INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
updates from snapshots
[INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for
updates from apache.snapshots
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.StackOverflowError
at
org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033)
at
org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006)
at
org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918)
...
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949)
at
org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918)
[INFO]
[INFO] Total time: 22 seconds
[INFO] Finished at: Tue Sep 02 13:53:56 CEST 2008
[INFO] Final Memory: 6M/254M
[INFO]
[jira] Created: (MWAR-168) "Dependency Has Changed" Incorrectly Reported
"Dependency Has Changed" Incorrectly Reported
-
Key: MWAR-168
URL: http://jira.codehaus.org/browse/MWAR-168
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: gotama
In maven-war-plugin 2.1-alpha-2, execute the following on a war project:
mvn clean;
mvn install;
mvn install;
The 3rd command incorrectly lists messages for each dependency as follows:
[INFO] Dependency[Dependency {groupId=com.mycompany, artifactId=myartifact,
version=8.6.1, type=jar}]
has changed (was Dependency {groupId=com.mycompany, artifactId=myartifact,
version=8.6.1, type=jar}).
The first time that mvn install is run, dependencies are added to:
target\myapp-war-1.1-SNAPSHOT\WEB-INF\lib
The second invocation of mvn install appears to fail in comparing the existing
jars in the above path with what is in the repository. The message states the
dependencies have changed when in fact they have not.
This problem does not exist in maven-war-plugin 2.0.2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSHARED-55) NLP IF no fileset directory specified.
[
http://jira.codehaus.org/browse/MSHARED-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146872#action_146872
]
Benjamin Bentmann commented on MSHARED-55:
--
Petar, I am not sure whether your patch really solves MASSEMBLY-342. You are
simply avoiding the NPE in the FileSetManager but as far as I understand, the
NPE is adequate: A required parameter is missing and I wouldn't consider a
FileSet without base directory a valid object. The Assembly Plugin is
responsible to properly configure the FileSet before passing it down to the
FileSetManager, so that needs fixing. In particular, consider the POM snippet
given over at the MASSEMBLY-342
{code:xml}
true
INSTALL*
README*
LICENSE*
NOTICE*
{code}
which suggests that the user wants the FileSet to use the project's base
directory. This is a completely different semantics than just returning an
empty result list.
To summarize: I think this issue itself should be closed as "Won't fix". To
real work is over in the Assembly Plugin.
> NLP IF no fileset directory specified.
> --
>
> Key: MSHARED-55
> URL: http://jira.codehaus.org/browse/MSHARED-55
> Project: Maven Shared Components
> Issue Type: Bug
> Components: file-management
>Affects Versions: file-management 1.2
> Environment: all
>Reporter: Petar Tahchiev
> Attachments: massembly-342.txt, mshared55-ver.1.txt,
> mshared55-ver1-testcase.txt
>
>
> Hi guys I have created a patch for the MASSEMBLY-342 that should be applied
> to FileSetManager. This patch fixes a but that can arise if you make
> assemblies and in your assembly-descriptor you have filesets that don't
> specify directory.
> For further info please look here:
> http://jira.codehaus.org/browse/MASSEMBLY-342
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSHARED-55) NLP IF no fileset directory specified.
[ http://jira.codehaus.org/browse/MSHARED-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MSHARED-55: - Affects Version/s: file-management 1.2 > NLP IF no fileset directory specified. > -- > > Key: MSHARED-55 > URL: http://jira.codehaus.org/browse/MSHARED-55 > Project: Maven Shared Components > Issue Type: Bug > Components: file-management >Affects Versions: file-management 1.2 > Environment: all >Reporter: Petar Tahchiev > Attachments: massembly-342.txt, mshared55-ver.1.txt, > mshared55-ver1-testcase.txt > > > Hi guys I have created a patch for the MASSEMBLY-342 that should be applied > to FileSetManager. This patch fixes a but that can arise if you make > assemblies and in your assembly-descriptor you have filesets that don't > specify directory. > For further info please look here: > http://jira.codehaus.org/browse/MASSEMBLY-342 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSOURCES-39) Add a includePom option to the sources:jar goal
Add a includePom option to the sources:jar goal
---
Key: MSOURCES-39
URL: http://jira.codehaus.org/browse/MSOURCES-39
Project: Maven 2.x Source Plugin
Issue Type: Improvement
Reporter: Moritz Havelock
Priority: Minor
Adds an includePom option that will result in inclusion of the project's pom
file into the generates sources jar file.
Index:
src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
===
--- src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
(revision 691652)
+++ src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.j
+++ ava
(working copy)
@@ -69,6 +69,14 @@
* @since 2.0.4
*/
protected boolean excludeResources;
+
+/**
+ * Specifies whether or not to include the pom file in the sources-jar.
+ *
+ * @parameter expression="${includePom}" default-value="false"
+ * @since 2.0.5
+ */
+protected boolean includePom;
/**
* Used for attaching the source jar to the project.
@@ -186,6 +194,15 @@
protected void archiveProjectContent( MavenProject project, Archiver
archiver )
throws MojoExecutionException
{
+
+ if (includePom) {
+ try {
+ archiver.addFile(project.getFile(),
project.getFile().getName());
+ } catch (ArchiverException e) {
+ throw new MojoExecutionException("Error
adding pom file to target jar file.", e);
+ }
+ }
+
for ( Iterator i = getSources( project ).iterator(); i.hasNext(); )
{
String s = (String) i.next();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2198) Please upload simple-4.0.1 to central Maven 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146870#action_146870 ] Niall Gallagher commented on MAVENUPLOAD-2198: -- Hi, This project is associated with the existing maven/org.simpleframework project. So it would be good if it was filed with the existing simple-xml.* archives. Thanks, Niall > Please upload simple-4.0.1 to central Maven 2 repo > -- > > Key: MAVENUPLOAD-2198 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2198 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: simple-web-4.0.1-bundle.jar, simple-web-4.0.1.jar > > > Simple ( http://www.simpleframework.org/ ) is self described as: "The goal of > Simple is to bring the power of simplicity to the world of server side Java. > The primary focus of the project is to provide a truly embeddable Java based > HTTP engine capable of handling enormous loads. Simple provides a truly > asynchronous service model, request completion is driven using an internal, > transparent, monitoring system. This allows Simple to vastly outperform most > popular Java based servers in a multi-tier environment, as it requires only a > very limited number of threads to handle very high quantities of concurrent > clients. Simple has consistently out performed both commercial and open > source Java Servlet engines and has a fully comprehensive API that is as > usable for experienced Java developers as it is for beginners. Best of all, > Simple is completely free, and is released under the terms of the GNU Lesser > General Public License, LGPL, which ensures its availability for use by open > source and proprietary developers alike." > Simple is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I will attempt to contact the developer to inform him of this. > Bundle attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHARED-57) FileSetManager.isSymlink() produces false negatives
[
http://jira.codehaus.org/browse/MSHARED-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHARED-57.
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: file-management 1.2.1
Fixed in [r691718|http://svn.apache.org/viewvc?view=rev&revision=691718].
> FileSetManager.isSymlink() produces false negatives
> ---
>
> Key: MSHARED-57
> URL: http://jira.codehaus.org/browse/MSHARED-57
> Project: Maven Shared Components
> Issue Type: Bug
> Components: file-management
>Affects Versions: file-management 1.2
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: file-management 1.2.1
>
>
> Given this directory structure:
> {noformat}
> ./
> dir/
> subdir/
> subdir/ -> dir/subdir/
> {noformat}
> {{isSymlink("./subdir")}} erroneously returns false because its logic does
> not properly handle links to sub directories of the link's parent directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-459) Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146867#action_146867 ] cbeams edited comment on SUREFIRE-459 at 9/3/08 1:27 PM: -- It appears that I've just reproduced this bug against 2.4.3. I've tried the 'useSystemClassLoader=false' workaround, and it exposes a different problem. Unfortunately this issue is 'closed' and so cannot be re-opened. Shall I create a new issue? At any rate, here are the repro steps: 1) Check out, build and test Spring JavaConfig's petclinic sample: svn co -r 789 https://src.springframework.org/svn/spring-javaconfig/trunk/samples/org.springframework.config.java.samples.petclinic petclinic cd petclinic mvn clean test 2) Notice that there are two test failures: Tests in error: testIndex(test.web.InContainerTests) testFindOwners(test.web.InContainerTests) The cause of both these issues is the following: Error 500 /WEB-INF/jsp/includes.jsp(1,70) PWC6188: The absolute uri: http://www.springframework.org/tags cannot be resolved in either web.xml or the jar files deployed with this application As mentioned above, downgrading to 2.3 does work - the tests pass once I do this. (See revision 790 of the above to confirm). was (Author: cbeams): It appears that I've just reproduced this bug against 2.4.3. I've tried the 'useSystemClassLoader=false' workaround, and it exposes a different problem. Unfortunately this issue is 'closed' and so cannot be re-opened. Shall I create a new issue? At any rate, here are the repro steps: 1) Check out, build and test Spring JavaConfig's petclinic sample: svn co -r 789 https://src.springframework.org/svn/spring-javaconfig/trunk/samples/org.springframework.config.java.samples.petclinic petclinic cd petclinic mvn clean test 2) Notice that there are two test failures: Tests in error: testIndex(test.web.InContainerTests) testFindOwners(test.web.InContainerTests) The cause of both these issues is the following: Error 500 /WEB-INF/jsp/includes.jsp(1,70) PWC6188: The absolute uri: http://www.springframework.org/tags cannot be resolved in either web.xml or the jar files deployed with this application As mentioned above, downgrading to 2.3 does work - the tests pass once I do this. (See revision 780 of the above to confirm). > Integration test using Jetty and JSP 2.1 fails after update to > maven-surefire-plugin 2.4 > > > Key: SUREFIRE-459 > URL: http://jira.codehaus.org/browse/SUREFIRE-459 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, plugin >Affects Versions: 2.4, 2.4.1 > Environment: Maven 2.0.8, Windows XP >Reporter: Nils-Helge Garli >Assignee: Dan Fabulich > Fix For: 2.4.3 > > > We have an integration test running in a Struts 2 sample application, and > after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is > failing. There's an issue registered in the Struts 2 JIRA explaining the > error: https://issues.apache.org/struts/browse/WW-2494 > I have no idea what's causing the error, but I suspect it has something to do > witn classloader configuration, as aparently no tld files are found inside > the jar files on the classpath. > It should be pretty easy to reproduce. Just checkout the Struts 2 code and > run 'mvn test' on the portlet example application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHARED-57) FileSetManager.isSymlink() produces false negatives
FileSetManager.isSymlink() produces false negatives
---
Key: MSHARED-57
URL: http://jira.codehaus.org/browse/MSHARED-57
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2
Reporter: Benjamin Bentmann
Given this directory structure:
{noformat}
./
dir/
subdir/
subdir/ -> dir/subdir/
{noformat}
{{isSymlink("./subdir")}} erroneously returns false because its logic does not
properly handle links to sub directories of the link's parent directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2198) Please upload simple-4.0.1 to central Maven 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146868#action_146868 ] Gary S. Weaver commented on MAVENUPLOAD-2198: - Note: response from developer: "Hi, Thanks fine, however there is a slight bug in 4.0.1 which I have just resolved. Should be released by the end of the week. I will ensure to upload this version also. Thanks, Niall" So once he updates it at end of week (or so) I'll rebundle and attach new version to this ticket. > Please upload simple-4.0.1 to central Maven 2 repo > -- > > Key: MAVENUPLOAD-2198 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2198 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: simple-web-4.0.1-bundle.jar, simple-web-4.0.1.jar > > > Simple ( http://www.simpleframework.org/ ) is self described as: "The goal of > Simple is to bring the power of simplicity to the world of server side Java. > The primary focus of the project is to provide a truly embeddable Java based > HTTP engine capable of handling enormous loads. Simple provides a truly > asynchronous service model, request completion is driven using an internal, > transparent, monitoring system. This allows Simple to vastly outperform most > popular Java based servers in a multi-tier environment, as it requires only a > very limited number of threads to handle very high quantities of concurrent > clients. Simple has consistently out performed both commercial and open > source Java Servlet engines and has a fully comprehensive API that is as > usable for experienced Java developers as it is for beginners. Best of all, > Simple is completely free, and is released under the terms of the GNU Lesser > General Public License, LGPL, which ensures its availability for use by open > source and proprietary developers alike." > Simple is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I will attempt to contact the developer to inform him of this. > Bundle attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-459) Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146867#action_146867 ] Chris Beams commented on SUREFIRE-459: -- It appears that I've just reproduced this bug against 2.4.3. I've tried the 'useSystemClassLoader=false' workaround, and it exposes a different problem. Unfortunately this issue is 'closed' and so cannot be re-opened. Shall I create a new issue? At any rate, here are the repro steps: 1) Check out, build and test Spring JavaConfig's petclinic sample: svn co -r 789 https://src.springframework.org/svn/spring-javaconfig/trunk/samples/org.springframework.config.java.samples.petclinic petclinic cd petclinic mvn clean test 2) Notice that there are two test failures: Tests in error: testIndex(test.web.InContainerTests) testFindOwners(test.web.InContainerTests) The cause of both these issues is the following: Error 500 /WEB-INF/jsp/includes.jsp(1,70) PWC6188: The absolute uri: http://www.springframework.org/tags cannot be resolved in either web.xml or the jar files deployed with this application As mentioned above, downgrading to 2.3 does work - the tests pass once I do this. (See revision 780 of the above to confirm). > Integration test using Jetty and JSP 2.1 fails after update to > maven-surefire-plugin 2.4 > > > Key: SUREFIRE-459 > URL: http://jira.codehaus.org/browse/SUREFIRE-459 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, plugin >Affects Versions: 2.4, 2.4.1 > Environment: Maven 2.0.8, Windows XP >Reporter: Nils-Helge Garli >Assignee: Dan Fabulich > Fix For: 2.4.3 > > > We have an integration test running in a Struts 2 sample application, and > after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is > failing. There's an issue registered in the Struts 2 JIRA explaining the > error: https://issues.apache.org/struts/browse/WW-2494 > I have no idea what's causing the error, but I suspect it has something to do > witn classloader configuration, as aparently no tld files are found inside > the jar files on the classpath. > It should be pretty easy to reproduce. Just checkout the Struts 2 code and > run 'mvn test' on the portlet example application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVENUPLOAD-2197) Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite version number)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary S. Weaver updated MAVENUPLOAD-2197: Attachment: rupy-0.2.4-bundle-2.jar Oops. The groupId in the first attached bundle included the artifact name, which it shouldn't have to be clean. Fixed, re-bundled, and attached as rupy-0.2.4-bundle-2.jar > Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite > version number) > -- > > Key: MAVENUPLOAD-2197 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2197 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: rupy-0.2.4-bundle-2.jar, rupy-0.2.4-bundle.jar, > rupy-0.2.4.jar > > > Rupy ( http://code.google.com/p/rupy/ ) is self described as: "Weighing less > than 50KB, rupy is probably the smallest Java NIO application server in the > world. Rupy is inherently non-blocking asynchronous, which makes it the ideal > candidate for high concurrency real-time applications pushing dynamic data. > Tested with acme, rupy performs on average ~1500 requests per second. To put > that figure in perspective; acme doesn't use keep-alive, so that means 1500 > unique TCP connections serving dynamic content per second! Thanks to NIO and > an event queue to avoid selector trashing, this figure degrades gracefully > under high concurrency. " > Rupy is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I renamed http.jar in the bundle to rupy-0.2.4.jar to meet convention. It > appears to be a final release, even though is versioned as v0.2.4. > I will attempt to contact the developer to inform him of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2198) Please upload simple-4.0.1 to central Maven 2 repo
Please upload simple-4.0.1 to central Maven 2 repo -- Key: MAVENUPLOAD-2198 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2198 Project: Maven Upload Requests Issue Type: Wish Reporter: Gary S. Weaver Attachments: simple-web-4.0.1-bundle.jar, simple-web-4.0.1.jar Simple ( http://www.simpleframework.org/ ) is self described as: "The goal of Simple is to bring the power of simplicity to the world of server side Java. The primary focus of the project is to provide a truly embeddable Java based HTTP engine capable of handling enormous loads. Simple provides a truly asynchronous service model, request completion is driven using an internal, transparent, monitoring system. This allows Simple to vastly outperform most popular Java based servers in a multi-tier environment, as it requires only a very limited number of threads to handle very high quantities of concurrent clients. Simple has consistently out performed both commercial and open source Java Servlet engines and has a fully comprehensive API that is as usable for experienced Java developers as it is for beginners. Best of all, Simple is completely free, and is released under the terms of the GNU Lesser General Public License, LGPL, which ensures its availability for use by open source and proprietary developers alike." Simple is also mentioned here (where I found reference to it): http://java-source.net/open-source/web-servers I think it would make a good addition to the central Maven 2 repository, and I'd consider using it in a project I'm developing. I also mentioned it on the maven users mailing list. I will attempt to contact the developer to inform him of this. Bundle attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MREPOSITORY-11) Javadoc not included in the bundle
[ http://jira.codehaus.org/browse/MREPOSITORY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146864#action_146864 ] Gary S. Weaver commented on MREPOSITORY-11: --- It looks like the fix version is earlier than 2.1. It appears it is working in 2.0.9. > Javadoc not included in the bundle > -- > > Key: MREPOSITORY-11 > URL: http://jira.codehaus.org/browse/MREPOSITORY-11 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven version: 2.0.7 > Java version: 1.4.2_13 > OS name: "windows xp" version: "5.1" arch: "x86" >Reporter: Julien HENRY >Assignee: Carlos Sanchez > Fix For: 2.1 > > > On a simple project, I run: > mvn clean source:jar javadoc:jar repository:bundle-create > As a result in target I get: > artifact-version.jar > artifact-version-bundle.jar > artifact-version-javadoc.jar > artifact-version-sources.jar > But in artifact-version-bundle.jar there are only: > META-INF > pom.xml > LICENSE.txt > artifact-version.jar > artifact-version-sources.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-2197) Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite version number)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary S. Weaver updated MAVENUPLOAD-2197: Attachment: rupy-0.2.4-bundle.jar Ok, here is the real bundle that I just created (attached as rupy-0.2.4-bundle.jar). > Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite > version number) > -- > > Key: MAVENUPLOAD-2197 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2197 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: rupy-0.2.4-bundle.jar, rupy-0.2.4.jar > > > Rupy ( http://code.google.com/p/rupy/ ) is self described as: "Weighing less > than 50KB, rupy is probably the smallest Java NIO application server in the > world. Rupy is inherently non-blocking asynchronous, which makes it the ideal > candidate for high concurrency real-time applications pushing dynamic data. > Tested with acme, rupy performs on average ~1500 requests per second. To put > that figure in perspective; acme doesn't use keep-alive, so that means 1500 > unique TCP connections serving dynamic content per second! Thanks to NIO and > an event queue to avoid selector trashing, this figure degrades gracefully > under high concurrency. " > Rupy is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I renamed http.jar in the bundle to rupy-0.2.4.jar to meet convention. It > appears to be a final release, even though is versioned as v0.2.4. > I will attempt to contact the developer to inform him of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2196) piccolo2d.org, version 1.2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] M. Rohrmoser closed MAVENUPLOAD-2196. - Resolution: Won't Fix Sorry, one of the bundles isn't correct. I'll file a new wish when corrected. > piccolo2d.org, version 1.2.1 > > > Key: MAVENUPLOAD-2196 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2196 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: M. Rohrmoser > Attachments: piccolo2d-core-1.2.1-bundle.jar, > piccolo2d-examples-1.2.1-bundle.jar, piccolo2d-extras-1.2.1-bundle.jar > > > http://code.google.com/p/piccolo2d > I'm a developer of piccolo2d, please upload. > To verify, see the issue at piccolo2d: > http://code.google.com/p/piccolo2d/issues/detail?id=62 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3698) Improve performance regarding concrete/dynamic build transitions surrounding plugin executions and report instantiations
[ http://jira.codehaus.org/browse/MNG-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146859#action_146859 ] John Casey commented on MNG-3698: - Finally, I reimplemented the ModelUtils.cloneXXX(..) methods to use direct object construction instead of the previous attempt to reuse the DefaultModelInheritanceAssembler, or the interim attempt at using serialization/deserializationto get a guaranteed-clean copy. > Improve performance regarding concrete/dynamic build transitions surrounding > plugin executions and report instantiations > > > Key: MNG-3698 > URL: http://jira.codehaus.org/browse/MNG-3698 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > > This is increasing time to build by anywhere from 20% up to a reported 300%, > depending on whether reports and aggregator mojos are bound into the > lifecycle phases that are executed. Best candidate for fixing this issue is > currently to move this transition into the LIfecycleExecutor (out of the > PluginManager and PluginParameterExpressionEvaluator) to make the transition > less sensitive to report instantiation and forked lifecycles. > There are a couple of other potential performance improvements in the > interpolator itself, such as giving a plausible buffer size to the > StringWriter embedded for model interpolation, and hanging onto the > plexus-interpolator RegexBasedInterpolator instance to prevent continual > re-instantiation of the underlying regex Pattern object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3698) Improve performance regarding concrete/dynamic build transitions surrounding plugin executions and report instantiations
[ http://jira.codehaus.org/browse/MNG-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146857#action_146857 ] John Casey commented on MNG-3698: - Additionally, I implemented a new ModelInterpolator that uses reflection instead of serialization/deserialization, and String.indexOf(..) to search for expressions inside values instead of regex Pattern/Matcher instances. > Improve performance regarding concrete/dynamic build transitions surrounding > plugin executions and report instantiations > > > Key: MNG-3698 > URL: http://jira.codehaus.org/browse/MNG-3698 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > > This is increasing time to build by anywhere from 20% up to a reported 300%, > depending on whether reports and aggregator mojos are bound into the > lifecycle phases that are executed. Best candidate for fixing this issue is > currently to move this transition into the LIfecycleExecutor (out of the > PluginManager and PluginParameterExpressionEvaluator) to make the transition > less sensitive to report instantiation and forked lifecycles. > There are a couple of other potential performance improvements in the > interpolator itself, such as giving a plausible buffer size to the > StringWriter embedded for model interpolation, and hanging onto the > plexus-interpolator RegexBasedInterpolator instance to prevent continual > re-instantiation of the underlying regex Pattern object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2197) Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite version number)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146856#action_146856 ] Gary S. Weaver commented on MAVENUPLOAD-2197: - Rats. I didn't actually create a bundle. Ignore that Bundle URL. I'll create a bundle and attach it shortly. > Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite > version number) > -- > > Key: MAVENUPLOAD-2197 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2197 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Gary S. Weaver > Attachments: rupy-0.2.4.jar > > > Rupy ( http://code.google.com/p/rupy/ ) is self described as: "Weighing less > than 50KB, rupy is probably the smallest Java NIO application server in the > world. Rupy is inherently non-blocking asynchronous, which makes it the ideal > candidate for high concurrency real-time applications pushing dynamic data. > Tested with acme, rupy performs on average ~1500 requests per second. To put > that figure in perspective; acme doesn't use keep-alive, so that means 1500 > unique TCP connections serving dynamic content per second! Thanks to NIO and > an event queue to avoid selector trashing, this figure degrades gracefully > under high concurrency. " > Rupy is also mentioned here (where I found reference to it): > http://java-source.net/open-source/web-servers > I think it would make a good addition to the central Maven 2 repository, and > I'd consider using it in a project I'm developing. I also mentioned it on the > maven users mailing list. > I renamed http.jar in the bundle to rupy-0.2.4.jar to meet convention. It > appears to be a final release, even though is versioned as v0.2.4. > I will attempt to contact the developer to inform him of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2197) Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite version number)
Please upload rupy-0.2.4 to central Maven 2 repo (is final version despite version number) -- Key: MAVENUPLOAD-2197 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2197 Project: Maven Upload Requests Issue Type: Wish Reporter: Gary S. Weaver Attachments: rupy-0.2.4.jar Rupy ( http://code.google.com/p/rupy/ ) is self described as: "Weighing less than 50KB, rupy is probably the smallest Java NIO application server in the world. Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data. Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn't use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency. " Rupy is also mentioned here (where I found reference to it): http://java-source.net/open-source/web-servers I think it would make a good addition to the central Maven 2 repository, and I'd consider using it in a project I'm developing. I also mentioned it on the maven users mailing list. I renamed http.jar in the bundle to rupy-0.2.4.jar to meet convention. It appears to be a final release, even though is versioned as v0.2.4. I will attempt to contact the developer to inform him of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-351) ${project.xxxx} is not interpolated in the descriptor
${project.} is not interpolated in the descriptor
-
Key: MASSEMBLY-351
URL: http://jira.codehaus.org/browse/MASSEMBLY-351
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Brian Fox
Fix For: 2.2-beta-3
The old syntax of ${pom.xxx} is supported, but the proper maven 2 syntax of
${project.xxx} is not. The ${pom should be deprecated like it is in maven and
${project should be supported.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MASSEMBLY-351) ${project.xxxx} is not interpolated in the descriptor
[
http://jira.codehaus.org/browse/MASSEMBLY-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-351:
-
Fix Version/s: 2.2-beta-3
> ${project.} is not interpolated in the descriptor
> -
>
> Key: MASSEMBLY-351
> URL: http://jira.codehaus.org/browse/MASSEMBLY-351
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Brian Fox
> Fix For: 2.2-beta-3
>
>
> The old syntax of ${pom.xxx} is supported, but the proper maven 2 syntax of
> ${project.xxx} is not. The ${pom should be deprecated like it is in maven and
> ${project should be supported.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MCLEAN-29) Maven clean plugin doesn't filter resources from exclude list
[
http://jira.codehaus.org/browse/MCLEAN-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCLEAN-29:
Description:
For example you want to delete content of folder but want to keep folder itself
and it's SCM (e.g. SVN) information. Following configuration for
"maven-maven-clean" plugin deletes all plain files under ".svn" directory and
simply keeps empty subdirs. Thus, making update command impossible.
{code:xml}
...
maven-clean-plugin
true
logic/src/test/generated/resources
.svn/**/*
**/*
false
{code}
was:
For example you want to delete content of folder but want to keep folder itself
and it's SCM (e.g. SVN) information. Following configuration for
"maven-maven-clean" plugin deletes all plain files under ".svn" directory and
simply keeps empty subdirs. Thus, making update command impossible.
...
maven-clean-plugin
true
logic/src/test/generated/resources
.svn/**/*
**/*
false
> Maven clean plugin doesn't filter resources from exclude list
> -
>
> Key: MCLEAN-29
> URL: http://jira.codehaus.org/browse/MCLEAN-29
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
>Reporter: Vladimir Sosnin
> Attachments: clean-exclude.zip, dont-delete-excluded-file-test.patch,
> dont-delete-excluded-file.patch
>
>
> For example you want to delete content of folder but want to keep folder
> itself and it's SCM (e.g. SVN) information. Following configuration for
> "maven-maven-clean" plugin deletes all plain files under ".svn" directory and
> simply keeps empty subdirs. Thus, making update command impossible.
> {code:xml}
>
> ...
>
>
> maven-clean-plugin
>
> true
>
>
> logic/src/test/generated/resources
>
> .svn/**/*
>
>
> **/*
>
> false
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRAR-22) Allow filtering of source resources
[ http://jira.codehaus.org/browse/MRAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRAR-22: - Fix Version/s: 2.3 Issue Type: Improvement (was: Bug) > Allow filtering of source resources > > > Key: MRAR-22 > URL: http://jira.codehaus.org/browse/MRAR-22 > Project: Maven 2.x Rar Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Basil James Whitehouse III > Fix For: 2.3 > > > There doesn't appear to be a way to filter the contents of /src/main/rar . > This would be very useful to filter the project version into Geronimo > specific descriptors (as well as other custom settings). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANT-44) Generated ant copy commands in package target point to hard-coded local repository instead of ${maven.repo.local}
[
http://jira.codehaus.org/browse/MANT-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-44.
-
Assignee: Benjamin Bentmann (was: Dennis Lundberg)
Resolution: Fixed
Fix Version/s: 2.1.1
Fixed in [r691629|http://svn.apache.org/viewvc?view=rev&revision=691629],
SNAPSHOT deployed.
Dennis, could you review the fix and tweak it in case the solution you
mentioned is cleaner or more robust?
> Generated ant copy commands in package target point to hard-coded local
> repository instead of ${maven.repo.local}
> -
>
> Key: MANT-44
> URL: http://jira.codehaus.org/browse/MANT-44
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Professional SP2
>Reporter: Travis Martensen
>Assignee: Benjamin Bentmann
> Fix For: 2.1.1
>
>
> When generating a build file, copy commands in the "package" target are
> hard-coded to the local repository, even with no hard-coded paths in the POM.
> I'm guessing the hard-coded path should be replaced with ${maven.repo.local}.
> Example:
> {code:xml}
>
>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
>
> todir="${maven.build.dir}/${maven.build.finalName}/WEB-INF/lib"/>
> basedir="${maven.build.outputDir}"
> compress="true"
> webxml="${basedir}/src/main/webapp/WEB-INF/web.xml">
>
>
> excludes="web.xml"/>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[ http://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146844#action_146844 ] Jens Bannmann commented on MASSEMBLY-108: - Petar: sorry for the imprecise description. The problem is that the folder does not exist in my source tree. I wanted to create it without an Ant script or another hack, just specify that the assembly plugin should create this folder before zipping. > Assembly Plugin Implicitly Excludes Empty Directory > --- > > Key: MASSEMBLY-108 > URL: http://jira.codehaus.org/browse/MASSEMBLY-108 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sharmarke Aden > Fix For: 2.3-beta-1 > > > It seems that the inclusion of an empty directory isn't currently possible > with the assembly plugin. This is a problem because I would like to have an > empty "logs" directory included with my zip file assembly. It would be nice > if the assembly plugin gave you the option to add empty directories to an > assembly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MANT-45) basedir attribute of task of package target in generated Ant build causes files to be archived twice
[
http://jira.codehaus.org/browse/MANT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-45.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1.1
Fixed in [r691615|http://svn.apache.org/viewvc?view=rev&revision=691615].
The new target looks like
{code:xml}
{code}
i.e. I removed the basedir attribute as suggested but removed the tag
instead of the tag. The later one denotes the WEB-INF's parent
directory and usually contains additional files.
> basedir attribute of task of package target in generated Ant build
> causes files to be archived twice
> --
>
> Key: MANT-45
> URL: http://jira.codehaus.org/browse/MANT-45
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Professional SP2, Ant 1.7.0
>Reporter: Travis Martensen
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.1.1
>
>
> When comparing the WAR file built by Ant generated from a POM and the WAR
> file from the Maven build, it appears that files are doubled in the WAR (with
> different paths) when build by the Ant file. A workaround for this is to
> remove the line below:
> {code:xml}
> basedir="${maven.build.outputDir}"
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[
http://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146833#action_146833
]
Petar Tahchiev commented on MASSEMBLY-108:
--
I don't understand this issue. I have a project that has the following
structure:
{noformat}
pom.xml
src/-|
|
|--main/-|
|
|-include/-|
|
|-a.txt
|-b/
{noformat}
And the last folder b/ is an empty folder. I can include a.txt and b/ in the
zip with the following assembly descriptor:
{noformat}
bin
zip
src/main/include/
{noformat}
I used both 2.2-beta-1 and 2.2-beta-3-SNAPSHOT.
Is that what you want to achieve?
> Assembly Plugin Implicitly Excludes Empty Directory
> ---
>
> Key: MASSEMBLY-108
> URL: http://jira.codehaus.org/browse/MASSEMBLY-108
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sharmarke Aden
> Fix For: 2.3-beta-1
>
>
> It seems that the inclusion of an empty directory isn't currently possible
> with the assembly plugin. This is a problem because I would like to have an
> empty "logs" directory included with my zip file assembly. It would be nice
> if the assembly plugin gave you the option to add empty directories to an
> assembly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SCM-246) p4 command reports most or all errors on stderr but maven-scm-provider-perforce throws away stderr
[ http://jira.codehaus.org/browse/SCM-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated SCM-246: Fix Version/s: (was: future) 1.1.1 Patch applied in r[r691605|http://svn.apache.org/viewvc?rev=691605&view=rev]. Leave open for other commands. > p4 command reports most or all errors on stderr but > maven-scm-provider-perforce throws away stderr > -- > > Key: SCM-246 > URL: http://jira.codehaus.org/browse/SCM-246 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce > Environment: I tested this with whatever version came down by default > & then with the lastest svn trunk. The fixes & affects versions available in > this issue form don't seem to match the versions available. > [EMAIL PROTECTED] maven-scm-provider-perforce]$ p4 -V > Perforce - The Fast Software Configuration Management System. > Copyright 1995-2006 Perforce Software. All rights reserved. > Rev. P4/LINUX24X86/2006.1/101890 (2006/06/21). > [EMAIL PROTECTED] maven-scm-provider-perforce]$ p4 info > User name: tparker > Client name: tua > Client host: tua.uiactive.com > Client unknown. > Current directory: > /u01/tomp/maven-scm/maven-scm-providers/maven-scm-provider-perforce > Client address: 172.18.1.29:52715 > Server address: sydb.bullant.local:1666 > Server root: P:\P4ROOT > Server date: 2006/10/31 16:47:50 +1100 AUS Eastern Daylight Time > Server version: P4D/NTX86/2005.2/93627 (2006/02/14) > Server license: Bullant Software (fka Bullant Technology - fna Softblocks > Pty.) 40 users (support expired 2006/10/04) >Reporter: Tom Parker > Fix For: 1.1.1 > > Attachments: maven-scm-provider-perforce.patch > > > This applies to most or all commands in maven-scm-provider-perforce. I was > unable to fix some basic scm configuration issues until I downloaded the > maven-scm-provider-perforce source and hacked it to consume and report the p4 > command's stderr as well as stdout. > The attached patch fixes the problem for diff, checkin, checkout and tag. My > solution naively consumes stdout until it is finished and then consums > stderr. This isn't ideal if the output order is significant, but for the > errors situations I was dealing with, it worked fine. I had a brief search > for an InputStreamMultiplexer but found nothing. I have included todos to > improve this. > There is much potential for reuse between the classes in > maven-scm-provider-perforce, I have included todo's stating as such. > I have not fixed all the perforce commands. Sorry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SCM-367) Create new SCM provider: Proxy-SCM
[ http://jira.codehaus.org/browse/SCM-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated SCM-367: Patch Submitted: (was: [Yes]) > Create new SCM provider: Proxy-SCM > -- > > Key: SCM-367 > URL: http://jira.codehaus.org/browse/SCM-367 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 1.1 >Reporter: Andrei Solntsev >Priority: Minor > > Create one more SCM provider, Proxy SCM. > Its main goal is to checkout different modules from different places calling > other SCM providers. > See detailed description in my blog: > http://asolntsev.blogspot.com/2008/02/extending-maven-scm-proxy-scm.html > I can also provide the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-366) Provide pure-java svn implementation
[ http://jira.codehaus.org/browse/SCM-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146829#action_146829 ] Vincent Siveton commented on SCM-366: - The maven-scm-provider-svnjava is already present in our sandbox [1]. I migrated code to the latest SCM API in [r691600|http://svn.apache.org/viewvc?rev=691600&view=rev]. Some methods are not implemented yet., patch welcomes :) [1] http://svn.apache.org/repos/asf/maven/sandbox/trunk/scm/maven-scm-provider-svnjava > Provide pure-java svn implementation > > > Key: SCM-366 > URL: http://jira.codehaus.org/browse/SCM-366 > Project: Maven SCM > Issue Type: Wish > Components: maven-scm-provider-svn >Affects Versions: 1.1.1 >Reporter: Florian Kirchmeir >Priority: Minor > Fix For: 1.2 > > > Please remove the dependency on the svn.exe command-line executable! > See http://jira.codehaus.org/browse/SCM-13: > The issue has been closed as "FIXED", but the maven-scm-provider-svnjava > module appearently has never been comitted. > Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-366) Provide pure-java svn implementation
[ http://jira.codehaus.org/browse/SCM-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated SCM-366: Affects Version/s: (was: 1.0) 1.1.1 Fix Version/s: 1.2 > Provide pure-java svn implementation > > > Key: SCM-366 > URL: http://jira.codehaus.org/browse/SCM-366 > Project: Maven SCM > Issue Type: Wish > Components: maven-scm-provider-svn >Affects Versions: 1.1.1 >Reporter: Florian Kirchmeir >Priority: Minor > Fix For: 1.2 > > > Please remove the dependency on the svn.exe command-line executable! > See http://jira.codehaus.org/browse/SCM-13: > The issue has been closed as "FIXED", but the maven-scm-provider-svnjava > module appearently has never been comitted. > Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-264) Filtering in Assembly Generates Blank Files in the Archive
[ http://jira.codehaus.org/browse/MASSEMBLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146828#action_146828 ] Petar Tahchiev commented on MASSEMBLY-264: -- Hi Neill, I tested with your test-project and with both 2.2-beta-2 and 2.2-beta-3-SNAPSHOT and I can't reproduce this issue. Please, can you retest once again and report here if this issue is still relevant. Thanks, Petar. > Filtering in Assembly Generates Blank Files in the Archive > -- > > Key: MASSEMBLY-264 > URL: http://jira.codehaus.org/browse/MASSEMBLY-264 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Neill Alexander > Fix For: 2.2-beta-3 > > Attachments: maven-assembly-plugin-bug-test.tar.gz > > > When filers are filtered during assembly, the result is an empty file in the > archive (see output from unzip below): > $ unzip -l assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Archive: assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Length Date TimeName > > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/test.ini > --- > 0 3 files > This appears to be a result of some recent changes to the > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java > file (changeset 591556) which deletes the files from the temporary > directory. The problem with this is that the archive object has a reference > to the filtered files in the temporary directory. When the call to > archive.createArchive( ) is made it can't find the filtered files, and > therefore they end up empty in the archive. > The attached archive contains a test maven project you can run which will > demonstrate this bug. Run 'mvn clean assembly:assembly' and check out the > contents of target/assembly-bug-1.0.0-SNAPSHOT-buggy.zip > The simply fix is simply to roll-back the 'finally' clause added as part of > 591556 to > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java. > Whether or not it is the best fix, I don't know (hence the absence of a > patch). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-312) outputFileNameMapping not respected when the unpack=true
[
http://jira.codehaus.org/browse/MASSEMBLY-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev updated MASSEMBLY-312:
-
Attachment: massembly-312.txt
Here is the patch.
> outputFileNameMapping not respected when the unpack=true
>
>
> Key: MASSEMBLY-312
> URL: http://jira.codehaus.org/browse/MASSEMBLY-312
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Calvin Yu
> Attachments: massembly-312.txt
>
>
> If I configure a dependencySet to unpack = true, the outputFileNameMapping is
> not respected, and instead the artifact is decompressed into the output
> directory. Looking at the code, this looks like it'll affect moduleSets as
> well.
> For example:
>
> some_directory
>
> ${artifact.artifactId}.${artifact.extension}
> true
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-312) outputFileNameMapping not respected when the unpack=true
[
http://jira.codehaus.org/browse/MASSEMBLY-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146816#action_146816
]
Petar Tahchiev commented on MASSEMBLY-312:
--
Not sure if this is a bug, since the outputFileNameMapping clearly denotes that
it is supposed for file-names, not directory names. But if the maven team
decides to change this behavior I have attached a patch that can be used. Once
again, IMHO, this is not a bug itself, but instead misuse of the
outputFileNameMapping attribute.
HTH, Petar.
> outputFileNameMapping not respected when the unpack=true
>
>
> Key: MASSEMBLY-312
> URL: http://jira.codehaus.org/browse/MASSEMBLY-312
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Calvin Yu
>
> If I configure a dependencySet to unpack = true, the outputFileNameMapping is
> not respected, and instead the artifact is decompressed into the output
> directory. Looking at the code, this looks like it'll affect moduleSets as
> well.
> For example:
>
> some_directory
>
> ${artifact.artifactId}.${artifact.extension}
> true
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MECLIPSE-427) .springBeans definition throws NullPointer if BaseDir does not exist
[
http://jira.codehaus.org/browse/MECLIPSE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-427.
Resolution: Fixed
Fixed in maven-eclipse-plugin 2.6-20080903.101709-4
> .springBeans definition throws NullPointer if BaseDir does not exist
>
>
> Key: MECLIPSE-427
> URL: http://jira.codehaus.org/browse/MECLIPSE-427
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: MyEclipse support
>Affects Versions: 2.5, 2.5.1
>Reporter: Joe Freeman
>Assignee: Arnaud Heritier
> Fix For: 2.6
>
> Attachments: MECLIPSE-427.patch,
> testcase-project-meclipse-MECLIPSE-427.zip
>
>
> This is related to the fix submitted for MECLIPSE-359
> We have an application with 40 eclipse projects in it. About half of them
> have spring beans and 1/2 don't. The top level pom describes how the eclipse
> plugin should function and includes the Spring configuration component for
> the myeclipse target. A null pointer is thrown when running
> eclipse:myeclipse when the base dir doesn't exist, in our case in one of the
> projects that doesn't have any spring components. Our pom.xml fragment looks
> like
>
> 2.0
> *.xml
> src/main/resources/conf
>
> The exception stack trace looks like
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.getConfigurationFilesList(MyEclipseSpringBeansWriter.java:142)
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.write(MyEclipseSpringBeansWriter.java:93)
> The following code block with the problem throws NullPointer when
> directory.listFiles() returns a null into subdirs. Wrap the for() loop in a
> nullcheck
>try
> {
> File directory = new File( basedir );
> File[] subdirs = directory.listFiles( new FileFilter()
> {
> public boolean accept( File pathname )
> {
> return pathname.isDirectory();
> }
> } );
> for ( int i = 0; i < subdirs.length; i++ )
> {
> configFiles.addAll( getConfigurationFilesList(
> subdirs[i].getPath(), pattern ) );
> }
> configFiles.addAll( FileUtils.getFileNames( directory, pattern,
> null, true ) );
> }
> Testing:
> Take one of the test cases and remove the directory that is pointed to by the
> basedir attribute.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-137) Dependency Locations should work with an intranet repository and restricted internet access
[ http://jira.codehaus.org/browse/MPIR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146805#action_146805 ] Allor Dev commented on MPIR-137: The workaround does not work for me. I had to change maven-project-info-reports-plugin version to 2.0. > Dependency Locations should work with an intranet repository and restricted > internet access > --- > > Key: MPIR-137 > URL: http://jira.codehaus.org/browse/MPIR-137 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.1 > Environment: All environments, no internet access allowed, no > internet proxy configuration, intranet repository configured (Artifactory, > but it seems to happen with Archiva) >Reporter: Diego Parrilla >Priority: Minor > > We use Maven and Artifactory, and the PCs does not have direct internet > access allowed. Maven is configured to mirror the Artifactory repository. So, > all the users have to download their artifacts from the intranet repository. > When launching the 'site' goal (mvn site), when generating the 'Dependencies' > report, it hangs for a long time until we get this error: > [WARNING] The repository url '' is invalid - Repository 'XXX' will be > blacklisted. > It's possible to work around this problem disabling the parameter > 'dependencyLocationEnabled' in the maven-project-info-reports-plugin: > > ... > > org.apache.maven.plugins > maven-project-info-reports-plugin > 2.1 > > false > > > ... > > But I think the dependency locations should be solved using the information > stored in the intranet repository (in my case Artifactory). At this moment > the reports generated do not include the Dependency Location information. > You can read this thread for a further description: > http://www.nabble.com/Problem-with-Maven%2C-Hudson%2C-Archiva---Builds-take-very-long-td19158623.html#a19218823 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-121) Custom manifest attributres are ignored.
[
http://jira.codehaus.org/browse/MASSEMBLY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146793#action_146793
]
Petar Tahchiev commented on MASSEMBLY-121:
--
I tried now with 2.1, 2.2-beta-1, 2.2-beta-2, 2.2-beta-3-SNAPSHOT from both the
project root and the parent's directory and it works well.
You can go on and close the issue, sorry for my previous post.
Thanks, Petar.
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-plugin.patch, massembly121.zip
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
> ${project.build.directory}
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2196) piccolo2d.org, version 1.2.1
piccolo2d.org, version 1.2.1 Key: MAVENUPLOAD-2196 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2196 Project: Maven Upload Requests Issue Type: Wish Reporter: M. Rohrmoser Attachments: piccolo2d-core-1.2.1-bundle.jar, piccolo2d-examples-1.2.1-bundle.jar, piccolo2d-extras-1.2.1-bundle.jar http://code.google.com/p/piccolo2d I'm a developer of piccolo2d, please upload. To verify, see the issue at piccolo2d: http://code.google.com/p/piccolo2d/issues/detail?id=62 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-88) Cannot mvn install pom.xml that has build/extension/extions pointing to a jar file with set of pmd rules when using maven-2.1-SNAPSHOT
Cannot mvn install pom.xml that has build/extension/extions pointing to a jar file with set of pmd rules when using maven-2.1-SNAPSHOT -- Key: MPMD-88 URL: http://jira.codehaus.org/browse/MPMD-88 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4, 2.3, 2.2 Environment: Windows Reporter: Allan G. Ramirez Attachments: apache-maven-2.1-659801-bin.zip, debug-error.txt, files.zip How to reproduce: 1. extract the files 2. set the environment variable such that maven-2.1-SNAPSHOT is used 3. mvn install /corporate-rules/ 4. mvn instlal /corporate-pom/ An exception will occur after step 4. Inside debug-error.txt is the portion where the error started when i executed mvn clean install -X. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-445) myeclipse target doesn't generate spring bean files for hierarchical projects.
[ http://jira.codehaus.org/browse/MECLIPSE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-445. Resolution: Fixed Fixed in maven-eclipse-plugin 2.6-20080903.065856-3 > myeclipse target doesn't generate spring bean files for hierarchical projects. > -- > > Key: MECLIPSE-445 > URL: http://jira.codehaus.org/browse/MECLIPSE-445 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: MyEclipse support >Affects Versions: 2.5.1 >Reporter: Joe Freeman >Assignee: Arnaud Heritier > Fix For: 2.6 > > Attachments: MECLIPSE-445.zip > > > The spring bean file creation code doesn't works only when the current > working directory is the same as the project directory. This means it works > fine for single level projects. We have an n-deep hierarchy of projects > where we run the eclipse:eclipse and eclipse:myeclipse targets from the top. > In this situation, the cwd doesn't change as it traverses the hierarchy so > absolute paths must be used for navigation and then trimmed when the actual > fiile references are put in the spring beans file. I have a patch for this > but don't yet have a standalone test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
