[jira] Closed: (WAGON-284) Artifacts are uploaded twice in the case of HTTP redirection
[ http://jira.codehaus.org/browse/WAGON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed WAGON-284. --- Resolution: Won't Fix Assignee: Mark Struberg Actually it's not a problem imo. Using the 100-continue mechanism would mean that _every_ request would need to be sent twice! The 100-continue logic is to send a request upfront if the server is willing to accept the data at all. The server will most likely respond with a HTTP_CONTINUE (100) ret code. In this case the client sends the real request. IF we'd like to implement that, then it would only make sense to do this solely for big uploads. Which is a bit of a problem for the stream based wagons. > Artifacts are uploaded twice in the case of HTTP redirection > > > Key: WAGON-284 > URL: http://jira.codehaus.org/browse/WAGON-284 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Assignee: Mark Struberg >Priority: Minor > Fix For: 1.0 > > > When deploying to an HTTP (not DAV) repository, if the request is redirected, > the artifact is uploaded twice: once for the original request, and then again > at the redirect location. > Please consider using "Expect: 100-continue" when uploading, so as not to > waste bandwidth in the case of a redirect. See RFC 2616 section 8.2.3. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-284) Artifacts are uploaded twice in the case of HTTP redirection
[ http://jira.codehaus.org/browse/WAGON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270768#comment-270768 ] Mark Struberg commented on WAGON-284: - read more over at httpclient4 https://issues.apache.org/jira/browse/HTTPCLIENT-889 > Artifacts are uploaded twice in the case of HTTP redirection > > > Key: WAGON-284 > URL: http://jira.codehaus.org/browse/WAGON-284 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Assignee: Mark Struberg >Priority: Minor > Fix For: 1.0 > > > When deploying to an HTTP (not DAV) repository, if the request is redirected, > the artifact is uploaded twice: once for the original request, and then again > at the redirect location. > Please consider using "Expect: 100-continue" when uploading, so as not to > waste bandwidth in the case of a redirect. See RFC 2616 section 8.2.3. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-248) Support custom jira status ids, please
[ http://jira.codehaus.org/browse/MCHANGES-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MCHANGES-248: --- Assignee: Benson Margulies > Support custom jira status ids, please > -- > > Key: MCHANGES-248 > URL: http://jira.codehaus.org/browse/MCHANGES-248 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: jira >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.6 > > Attachments: MCHANGES-248.patch > > > It is possible to add status IDs to JIRA. e.g., Verified. There is currently > no way to make these work with the changes plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MNG-2258: -- Labels: maven-messy (was: ) > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Blocker > Labels: maven-messy > Fix For: Issues to be reviewed for 3.x > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MNG-2258. - Resolution: Fixed Fix Version/s: (was: Issues to be reviewed for 3.x) 3.0.3 Assignee: Benson Margulies The original problem reported in the original test case is fixed in 3.0.3. There is much other material in here, but if someone claims that it amounts to a defect, they can make a distinct JIRA with a test case to that effect. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-591) Integration tests lifecycle
[ http://jira.codehaus.org/browse/MNG-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MNG-591. Resolution: Fixed Fix Version/s: (was: Issues to be reviewed for 3.x) Assignee: Benson Margulies The last comment in here was years ago, inviting the OP to comment if the work done was insufficient. There is no comment in all that time, so a close is overdue. > Integration tests lifecycle > --- > > Key: MNG-591 > URL: http://jira.codehaus.org/browse/MNG-591 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Kenney Westerhof >Assignee: Benson Margulies >Priority: Blocker > Original Estimate: 8 hours > Time Spent: 45 minutes > Remaining Estimate: 7 hours, 15 minutes > > I'm trying to do an integration test that depends on a war/ear to be deployed. > What i'm missing is: > - integration-test-compile stage and/or: > - a way to specify an integrationTestSourceDirectory or multiple > testSourceDirectories in the pom > I can't put the test sources in src/test/java because then surefire will run > them in the test stage, when > there's no artifact to deploy yet. > [Btw, I'm doing this while creating a cactus plugin, for the moment using > cargo in the TestSuite itself to deploy.] > The idea is that the integration test sources go in src/itest/*; that there > be a integration-test-compile, > integration-test-package and/or integration-test-appdeploy[or something] and > that surefire > is also bound to integration-test. > Maybe something can be done using the src/test/project/some-project/ > approach seen in > maven-javadoc-plugin, maven-site-plugin and maven-eclipse-plugin (i'd like to > see some of that > standardized anyway to allow plugin testing generally - which can also be > seen as integration testing). > Thoughts, comments, approaches? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3840) javadoc is non existent
[ http://jira.codehaus.org/browse/MNG-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MNG-3840. - Resolution: Not A Bug Fix Version/s: (was: Documentation Deficit) Assignee: Benson Margulies While it is true that the javadoc available on much of the maven source is risible, a single JIRA to that effect does not help anyone fix anything. Ask yourself how anyone would ever decide to close this as fixed? > javadoc is non existent > --- > > Key: MNG-3840 > URL: http://jira.codehaus.org/browse/MNG-3840 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Documentation: General >Affects Versions: 2.0.9 > Environment: All >Reporter: Martin West >Assignee: Benson Margulies >Priority: Blocker > > e.g. > http://maven.apache.org/ref/2.0.9/maven-artifact/apidocs/org/apache/maven/artifact/resolver/ArtifactResolver.html > This is symptomatic of the whole maven project documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270827#comment-270827 ] Benson Margulies commented on MNG-4301: --- Doesn't this net out to a bug in the dav plugin, not maven itself? > Invalid checksums on deploy when using webdav without extension > --- > > Key: MNG-4301 > URL: http://jira.codehaus.org/browse/MNG-4301 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 2.2.1 > Environment: n/a >Reporter: Kevin Shekleton >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > > With maven 2.2.1, our deployments via webdav are producing invalid checksums, > similar to the issue reported in MNG-4235. > From maven 2.0.8 and previous, the following build extension was required to > deploy via webdav: > > > org.apache.maven.wagon > wagon-webdav > 1.0-beta-2 > > > Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and > the aforementioned build extension must be removed from the project. If it > was included in the project the deployment would fail as Maven would report > multiple versions of wagon-webdav present. > With maven 2.2.0, our deployment suffered from invalid checksums reported in > MNG-4235. > With maven 2.2.1, we still see the invalid checksums on deployment as > reported in MNG-4235. However, I've found that if you add the above build > extension into the project, we don't experience this issue (of generating > invalid checksums). Is this workaround an intentional change brought about > by the fix of MNG-4235? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2902) long build startup times due to frequent network access for SNAPSHOT resolving
[ http://jira.codehaus.org/browse/MNG-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MNG-2902. - Resolution: Fixed Fix Version/s: (was: Issues to be reviewed for 3.x) 2.2.1 Assignee: Benson Margulies (was: Jason van Zyl) I tested this and observed no particular gap in time with 2.2.1. > long build startup times due to frequent network access for SNAPSHOT resolving > -- > > Key: MNG-2902 > URL: http://jira.codehaus.org/browse/MNG-2902 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.x (to be reviewed) >Reporter: Jorg Heymans >Assignee: Benson Margulies >Priority: Blocker > Fix For: 2.2.1 > > > IRC log: > jorg: is it normal that between 'Scanning for projects' and the first actual > build output it takes about 1 minute ? > [20:45] jvanzyl: jorg > [20:45] jvanzyl: probably network > [20:45] jvanzyl: you have snapshots? > [20:46] jorg: snapshot of what ? > [20:46] jorg: oh in general you mean > [20:46] jvanzyl: in 2.1 i'm trying to scour the code to make sure it never > touches the network if everything is local > [20:46] jvanzyl: it doesn't do that very well right now > [20:46] jvanzyl: yah > [20:46] jorg: well not on external dependencies no ... > [20:47] jvanzyl: yah, we need to track the pull during a sessions which we > don't > [20:47] jorg: our own modules are however all snapshots ... perhaps that's > what it's trying to resolve > [20:47] jvanzyl: can you put that in a jira and i will assign to 2.1-alpha-1 > [20:47] jorg: ok but the behaviour is expected as is .. that's all i wanted > to make sure then > [20:47] jvanzyl: and then assign to me so i don't forget and i will look at it > [20:47] jvanzyl: it shouldn't do that, but obviously it does > [20:47] jorg: shall i paste the full output of -X or just the start ? > [20:47] jvanzyl: it's doing it for each module > [20:48] jvanzyl: just the start is fine > [20:48] jvanzyl: i get the idea > [20:48] jvanzyl: yah, that's really annoying > [20:48] jorg: ok thanks for the feedback jason, i'll create an issue for it > [20:49] jvanzyl: great, thanks > [20:50] jvanzyl: just paste the issue here > [20:50] jvanzyl: and i'll change the fix version and assign it to me > --- BUILD OUTPUT > jorg:~/src/cocoon-trunk jheymans$ mvn clean install -Dmaven.test.skip=true > -Pallblocks -X > + Error stacktraces are turned on. > Maven version: 2.0.6-SNAPSHOT > [DEBUG] Building Maven user-level plugin registry from: > '/Users/jheymans/.m2/plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > '/Users/jheymans/tools/maven2/conf/plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Searching for parent-POM: org.apache:apache::4 of project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT in relative path: ../pom.xml > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > specification in org.apache.cocoon:cocoon:pom:4-SNAPSHOT: > Specified: org.apache:apache::4 > Found: org.apache.excalibur:excalibur:pom:1 > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.cocoon:cocoon:pom:4-SNAPSHOT from the repository. > [DEBUG] Retrieving parent-
[jira] Closed: (JXR-71) JXR doesn't link classes with non letters in their names
[ http://jira.codehaus.org/browse/JXR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed JXR-71. Resolution: Fixed Fix Version/s: 2.3 Assignee: Herve Boutemy patch applied in [r1137457|http://svn.apache.org/viewvc?rev=1137457&view=rev] thank you > JXR doesn't link classes with non letters in their names > > > Key: JXR-71 > URL: http://jira.codehaus.org/browse/JXR-71 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Affects Versions: 2.1 >Reporter: James Agnew >Assignee: Herve Boutemy > Fix For: 2.3 > > Attachments: jxr.patch > > > JXR won't currently link together any classes which contain non-letters in > their names (ie. underscores, numbers, etc) even though these are valid. > The attached patch fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JXR-79) NPE on source XREF
[
http://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated JXR-79:
-
Description:
{noformat}[INFO] Generating "Source Xref" report.
[DEBUG] Scanning
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java
[DEBUG] parsing... com/cedarsoft/VersionRange.java
[DEBUG] parsing... com/cedarsoft/Version.java
[DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java
[DEBUG] parsing... com/cedarsoft/VersionMismatchException.java
[DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java
[DEBUG] parsing... com/cedarsoft/VersionException.java
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html
[DEBUG]
/home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java
->
/home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html
[DEBUG] **
[DEBUG] Starting Jakarta Velocity v1.4
[DEBUG] RuntimeInstance initializing.
[DEBUG] Default Properties File:
org/apache/velocity/runtime/defaults/velocity.properties
[DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger
[DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger
[DEBUG] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[DEBUG] Resource Loader Instantiated:
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ClasspathResourceLoader : initialization starting.
[DEBUG] ClasspathResourceLoader : initialization complete.
[DEBUG] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
[DEBUG] Default ResourceManager initialization complete.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[DEBUG] Created: 20 parsers.
[DEBUG] Velocimacro : initialization starting.
[DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
NOT replace previous VM definitions
[DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[DEBUG] Velocimacro : messages on : VM system will output logging messages
[DEBUG] Velocimacro : autoload off : VM system will not automatically reload
global library macros
[DEBUG] Velocimacro : initialization complete.
[DEBUG] Velocity successfully started.
[DEBUG] ResourceManager : found templates/index.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceManager : found templates/overview-frame.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceManager : found templates/allclasses-frame.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceManager : found templates/overview-summary.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceManager : found templates/package-summary.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceManager : found templates/package-frame.vm with loader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[INFO]
[ERROR] FATAL ERROR
[INFO] --
[jira] Updated: (JXR-59) speed up AbstractJxrReport.hasSources()
[
http://jira.codehaus.org/browse/JXR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated JXR-59:
-
Description:
The method AbstractJxrReport.hasSources( File dir ) spends a lot of time
scanning .svn directories when I do my build.
If you replace the line,
{code:java}else if ( currentFile.isDirectory() ){code}
with the lines
{code:java}else if ( currentFile.isDirectory() &&
Character.isJavaIdentifierStart(currentFile.getName().charAt(0))
){code}
You will speed this up.
If the first character in the directory is not a valid java identifier start,
then the directory cannot contain java code. '.' is not a valid java
identifier start, so .svn directories are ignored when scanning for sources.
was:
The method AbstractJxrReport.hasSources( File dir ) spends a lot of time
scanning .svn directories when I do my build.
If you replace the line,
else if ( currentFile.isDirectory() )
with the lines
else if ( currentFile.isDirectory() &&
Character.isJavaIdentifierStart(currentFile.getName().charAt(0))
)
You will speed this up.
If the first character in the directory is not a valid java identifier start,
then the directory cannot contain java code. '.' is not a valid java
identifier start, so .svn directories are ignored when scanning for sources.
> speed up AbstractJxrReport.hasSources()
> ---
>
> Key: JXR-59
> URL: http://jira.codehaus.org/browse/JXR-59
> Project: Maven JXR
> Issue Type: Improvement
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Sean Bridges
>Priority: Minor
>
> The method AbstractJxrReport.hasSources( File dir ) spends a lot of time
> scanning .svn directories when I do my build.
> If you replace the line,
> {code:java}else if ( currentFile.isDirectory() ){code}
> with the lines
> {code:java}else if ( currentFile.isDirectory() &&
> Character.isJavaIdentifierStart(currentFile.getName().charAt(0))
> ){code}
> You will speed this up.
> If the first character in the directory is not a valid java identifier start,
> then the directory cannot contain java code. '.' is not a valid java
> identifier start, so .svn directories are ignored when scanning for sources.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JXR-59) speed up AbstractJxrReport.hasSources()
[
http://jira.codehaus.org/browse/JXR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed JXR-59.
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Herve Boutemy
fixed in [r1137460|http://svn.apache.org/viewvc?rev=1137460&view=rev]
thank you
> speed up AbstractJxrReport.hasSources()
> ---
>
> Key: JXR-59
> URL: http://jira.codehaus.org/browse/JXR-59
> Project: Maven JXR
> Issue Type: Improvement
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Sean Bridges
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.3
>
>
> The method AbstractJxrReport.hasSources( File dir ) spends a lot of time
> scanning .svn directories when I do my build.
> If you replace the line,
> {code:java}else if ( currentFile.isDirectory() ){code}
> with the lines
> {code:java}else if ( currentFile.isDirectory() &&
> Character.isJavaIdentifierStart(currentFile.getName().charAt(0))
> ){code}
> You will speed this up.
> If the first character in the directory is not a valid java identifier start,
> then the directory cannot contain java code. '.' is not a valid java
> identifier start, so .svn directories are ignored when scanning for sources.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JXR-88) create jxr:aggregate and jxr:test-aggregate
create jxr:aggregate and jxr:test-aggregate --- Key: JXR-88 URL: http://jira.codehaus.org/browse/JXR-88 Project: Maven JXR Issue Type: New Feature Affects Versions: 2.2 Reporter: Herve Boutemy in MJAVADOC-212, aggregate parameter of javadoc:javadoc was replaced by javadoc:aggregate, which is more flexible JXR should do the same change -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5119) improve site organization of core components
[ http://jira.codehaus.org/browse/MNG-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-5119: --- Description: see http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:i5vduo7nzq47anoi+state:results work in progress can be evaluated comparing [3.0.3|http://maven.apache.org/ref/3.0.3/] and [3.0.4-SNAPSHOT|http://maven.apache.org/ref/3.0.4-SNAPSHOT/] was:see http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:i5vduo7nzq47anoi+state:results > improve site organization of core components > > > Key: MNG-5119 > URL: http://jira.codehaus.org/browse/MNG-5119 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.0.3 >Reporter: Herve Boutemy > Fix For: 3.0.4 > > > see > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:i5vduo7nzq47anoi+state:results > work in progress can be evaluated comparing > [3.0.3|http://maven.apache.org/ref/3.0.3/] and > [3.0.4-SNAPSHOT|http://maven.apache.org/ref/3.0.4-SNAPSHOT/] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4225) Plugin dependencies are incorrectly included as needed artifacts in IBM JDK 1.5 sr8 and IBM JDK 1.6
[ http://jira.codehaus.org/browse/MNG-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MNG-4225. - Resolution: Not A Bug Fix Version/s: (was: Issues to be reviewed for 3.x) Behavior is neither incorrect, nor myterious. > Plugin dependencies are incorrectly included as needed artifacts in IBM JDK > 1.5 sr8 and IBM JDK 1.6 > > > Key: MNG-4225 > URL: http://jira.codehaus.org/browse/MNG-4225 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9 > Environment: OS : Windows Server 2003 > JDK: IBM JDK 1.5 sr8 edition and IBM JDK 1.6 >Reporter: Baback Nemazie >Assignee: Benson Margulies >Priority: Blocker > Attachments: JavaMavenTest.zip > > > We have been using a "parent pom" that specifies the plugin dependencies for > our projects. This parent pom has been in use for more than a year. We have > been using IBM JDK 1.5 sr4 until recently, and we had no problems building > the parent pom. However for the upcoming release we upgraded to IBM JDK 1.5 > sr8. Upon upgrade to the sr8 edition, when we tried to build the parent pom, > the build process incorrectly tried to search for specified plugin > dependencies, and since these specified plugin dependencies are built AFTER > the parent pom is built the build process fails with the error message that > it could not find the plugin-dependencies in order to proceed with building > the parent pom. > We encountered the same issue with IBM JDK 1.6 as well. Since many of the > developers who use our product will be using IBM JDK 1.6, we need to resolve > this issue for both IBM JDK1.5 sr8 and IBM JDK 1.6. > We did NOT encounter this issue with the Sun JDK 1.6. This led us to approach > IBM to investigate the issue as it appeared that this maybe an IBM JDK > specific issue. We sent our test case to them, and they reported to us that > suspect that maven code could be depending on the hashmap ordering, which is > breaking the dependency check. > They instructed us to post this issue to the maven issue tracking and they > will follow up with the maven folks. > Attached is the test case to reproduce the problem. Please read the file > how_to_reproduce.txt in the attached. IBM folks will provide you with the > needed JDK's. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5120) Reg:How to build a project when building another project implicitely
Reg:How to build a project when building another project implicitely Key: MNG-5120 URL: http://jira.codehaus.org/browse/MNG-5120 Project: Maven 2 & 3 Issue Type: New Feature Reporter: krishna prasad vurapalli When we are building a project and that project contains dependency from another project then we have to add the dependency explicitly . Instead of doing like that is there is any way to build the dependent project while building the main project implicitly that is we have to take the project name from the command prompt and that will be dependent project name and that project has to be build first and then that dependency will be added to our main project -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
