[jira] [Updated] (LUCENE-3990) TestRandomChains failure
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3990: Attachment: analysis-common.tests-report.txt > TestRandomChains failure > > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe > Attachments: analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >>at > org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3983) HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
[
https://issues.apache.org/jira/browse/LUCENE-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3983:
Priority: Minor (was: Major)
> HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
> --
>
> Key: LUCENE-3983
> URL: https://issues.apache.org/jira/browse/LUCENE-3983
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Steven Rowe
>Priority: Minor
>
> Is this expected?
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(), value);
> }
> }
> {code}
> In my opinion, this should look like:
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(Locale.ENGLISH), value);
> }
> }
> {code}
> (otherwise in the Turkish locale, the entities containing "i" (like "xi" ->
> '\u03BE') will not be detected correctly).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3948) Experiment with placing poms outside of src
[
https://issues.apache.org/jira/browse/LUCENE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3948:
Attachment: LUCENE-3948.patch
Patch, updated to current trunk, and also:
# regularizes {{module-path}} definitions to always be
{{$\{top-level}}{{\}/$\{module-path}}{{\}}}, where {{top-level}} is a
separately specified property;
# uses {{top-level}} in definitions that would otherwise have multiple
{{../..}} path segments;
# removes definitions for {{project.build.directory}},
{{project.build.outputDirectory}} and {{project.build.testOutputDirectory}},
because these values are now the same as their defaults;
# adds a new {{surefire-top-level}} property based on {{top-level}} -- since
maven-surefire-plugin runs tests with CWD {{/target/test/}}, the path
to access Solr's {{testlogging.properties}} file needs two extra {{../}}'s; and
# adds a new target {{clean-maven-build}} to the top-level {{build.xml}}.
{quote}
TODO
* Connect generate-maven-artifacts to this new process.
{quote}
This isn't necessary, since generate-maven-artifacts now uses a separate target
to filter the POMs for release artifact production: {{filter-pom-templates}};
this target and {{get-maven-poms}} are now independent of each other.
{quote}
* Add mechanism to clean maven-build
{quote}
Done.
{quote}
* Add maven-build as an svn:ignore dir.
* Remove svn:ignore for pom.xml in src directories.
{quote}
These will need to be done.
I think this is ready to commit.
> Experiment with placing poms outside of src
> ---
>
> Key: LUCENE-3948
> URL: https://issues.apache.org/jira/browse/LUCENE-3948
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3948.patch, LUCENE-3948.patch, LUCENE-3948.patch,
> LUCENE-3948.patch
>
>
> Recent work in LUCENE-3944 has changed how our generated pom.xml files are
> handled during release preparation, placing them in build/ instead. However
> get-maven-poms still places the poms inside src/ so you can use them to drive
> a build. What I think would be ideal is if we could unify the release
> handling of the poms and the normal building handling, so that the poms can
> sit outside of src and serve both purposes.
> Some time ago I investigated how the ANT project handles its own Maven
> integration and it has its poms sitting in their own directory. They then
> reference the actual src locations inside the poms. This works for ANT but
> with a warning since some of their tests don't work due to how the Maven
> surefire plugin works, so they skip their tests.
> I have done some quick testing of my own and this process does seem to work
> for our poms and tests. I now want to take this to a full scale POC and see
> if it works fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated SOLR-3344:
--
Attachment: SOLR-3344-runtime-scope.patch
Patch switching Solr test-framework's Jetty dependencies' scope from compile to
runtime. All Solr tests pass. Committing shortly.
> POM dependencies not all there yet for solr-test-framework
> --
>
> Key: SOLR-3344
> URL: https://issues.apache.org/jira/browse/SOLR-3344
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Benson Margulies
>Assignee: Steven Rowe
> Fix For: 4.0
>
> Attachments: 0001-Add-jetty-deps.patch,
> SOLR-3344-runtime-scope.patch, SOLR-3344.patch
>
>
> The pom for solr-test-framework does not mention jetty, so a test case that
> doesn't get jetty into it's classpath otherwise fails with:
> {noformat}
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated SOLR-3344:
--
Attachment: SOLR-3344.patch
Patch, adding 3 required Jetty dependencies to the Solr test-framework POM
template, and removing those dependencies from the dataimporthandler and
clustering POM templates.
Tests all pass for me locally.
Committing shortly.
> POM dependencies not all there yet for solr-test-framework
> --
>
> Key: SOLR-3344
> URL: https://issues.apache.org/jira/browse/SOLR-3344
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Benson Margulies
> Attachments: 0001-Add-jetty-deps.patch, SOLR-3344.patch
>
>
> The pom for solr-test-framework does not mention jetty, so a test case that
> doesn't get jetty into it's classpath otherwise fails with:
> {noformat}
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3963) improve smoketester to work on windows
[
https://issues.apache.org/jira/browse/LUCENE-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3963:
Attachment: LUCENE-3963.patch
Patch making {{smokeTestRelease.py}} work for me on Windows 7 + Cygwin. (This
script will *never* work w/o Cygwin - it assumes Unix tools.)
> improve smoketester to work on windows
> --
>
> Key: LUCENE-3963
> URL: https://issues.apache.org/jira/browse/LUCENE-3963
> Project: Lucene - Java
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-3963.patch
>
>
> After the changes in SOLR-3331, the smoketester won't work on windows
> (things like path separators of : or ;).
> Not really critical, people will just have to smoketest on
> unix-like machines. But it would be more convenient for testers on
> windows machines if it worked there too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3964: Attachment: LUCENE-3964.patch Patch fixing a bug in the naming of the Solr war's POM. After fixing the POM name problem, I successfully staged Solr 3.6.0 RC0 here: [https://repository.apache.org/content/repositories/orgapachelucene-016/]. I think it's ready to commit, but I'll wait until tomorrow to do so. > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch, LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3964) Stage Maven release artifacts
[
https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3964:
Attachment: LUCENE-3964.patch
Trunk patch for a new target {{stage-maven-artifacts}} in
{{lucene/common_build.xml}}, which:
# calls a Perl script in {{dev-tools/scripts/}} to recurse over the Maven dist
directory (specified via property {{maven.dist.dir}}, which has default values
under {{lucene/}} and {{solr/}}) to find Maven artifacts, and then write an Ant
build file (by default {{./build/stage_maven_build.xml}}); and
# invokes the {{stage-maven}} target in the Ant build file produced by the Perl
script to stage each artifact, along with its POM, sources and javadoc jars,
and signatures for each, to the staging repository specified in properties
{{m2.repository.id}} and {{m2.repository.url}}.
Also included in the patch: a shell script to crawl Maven release distribution
artifacts using {{wget}}: {{dev-tools/scripts/crawl.maven.release.dist.sh}}
I have successfully run this target on the Lucene artifacts in Robert's RC0
release candidate, and then "closed" [the resulting staging
repository|https://repository.apache.org/content/repositories/orgapachelucene-014/]
("closing" disallows further uploads to the staging repository, and also does
some quality checks, e.g. valid POMs, valid signatures) using this cmdline:
{noformat}ant clean stage-maven-artifacts -Dmaven.dist.dir=~/temp/lucene
-Dm2.repository.id=apache.releases.https
-Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2{noformat}
The process took a little less than ten minutes.
Although this patch is against trunk, it will work on any version's release, so
I think it won't be necessary to commit it to branch_3x.
Left to do: test against the RC0 Solr artifacts.
> Stage Maven release artifacts
> -
>
> Key: LUCENE-3964
> URL: https://issues.apache.org/jira/browse/LUCENE-3964
> Project: Lucene - Java
> Issue Type: New Feature
> Components: general/build
>Affects Versions: 3.6, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Critical
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3964.patch
>
>
> We need a way to stage Maven artifacts to the Apache release repository.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3959:
Attachment: LUCENE-3959.patch
Patch removing all {{@author}} tags from Lucene/Solr sources.
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Priority: Trivial
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3948) Experiment with placing poms outside of src
[
https://issues.apache.org/jira/browse/LUCENE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3948:
Attachment: LUCENE-3948.patch
Patch, superset of your patch, Chris, fixing just one problem I found: in the
smartcn analysis module's POM, the resource directory didn't have
{{module-path}} in front of it.
> Experiment with placing poms outside of src
> ---
>
> Key: LUCENE-3948
> URL: https://issues.apache.org/jira/browse/LUCENE-3948
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3948.patch, LUCENE-3948.patch
>
>
> Recent work in LUCENE-3944 has changed how our generated pom.xml files are
> handled during release preparation, placing them in build/ instead. However
> get-maven-poms still places the poms inside src/ so you can use them to drive
> a build. What I think would be ideal is if we could unify the release
> handling of the poms and the normal building handling, so that the poms can
> sit outside of src and serve both purposes.
> Some time ago I investigated how the ANT project handles its own Maven
> integration and it has its poms sitting in their own directory. They then
> reference the actual src locations inside the poms. This works for ANT but
> with a warning since some of their tests don't work due to how the Maven
> surefire plugin works, so they skip their tests.
> I have done some quick testing of my own and this process does seem to work
> for our poms and tests. I now want to take this to a full scale POC and see
> if it works fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3948) Experiment with placing poms outside of src
[
https://issues.apache.org/jira/browse/LUCENE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3948:
Comment: was deleted
(was: Hi Chris,
I applied the patch, ran {{ant filter-pom-templates}} under lucene, {{chdir}}'d
to {{lucene/build/poms/}}, and tried the following:
* {{)
> Experiment with placing poms outside of src
> ---
>
> Key: LUCENE-3948
> URL: https://issues.apache.org/jira/browse/LUCENE-3948
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3948.patch
>
>
> Recent work in LUCENE-3944 has changed how our generated pom.xml files are
> handled during release preparation, placing them in build/ instead. However
> get-maven-poms still places the poms inside src/ so you can use them to drive
> a build. What I think would be ideal is if we could unify the release
> handling of the poms and the normal building handling, so that the poms can
> sit outside of src and serve both purposes.
> Some time ago I investigated how the ANT project handles its own Maven
> integration and it has its poms sitting in their own directory. They then
> reference the actual src locations inside the poms. This works for ANT but
> with a warning since some of their tests don't work due to how the Maven
> surefire plugin works, so they skip their tests.
> I have done some quick testing of my own and this process does seem to work
> for our poms and tests. I now want to take this to a full scale POC and see
> if it works fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[ https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3951: Attachment: LUCENE-3951-handle-ivy.default.ivy.user.dir.patch Same patch, with the right issue number in the name this time. > get-maven-poms should depend on ivy resolve, so that non-mavenized jars are > available for use by mvn -P bootstrap install > - > > Key: LUCENE-3951 > URL: https://issues.apache.org/jira/browse/LUCENE-3951 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Affects Versions: 3.6 >Reporter: Steven Rowe >Assignee: Steven Rowe > Fix For: 3.6 > > Attachments: LUCENE-3951-handle-ivy.default.ivy.user.dir.patch, > LUCENE-3951.patch, LUCENE-3951.patch > > > see title -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[ https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3951: Attachment: (was: LUCENE-3944-handle-ivy.default.ivy.user.dir.patch) > get-maven-poms should depend on ivy resolve, so that non-mavenized jars are > available for use by mvn -P bootstrap install > - > > Key: LUCENE-3951 > URL: https://issues.apache.org/jira/browse/LUCENE-3951 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Affects Versions: 3.6 >Reporter: Steven Rowe >Assignee: Steven Rowe > Fix For: 3.6 > > Attachments: LUCENE-3951-handle-ivy.default.ivy.user.dir.patch, > LUCENE-3951.patch, LUCENE-3951.patch > > > see title -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3951:
Attachment: LUCENE-3944-handle-ivy.default.ivy.user.dir.patch
The [nightly Jenkins branch_3x Maven
job|https://builds.apache.org/job/Lucene-Solr-Maven-3.x/448/console] failed
because of {{ivy.default.ivy.user.dir}} sysprop problems (passing through the
non-interpolated reference):
{noformat}
[INFO] An Ant BuildException has occured: The following error occurred while
executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/example/build.xml:39:
java.lang.IllegalArgumentException: ivy.default.ivy.user.dir must be absolute:
${ivy.default.ivy.user.dir}
around Ant part .. @ 4:77 in
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/lucene/build/lucene-solr-grandparent/antrun/build-main.xml{noformat}
This patch fixes the maven-antrun-plugin setup by defining two executions, one
for the case where {{ivy.default.ivy.user.dir}} is set, and another for where
it is not.
Committing shortly.
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6
>
> Attachments: LUCENE-3944-handle-ivy.default.ivy.user.dir.patch,
> LUCENE-3951.patch, LUCENE-3951.patch
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3951:
Attachment: LUCENE-3951.patch
Patch invoking the {{resolve}} target in {{solr/example/build.xml}} via the
maven-antrun-plugin from the {{bootstrap}} profile in the Lucene/Solr
grandfather POM.
The Ivy jar included on the classpath for the maven-antrun-plugin is from the
user's Maven local repository, apparently because maven-antrun-plugin doesn't
look in {{~/.ant/lib/}}:
[http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html].
Works for me locally (from the top-level dir):
* {{ant clean clean-jars get-maven-poms}}
* {{mvn -N -P bootstrap install -Divy.default.ivy.user.dir=...}}
* {{mvn -DskipTests install}}
* {{mvn test}}
Committing shortly.
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6
>
> Attachments: LUCENE-3951.patch, LUCENE-3951.patch
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[ https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3951: Priority: Major (was: Blocker) Summary: get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install (was: dist-maven should depend on ivy resolve, so that maven-ant-tasks jar is available for use by m2-deploy) > get-maven-poms should depend on ivy resolve, so that non-mavenized jars are > available for use by mvn -P bootstrap install > - > > Key: LUCENE-3951 > URL: https://issues.apache.org/jira/browse/LUCENE-3951 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe > Fix For: 3.6, 4.0 > > > see title -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3951) dist-maven should depend on ivy resolve, so that maven-ant-tasks jar is available for use by m2-deploy
[ https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3951: Summary: dist-maven should depend on ivy resolve, so that maven-ant-tasks jar is available for use by m2-deploy (was: generate-maven-artifacts should depend on ivy resolve, so that maven-ant-tasks jar is available for use by m2-deploy) > dist-maven should depend on ivy resolve, so that maven-ant-tasks jar is > available for use by m2-deploy > -- > > Key: LUCENE-3951 > URL: https://issues.apache.org/jira/browse/LUCENE-3951 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Blocker > Fix For: 3.6, 4.0 > > > see title -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3944) ant clean should remove pom.xml's
[
https://issues.apache.org/jira/browse/LUCENE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3944:
Attachment: LUCENE-3944.patch
Final trunk patch. I ran {{ant dist-maven}} on all directories containing a
{{build.xml}} file. (Some failed, but in all cases that was due to not having
a {{dist-maven}} target.)
The changes from the last iteration:
* includes CHANGES entry
* removed full Solr duplicate of {{dist-maven}} (only dependencies were
different from the Lucene version) in favor of new target
{{dist-maven-common}}, which is depended on by both Lucene's and Solr's
{{dist-maven}} targets
* fixed {{dist-maven}} in {{solr/webapp/}} to depend on {{install-maven-tasks}}
* fixed top-level {{generate-maven-artifacts}} so that it functions properly.
Committing to trunk shortly, then backporting to branch_3x.
> ant clean should remove pom.xml's
> -
>
> Key: LUCENE-3944
> URL: https://issues.apache.org/jira/browse/LUCENE-3944
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3944.patch, LUCENE-3944.patch, LUCENE-3944.patch
>
>
> Currently once the pom.xml's are in place, its hard to get them out. Having
> them can be a little trappy when you're trying to debug the bug. We should
> facilitate their removal during clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3944) ant clean should remove pom.xml's
[
https://issues.apache.org/jira/browse/LUCENE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3944:
Attachment: LUCENE-3944.patch
New trunk patch.
Robert pointed out on #lucene IRC that the Ant problem (Solr contrib ignoring
an overridden {{dist-maven}} target definition in {{solr/common-build.xml}})
was as a result of the {{dist-maven}} specialization in
{{solr/contrib/langid}}, which depended on the lucene definition instead of the
overriding solr definition. This is fixed in this version of the patch.
Also fixed in this version of the patch: a typo in the Solr definition of
{{dist-maven}} that prevented it from finding the appropriate POM.
{{ant generate-maven-artifacts}} now works (succeeds anyway and puts the right
stuff in the right place) under {{solr/}}, {{lucene/}}, and {{modules/}}.
I plan on doing more testing before committing, and then backporting to
branch_3x.
> ant clean should remove pom.xml's
> -
>
> Key: LUCENE-3944
> URL: https://issues.apache.org/jira/browse/LUCENE-3944
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3944.patch, LUCENE-3944.patch
>
>
> Currently once the pom.xml's are in place, its hard to get them out. Having
> them can be a little trappy when you're trying to debug the bug. We should
> facilitate their removal during clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3944) ant clean should remove pom.xml's
[
https://issues.apache.org/jira/browse/LUCENE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3944:
Attachment: LUCENE-3944.patch
Patch implementing a new target {{filter-pom-templates}}, which places the POMs
under {{lucene/build/poms/}}. {{dist-maven}} pulls POMs from this location
instead of from each module's source directory. {{generate-maven-artifacts}}
under {{lucene/}} seems to work; I haven't tested much else.
There is an Ant problem, though: I have attempted to override {{dist-maven}} in
{{solr/common-build.xml}}, but it's being ignored in Solr modules, which are
instead using the {{dist-maven}} definition in {{lucene/common-build.xml}}. My
reading of the Ant docs makes me think this may be the intended behavior: only
the running build file's target definitions override those that are imported.
> ant clean should remove pom.xml's
> -
>
> Key: LUCENE-3944
> URL: https://issues.apache.org/jira/browse/LUCENE-3944
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3944.patch
>
>
> Currently once the pom.xml's are in place, its hard to get them out. Having
> them can be a little trappy when you're trying to debug the bug. We should
> facilitate their removal during clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3941:
Affects Version/s: (was: Realtime Branch)
4.0
> Maven Build Broken - Bootstrap fails
>
>
> Key: LUCENE-3941
> URL: https://issues.apache.org/jira/browse/LUCENE-3941
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.0
>Reporter: Tobias Rübner
>Assignee: Steven Rowe
> Fix For: 4.0
>
>
> Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
> because a contributed lib is missing.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
> (install-langdetect) on project lucene-solr-grandparent:
> Error installing artifact 'org.apache.solr:solr-langdetect:jar':
> Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
> /home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
> (No such file or directory) -> [Help 1]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3937) Workaround the XERCES-J bug in Benchmark
[
https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3937:
Attachment: LUCENE-3937-remaining-references.patch
Updated branch_3x patch putting back the xercesImpl mention in
{{lucene/NOTICE.txt}}.
Uwe, I looked at your CHANGES entry, and I think the entry I wrote in benchmark
CHANGES.txt should still be included there. Can you take a look and tell me if
you disagree?
> Workaround the XERCES-J bug in Benchmark
>
>
> Key: LUCENE-3937
> URL: https://issues.apache.org/jira/browse/LUCENE-3937
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3937-remaining-references.patch,
> LUCENE-3937-remaining-references.patch, LUCENE-3937.patch, LUCENE-3937.patch
>
>
> In becnhmark we have a patched version of XERCES which is hard to compile
> from source. When looking at the code part patched and the source of
> EnwikiContentSource, to simply provide the XML parser a Reader instead of
> InputStream, so the broken code is not triggered. This assumes, that the
> XML-file is always UTF-8 If not it will no longer work (because the XML
> parser cannot switch encoding, if it only has a Reader).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3937) Workaround the XERCES-J bug in Benchmark
[ https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3937: Attachment: LUCENE-3937-remaining-references.patch Patch against branch_3x removing remaining references to the patched xercesImpl jar. Also adds benchmark CHANGES entry. Committing shortly, and then forward porting to trunk. > Workaround the XERCES-J bug in Benchmark > > > Key: LUCENE-3937 > URL: https://issues.apache.org/jira/browse/LUCENE-3937 > Project: Lucene - Java > Issue Type: Bug >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Blocker > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3937-remaining-references.patch, > LUCENE-3937.patch, LUCENE-3937.patch > > > In becnhmark we have a patched version of XERCES which is hard to compile > from source. When looking at the code part patched and the source of > EnwikiContentSource, to simply provide the XML parser a Reader instead of > InputStream, so the broken code is not triggered. This assumes, that the > XML-file is always UTF-8 If not it will no longer work (because the XML > parser cannot switch encoding, if it only has a Reader). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3881) Create UAX29URLEmailAnalyzer: a standard analyzer that recognizes URLs and emails
[ https://issues.apache.org/jira/browse/LUCENE-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3881: Attachment: LUCENE-3881.patch Patch implementing the idea. Committing shortly. > Create UAX29URLEmailAnalyzer: a standard analyzer that recognizes URLs and > emails > - > > Key: LUCENE-3881 > URL: https://issues.apache.org/jira/browse/LUCENE-3881 > Project: Lucene - Java > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Minor > Attachments: LUCENE-3881.patch > > > This Analyzer should contain the same components as StandardAnalyzer, except > for the tokenizer, which should be UAX29URLEmailTokenizer instead of > StandardTokenizer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3913) HTMLStripCharFilter produces invalid final offset
[
https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3913:
Attachment: LUCENE-3913.patch
Patch, a superset of Mike's:
* fixes the identified problem: {{}} offset was improperly calculated.
(Added comments describing the offset calculations everywhere they're performed
in the .jflex source.)
* adds a new case emitting {{<\s*(/\s*)?(br|script|style)>?}} to
{{_TestUtil.randomHtmlishString()}}, because , , and