[prev in list] [next in list] [prev in thread] [next in thread]
List: solr-dev
Subject: Re: Heads up: module system integration
From: Dawid Weiss <dawid.weiss () gmail ! com>
Date: 2022-01-04 15:18:06
Message-ID: CAM21Rt90z3X5MGeCPH_YXLa1nHczoLYQMt0P++cjYc6M8J0fOw () mail ! gmail ! com
[Download RAW message or body]
I made a quick summary of the state of the module system support here.
https://issues.apache.org/jira/browse/LUCENE-10328?focusedCommentId=17468676&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17468676
I plan to un-draft the PR and commit it back to main as it currently is.
Dawid
On Thu, Dec 16, 2021 at 6:32 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> Hello,
>
> So... I've been fiddling with the module system together with Uwe,
> Tomoko and Chris. Here's a somewhat cleaned-up view of how the module
> system can be added to Lucene.
>
> https://github.com/apache/lucene/pull/533
>
> This is under LUCENE-10255. In short, some things do change:
>
> - note non-convention configurations in gradle (prefixed with
> 'module') - these are there specifically to distinguish modular from
> classpath dependencies. This helps enormously with setting up module
> path for various tasks (ECJ, javac, runtime configurations for tests).
>
> - there is some intentional duplication between gradle dependencies
> and module requirements, services in META-INF and inside the module
> descriptor. Whether these can be or should be automatically generated
> from one another is a larger question. The consistency of services and
> exposed packages is currently verified by an automatic test.
> Dependencies are not yet cross-checked (and it may be impossible to do
> so, in general).
>
> - I tried to verify that Eclipse and IntelliJ work fine but there may be
> quirks.
>
> - this patch does not try to change the API but, eventually, this will
> have to follow. The modular linter already complains about, for
> example, package-private classes being used as input/output types in
> the public API (this check had to be disabled).
>
> If there are no objections I'd like to merge this patch in. Please do
> review the diffs, experiment with your workflows and see if everything
> works for you.
>
> Dawid
>
[Attachment #3 (text/html)]
<div dir="ltr"><br><div>I made a quick summary of the state of the module system \
support here.</div><div><br></div><div><a \
href="https://issues.apache.org/jira/browse/LUCENE-10328?focusedCommentId=17468676& \
;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17468 \
676">https://issues.apache.org/jira/browse/LUCENE-10328?focusedCommentId=17468676& \
page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17468676</a><br></div><div><br></div><div>I \
plan to un-draft the PR and commit it back to main as it currently is. \
</div><div><br></div><div>Dawid</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Thu, Dec 16, 2021 at 6:32 PM Dawid Weiss <<a \
href="mailto:dawid.weiss@gmail.com">dawid.weiss@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br> <br>
So... I've been fiddling with the module system together with Uwe,<br>
Tomoko and Chris. Here's a somewhat cleaned-up view of how the module<br>
system can be added to Lucene.<br>
<br>
<a href="https://github.com/apache/lucene/pull/533" rel="noreferrer" \
target="_blank">https://github.com/apache/lucene/pull/533</a><br> <br>
This is under LUCENE-10255. In short, some things do change:<br>
<br>
- note non-convention configurations in gradle (prefixed with<br>
'module') - these are there specifically to distinguish modular from<br>
classpath dependencies. This helps enormously with setting up module<br>
path for various tasks (ECJ, javac, runtime configurations for tests).<br>
<br>
- there is some intentional duplication between gradle dependencies<br>
and module requirements, services in META-INF and inside the module<br>
descriptor. Whether these can be or should be automatically generated<br>
from one another is a larger question. The consistency of services and<br>
exposed packages is currently verified by an automatic test.<br>
Dependencies are not yet cross-checked (and it may be impossible to do<br>
so, in general).<br>
<br>
- I tried to verify that Eclipse and IntelliJ work fine but there may be quirks.<br>
<br>
- this patch does not try to change the API but, eventually, this will<br>
have to follow. The modular linter already complains about, for<br>
example, package-private classes being used as input/output types in<br>
the public API (this check had to be disabled).<br>
<br>
If there are no objections I'd like to merge this patch in. Please do<br>
review the diffs, experiment with your workflows and see if everything<br>
works for you.<br>
<br>
Dawid<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic