[jira] Closed: (MANTTASKS-219) artifact:dependencies and ant's restrict name resource filtering does not work
[
http://jira.codehaus.org/browse/MANTTASKS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wim Symons closed MANTTASKS-219.
Resolution: Not A Bug
As reported on Bugzilla, the "name" resource selector applies only to a file's
basename, not to the full path.
> artifact:dependencies and ant's restrict name resource filtering does not work
> --
>
> Key: MANTTASKS-219
> URL: http://jira.codehaus.org/browse/MANTTASKS-219
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.0.10
> Environment: SUSE Linux Enterprise Server 10 SP1 (x86_64)
> Ant 1.7.0
>Reporter: Wim Symons
>
> We have an Ant build file which calls maven-ant-tasks's dependencies to copy
> a bunch of dependencies.
> Since we need to exclude some of those jars, we used Ant's resource selectors
> to restrict the fileset produced by maven-ant-tasks.
> A small snippet from our build.xml:
> {code:xml}
>
>
>filesetid="dependencies.core" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> But when we ran the target, no files at all were copied. After a long time
> searching, we stumbled on the fact that it worked when we left out the line
> {noformat}{noformat} Our local Maven
> repository was located in {{/home/user/maven-repository}}. As it seems the
> pattern given doesn't respect the standard Ant patterns and also matches the
> directories in between (as {{maven*}} matches {{maven-repository}}).
> As a workaround, we renamed the directory containing the Maven repository to
> something that doesn't match any of the used patterns.
--
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: (MINDEXER-27) Be smarter about performing actual Lucene index changes
[
http://jira.codehaus.org/browse/MINDEXER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MINDEXER-27:
Fix Version/s: 4.1.1
Assignee: Tamás Cservenák
> Be smarter about performing actual Lucene index changes
> ---
>
> Key: MINDEXER-27
> URL: http://jira.codehaus.org/browse/MINDEXER-27
> Project: Maven Indexer
> Issue Type: New Feature
>Affects Versions: 3.1.0, 4.0.0
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 4.1.1
>
> Attachments:
> 0001-MINDEXER-27-only-update-lucene-index-when-there-are-.patch
>
>
> {{NexusIndexer.addArtifactToIndex()}} will perform Lucene index changes even
> if that does not makes any _content change_ (the artifact to be added and
> artifact already on index have _same_ ArtifactInfo).
> Still, actual IO -- Lucene Document deletion, and Lucene Document addition --
> does happen, even if it results in no logical/content change.
--
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: (MINDEXER-30) IndexPublisher does not protect "read consistency" over published context
[
http://jira.codehaus.org/browse/MINDEXER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MINDEXER-30:
Fix Version/s: 4.1.1
Assignee: Tamás Cservenák
> IndexPublisher does not protect "read consistency" over published context
> -
>
> Key: MINDEXER-30
> URL: http://jira.codehaus.org/browse/MINDEXER-30
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.0
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 4.1.1
>
>
> IndexPublisher does not protect "read consistency" over published context.
> This affects only contexts that are the new MergedIndexingContext. These --
> newly introduced context types in 4.1.0 -- are simply "logical merged view"
> of other IndexingContexts. When some change -- and async commit -- happens in
> some of the member contexts, a Lucene exception is thrown preventing proper
> publishing of the context.
> Typical top lines of these stack traces:
> {noformat}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed
> at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:177)
> at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:942)
> at org.apache.lucene.index.DirectoryReader.document(DirectoryReader.java:533)
> at org.apache.lucene.index.MultiReader.document(MultiReader.java:251)
> at org.apache.lucene.index.IndexReader.document(IndexReader.java:658)
> at
> org.apache.maven.index.incremental.DefaultIncrementalHandler.getIndexChunk(DefaultIncrementalHandler.java:154)
> at
> org.apache.maven.index.incremental.DefaultIncrementalHandler.getIncrementalUpdates(DefaultIncrementalHandler.java:65)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.packIndex(DefaultIndexPacker.java:117)
> {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] Created: (MINDEXER-30) IndexPublisher does not protect "read consistency" over published context
IndexPublisher does not protect "read consistency" over published context
-
Key: MINDEXER-30
URL: http://jira.codehaus.org/browse/MINDEXER-30
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.0
Reporter: Tamás Cservenák
IndexPublisher does not protect "read consistency" over published context.
This affects only contexts that are the new MergedIndexingContext. These --
newly introduced context types in 4.1.0 -- are simply "logical merged view" of
other IndexingContexts. When some change -- and async commit -- happens in some
of the member contexts, a Lucene exception is thrown preventing proper
publishing of the context.
Typical top lines of these stack traces:
{noformat}
org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:177)
at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:942)
at org.apache.lucene.index.DirectoryReader.document(DirectoryReader.java:533)
at org.apache.lucene.index.MultiReader.document(MultiReader.java:251)
at org.apache.lucene.index.IndexReader.document(IndexReader.java:658)
at
org.apache.maven.index.incremental.DefaultIncrementalHandler.getIndexChunk(DefaultIncrementalHandler.java:154)
at
org.apache.maven.index.incremental.DefaultIncrementalHandler.getIncrementalUpdates(DefaultIncrementalHandler.java:65)
at
org.apache.maven.index.packer.DefaultIndexPacker.packIndex(DefaultIndexPacker.java:117)
{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] Created: (MINDEXER-31) Bump Lucene to latest 3.2.0 version
Bump Lucene to latest 3.2.0 version --- Key: MINDEXER-31 URL: http://jira.codehaus.org/browse/MINDEXER-31 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Bump Lucene to latest 3.2.0 version. This would need small effort, since the "big work" was done by going from lucene 2.x API over to 3.x with indexer version 4.1.0. -- 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: (MINDEXER-31) Bump Lucene to latest 3.2.0 version
[ http://jira.codehaus.org/browse/MINDEXER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269812#action_269812 ] Tamás Cservenák commented on MINDEXER-31: - Work done on a branch with minimal changes and no functional changes. All UTs passes nicely. Now we could think of the uses of new Lucene 3.2.0 capabilities. Branch parked here: https://github.com/cstamas/maven-indexer/tree/lucene-31x > Bump Lucene to latest 3.2.0 version > --- > > Key: MINDEXER-31 > URL: http://jira.codehaus.org/browse/MINDEXER-31 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.0 >Reporter: Tamás Cservenák > Fix For: 4.2.0 > > > Bump Lucene to latest 3.2.0 version. > This would need small effort, since the "big work" was done by going from > lucene 2.x API over to 3.x with indexer version 4.1.0. -- 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: (MINDEXER-31) Bump Lucene to latest 3.2.0 version
[ http://jira.codehaus.org/browse/MINDEXER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MINDEXER-31: Affects Version/s: 4.1.0 Fix Version/s: 4.2.0 > Bump Lucene to latest 3.2.0 version > --- > > Key: MINDEXER-31 > URL: http://jira.codehaus.org/browse/MINDEXER-31 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.0 >Reporter: Tamás Cservenák > Fix For: 4.2.0 > > > Bump Lucene to latest 3.2.0 version. > This would need small effort, since the "big work" was done by going from > lucene 2.x API over to 3.x with indexer version 4.1.0. -- 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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MINDEXER-26:
Fix Version/s: 4.1.1
> NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
> -
>
> Key: MINDEXER-26
> URL: http://jira.codehaus.org/browse/MINDEXER-26
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
> Java(TM) SE Runtime
> Environment, 1.6.0_23-b05
> OS: Windows 7
>Reporter: Jesse Glick
> Fix For: 4.1.1
>
>
> http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
> user in a build embedding Maven Indexer 4.0.0.
> {noformat}
> if ( IndexWriter.isLocked( indexDirectory ) )
> {
> IndexWriter.unlock( indexDirectory );
> }
> {noformat}
> Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
> called, and this code does not check for that (other code in the same class
> does). Can probably be guarded with a simple null check?
--
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: (MINDEXER-28) OOME when fed garbage
[
http://jira.codehaus.org/browse/MINDEXER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269814#action_269814
]
Tamás Cservenák commented on MINDEXER-28:
-
Added to IndexDataReader.readUtf() to make code more robust to junk inputs:
{noformat}
byte[] bytearr;
char[] chararr;
try
{
bytearr = new byte[utflen];
chararr = new char[utflen];
}
catch ( OutOfMemoryError e )
{
final IOException ex =
new IOException(
"Index data content is inappropriate (is junk?), leads to
OutOfMemoryError! See MINDEXER-28 for more information!" );
e.initCause( e );
throw ex;
}
{noformat}
> OOME when fed garbage
> -
>
> Key: MINDEXER-28
> URL: http://jira.codehaus.org/browse/MINDEXER-28
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: JDK 6u24 on Ubuntu x86
>Reporter: Jesse Glick
>Priority: Minor
>
> See http://netbeans.org/bugzilla/show_bug.cgi?id=197988#c1 for background.
> Without the fix of MINDEXER-20 in place, the indexer will throw an
> {{OutOfMemoryError}} when given http://www.jasperforge.org/maven2/.index/
> since that site serves junk HTML with a 200 HTTP status.
> Since the code allocates an array whose length is a 32-bit int taken from an
> unverified source, it would be best to somehow handle the case that a random
> large number is read and an OOME is thrown - perhaps rethrowing as an
> {{IOException}}.
> MINDEXER-20 should prevent the bug precondition from being triggered nearly
> as often, but the input could randomly happen to begin with 0x01.
--
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: (MINDEXER-28) OOME when fed garbage
[
http://jira.codehaus.org/browse/MINDEXER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269816#action_269816
]
Jesse Glick commented on MINDEXER-28:
-
Looks right to me.
> OOME when fed garbage
> -
>
> Key: MINDEXER-28
> URL: http://jira.codehaus.org/browse/MINDEXER-28
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: JDK 6u24 on Ubuntu x86
>Reporter: Jesse Glick
>Priority: Minor
>
> See http://netbeans.org/bugzilla/show_bug.cgi?id=197988#c1 for background.
> Without the fix of MINDEXER-20 in place, the indexer will throw an
> {{OutOfMemoryError}} when given http://www.jasperforge.org/maven2/.index/
> since that site serves junk HTML with a 200 HTTP status.
> Since the code allocates an array whose length is a 32-bit int taken from an
> unverified source, it would be best to somehow handle the case that a random
> large number is read and an OOME is thrown - perhaps rethrowing as an
> {{IOException}}.
> MINDEXER-20 should prevent the bug precondition from being triggered nearly
> as often, but the input could randomly happen to begin with 0x01.
--
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: (MINDEXER-28) OOME when fed garbage
[
http://jira.codehaus.org/browse/MINDEXER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-28.
---
Resolution: Fixed
Fix Version/s: 4.1.1
> OOME when fed garbage
> -
>
> Key: MINDEXER-28
> URL: http://jira.codehaus.org/browse/MINDEXER-28
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: JDK 6u24 on Ubuntu x86
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 4.1.1
>
>
> See http://netbeans.org/bugzilla/show_bug.cgi?id=197988#c1 for background.
> Without the fix of MINDEXER-20 in place, the indexer will throw an
> {{OutOfMemoryError}} when given http://www.jasperforge.org/maven2/.index/
> since that site serves junk HTML with a 200 HTTP status.
> Since the code allocates an array whose length is a 32-bit int taken from an
> unverified source, it would be best to somehow handle the case that a random
> large number is read and an OOME is thrown - perhaps rethrowing as an
> {{IOException}}.
> MINDEXER-20 should prevent the bug precondition from being triggered nearly
> as often, but the input could randomly happen to begin with 0x01.
--
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: (MINDEXER-27) Be smarter about performing actual Lucene index changes
[
http://jira.codehaus.org/browse/MINDEXER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-27.
---
Resolution: Fixed
Fixed.
> Be smarter about performing actual Lucene index changes
> ---
>
> Key: MINDEXER-27
> URL: http://jira.codehaus.org/browse/MINDEXER-27
> Project: Maven Indexer
> Issue Type: New Feature
>Affects Versions: 3.1.0, 4.0.0
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 4.1.1
>
> Attachments:
> 0001-MINDEXER-27-only-update-lucene-index-when-there-are-.patch
>
>
> {{NexusIndexer.addArtifactToIndex()}} will perform Lucene index changes even
> if that does not makes any _content change_ (the artifact to be added and
> artifact already on index have _same_ ArtifactInfo).
> Still, actual IO -- Lucene Document deletion, and Lucene Document addition --
> does happen, even if it results in no logical/content change.
--
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: (MDEPLOY-121) Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository field
[ http://jira.codehaus.org/browse/MDEPLOY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269819#action_269819 ] Thomas Arand commented on MDEPLOY-121: -- Is there any forecast when this feature will be available? As long as it is not there, we are overloading our repositories with unnecessary artifacts, resulting in a frequent "no space left on device" production errors. > Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository > field > --- > > Key: MDEPLOY-121 > URL: http://jira.codehaus.org/browse/MDEPLOY-121 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.5 >Reporter: SebbASF >Assignee: Mark Struberg > Attachments: deploy.patch, deploy.patch > > > The altDeploymentRepository property allows the id, layout and URL of a > repository to be overriden. > However it does not allow the uniqueVersion setting to be overriden. > This reduces its usefulness as an override mechanism. > Patch implements the feature by using one of the spare fields in the property: > id::layout:uniqueVersion:url > e.g. > id::layout:true:url > id::layout:false:url > id::layout::url > If the value is empty, it defaults to true, as per the previous behaviour. -- 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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-26.
---
Resolution: Fixed
Fixed
> NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
> -
>
> Key: MINDEXER-26
> URL: http://jira.codehaus.org/browse/MINDEXER-26
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
> Java(TM) SE Runtime
> Environment, 1.6.0_23-b05
> OS: Windows 7
>Reporter: Jesse Glick
> Fix For: 4.1.1
>
>
> http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
> user in a build embedding Maven Indexer 4.0.0.
> {noformat}
> if ( IndexWriter.isLocked( indexDirectory ) )
> {
> IndexWriter.unlock( indexDirectory );
> }
> {noformat}
> Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
> called, and this code does not check for that (other code in the same class
> does). Can probably be guarded with a simple null check?
--
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: (MINDEXER-28) OOME when fed garbage
[
http://jira.codehaus.org/browse/MINDEXER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269822#action_269822
]
Tamás Cservenák commented on MINDEXER-28:
-
oops: ex.initCause(e), not like above fixed in code too.
> OOME when fed garbage
> -
>
> Key: MINDEXER-28
> URL: http://jira.codehaus.org/browse/MINDEXER-28
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: JDK 6u24 on Ubuntu x86
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 4.1.1
>
>
> See http://netbeans.org/bugzilla/show_bug.cgi?id=197988#c1 for background.
> Without the fix of MINDEXER-20 in place, the indexer will throw an
> {{OutOfMemoryError}} when given http://www.jasperforge.org/maven2/.index/
> since that site serves junk HTML with a 200 HTTP status.
> Since the code allocates an array whose length is a 32-bit int taken from an
> unverified source, it would be best to somehow handle the case that a random
> large number is read and an OOME is thrown - perhaps rethrowing as an
> {{IOException}}.
> MINDEXER-20 should prevent the bug precondition from being triggered nearly
> as often, but the input could randomly happen to begin with 0x01.
--
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: (MINDEXER-30) IndexPublisher does not protect "read consistency" over published context
[
http://jira.codehaus.org/browse/MINDEXER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-30.
---
Resolution: Fixed
Fixed
> IndexPublisher does not protect "read consistency" over published context
> -
>
> Key: MINDEXER-30
> URL: http://jira.codehaus.org/browse/MINDEXER-30
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.0
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 4.1.1
>
>
> IndexPublisher does not protect "read consistency" over published context.
> This affects only contexts that are the new MergedIndexingContext. These --
> newly introduced context types in 4.1.0 -- are simply "logical merged view"
> of other IndexingContexts. When some change -- and async commit -- happens in
> some of the member contexts, a Lucene exception is thrown preventing proper
> publishing of the context.
> Typical top lines of these stack traces:
> {noformat}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed
> at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:177)
> at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:942)
> at org.apache.lucene.index.DirectoryReader.document(DirectoryReader.java:533)
> at org.apache.lucene.index.MultiReader.document(MultiReader.java:251)
> at org.apache.lucene.index.IndexReader.document(IndexReader.java:658)
> at
> org.apache.maven.index.incremental.DefaultIncrementalHandler.getIndexChunk(DefaultIncrementalHandler.java:154)
> at
> org.apache.maven.index.incremental.DefaultIncrementalHandler.getIncrementalUpdates(DefaultIncrementalHandler.java:65)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.packIndex(DefaultIndexPacker.java:117)
> {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: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
[
http://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269834#action_269834
]
Brian Demers commented on SUREFIRE-446:
---
I applied the previous patch.
> Surefire fails to capture TestNG results when forkMode=always
> -
>
> Key: SUREFIRE-446
> URL: http://jira.codehaus.org/browse/SUREFIRE-446
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4
> Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Fix For: Backlog
>
> Attachments: testng-fork-mode-it.patch
>
>
> The interplay between {{surefire.Surefire}} and
> {{testng.TestNGDirectoryTestSuite}} does not properly notify the
> ReportManager such that it reports 0 executed tests after the end of the day.
> IT to reproduce attached.
> Also confirmed against 2.5-SNAPSHOT.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-622) Maven thinks it can find Mercurial when it can't
Maven thinks it can find Mercurial when it can't Key: SCM-622 URL: http://jira.codehaus.org/browse/SCM-622 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Environment: Maven 2.2.1, Java 1.6.0_24, Mac OSX 10.6.7 Reporter: Daniel Serodio When I run Maven from within Eclipse, /usr/local/bin is not on the PATH so it can't find my Mercurial installation. The build fails, as expected, but Maven thinks that it did find Mercurial: 6/8/11 6:34:09 PM BRT: [INFO] EXECUTING: /bin/sh -c cd /Users/dserodio/Projetos/busca_web && hg id -i 6/8/11 6:34:10 PM BRT: [ERROR] EXECUTION FAILED Execution of cmd : id failed with exit code: 127. Working directory was: /Users/dserodio/Projetos/busca_web Your Hg installation seems to be valid and complete. Hg version: NA (OK) -- 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-622) Maven thinks it can find Mercurial when it can't
[ http://jira.codehaus.org/browse/SCM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269847#action_269847 ] Daniel Serodio commented on SCM-622: Sorry, forgot to select version 1.5 of the plugin when filing this bug. > Maven thinks it can find Mercurial when it can't > > > Key: SCM-622 > URL: http://jira.codehaus.org/browse/SCM-622 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) > Environment: Maven 2.2.1, Java 1.6.0_24, Mac OSX 10.6.7 >Reporter: Daniel Serodio > > When I run Maven from within Eclipse, /usr/local/bin is not on the PATH so it > can't find my Mercurial installation. The build fails, as expected, but Maven > thinks that it did find Mercurial: > 6/8/11 6:34:09 PM BRT: [INFO] EXECUTING: /bin/sh -c cd > /Users/dserodio/Projetos/busca_web && hg id -i > 6/8/11 6:34:10 PM BRT: [ERROR] > EXECUTION FAILED > Execution of cmd : id failed with exit code: 127. > Working directory was: > /Users/dserodio/Projetos/busca_web > Your Hg installation seems to be valid and complete. > Hg version: NA (OK) -- 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: (WAGON-335) Tests fail with 'Address already in use' when building Wagon in parallel mode
Tests fail with 'Address already in use' when building Wagon in parallel mode - Key: WAGON-335 URL: http://jira.codehaus.org/browse/WAGON-335 Project: Maven Wagon Issue Type: Bug Affects Versions: 2.0 Reporter: Mark Struberg Building Wagon with -T8 leads to a 'Address already in use' Exception in a few tests. This situation has worsened after activating the TCKs. I'll change all tests to use a different port number for the tests of each wagon submodule. -- 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: (WAGON-335) Tests fail with 'Address already in use' when building Wagon in parallel mode
[ http://jira.codehaus.org/browse/WAGON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed WAGON-335. --- Resolution: Fixed Fix Version/s: 2.0 Assignee: Mark Struberg tests now succeeds even with mvn clean install -T8 > Tests fail with 'Address already in use' when building Wagon in parallel mode > - > > Key: WAGON-335 > URL: http://jira.codehaus.org/browse/WAGON-335 > Project: Maven Wagon > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 2.0 > > > Building Wagon with -T8 leads to a 'Address already in use' Exception in a > few tests. This situation has worsened after activating the TCKs. I'll change > all tests to use a different port number for the tests of each wagon > submodule. -- 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: (MJAR-140) Performance degredation
[
http://jira.codehaus.org/browse/MJAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269849#action_269849
]
Kristian Rosenvold commented on MJAR-140:
-
It would seem to me like this degradation occured when plexus-archiver switched
to using PlexusIoProxyResourceCollection which possibly retrieves quite a lot
of information we dont use. Especially on Linux this can be bad since plexus-io
still uses forks to determine file attributes, which I am still not sure if we
use/need.
> Performance degredation
>
>
> Key: MJAR-140
> URL: http://jira.codehaus.org/browse/MJAR-140
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.3.1
>Reporter: Eran Harel
>
> I migrated maven to version 3.0.1 in order to utilize the parallel build
> experimental feature.
> As a result I get the following warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in DataBuilder:
> [WARNING] org.apache.maven.plugins:maven-eclipse-plugin:2.8
> [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
> [WARNING] *
> {code}
> I upgraded the maven-jar-plugin to the latest version (2.3.1), and the
> message is gone, but now the builds take much longer: minutes added!!!
> The build takes about x 1.5 longer now.
> I also compared the maven 3 parallel build time with the new jar-plugin VS a
> serial build with the old 2.2 plugin version I had. The results are that
> same, while when using the parallel build with the 2.2 plugin I see a
> significant ~30% performance boost.
--
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: (MJAR-140) Performance degredation
[
http://jira.codehaus.org/browse/MJAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269849#action_269849
]
Kristian Rosenvold edited comment on MJAR-140 at 6/8/11 5:21 PM:
-
It would seem to me like this degradation occured when plexus-archiver switched
to using PlexusIoProxyResourceCollection
(0c17e83ae31786fd96f24d7ed5484e0e5df99a47) which possibly retrieves quite a lot
of information we dont use. Especially on Linux this can be bad since plexus-io
still uses forks to determine file attributes, which I am still not sure if we
use/need.
was (Author: krosenvold):
It would seem to me like this degradation occured when plexus-archiver
switched to using PlexusIoProxyResourceCollection which possibly retrieves
quite a lot of information we dont use. Especially on Linux this can be bad
since plexus-io still uses forks to determine file attributes, which I am still
not sure if we use/need.
> Performance degredation
>
>
> Key: MJAR-140
> URL: http://jira.codehaus.org/browse/MJAR-140
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.3.1
>Reporter: Eran Harel
>
> I migrated maven to version 3.0.1 in order to utilize the parallel build
> experimental feature.
> As a result I get the following warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in DataBuilder:
> [WARNING] org.apache.maven.plugins:maven-eclipse-plugin:2.8
> [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
> [WARNING] *
> {code}
> I upgraded the maven-jar-plugin to the latest version (2.3.1), and the
> message is gone, but now the builds take much longer: minutes added!!!
> The build takes about x 1.5 longer now.
> I also compared the maven 3 parallel build time with the new jar-plugin VS a
> serial build with the old 2.2 plugin version I had. The results are that
> same, while when using the parallel build with the 2.2 plugin I see a
> significant ~30% performance boost.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-335) Tests fail with 'Address already in use' when building Wagon in parallel mode
[ http://jira.codehaus.org/browse/WAGON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269851#action_269851 ] Mark Struberg commented on WAGON-335: - fixed in svn commit: r1133584 > Tests fail with 'Address already in use' when building Wagon in parallel mode > - > > Key: WAGON-335 > URL: http://jira.codehaus.org/browse/WAGON-335 > Project: Maven Wagon > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 2.0 > > > Building Wagon with -T8 leads to a 'Address already in use' Exception in a > few tests. This situation has worsened after activating the TCKs. I'll change > all tests to use a different port number for the tests of each wagon > submodule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5115) Repository deprecation: When a mvn build uses a maven repository that is marked deprecated in the maven repository metadata, it should show a warning.
Repository deprecation: When a mvn build uses a maven repository that is marked
deprecated in the maven repository metadata, it should show a warning.
--
Key: MNG-5115
URL: http://jira.codehaus.org/browse/MNG-5115
Project: Maven 2 & 3
Issue Type: New Feature
Components: Artifacts and Repositories
Affects Versions: 3.0.3
Reporter: Geoffrey De Smet
The old garbage JBoss repository is still used in many recent pom's (directly
or indirectly through dependencies).
To be able to battle it's use, a repository should be able to be marked as
deprecated.
Then when running a mvn build that somehow uses such a deprecated repository,
we should see something like this:
{code}
$ mvn clean install
[WARNING] You are using a deprecated repository
(http://deprecatedrepo.org/maven2/)
which was added in the pom of dependency org.foo:bar:1.0 ->
jdom:jdom:0.1 -> log4j:log4j:0.7
{code}
Note that it clearly shows the dependency graph path to the dependency pom that
included that bad repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
