[ 
https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229232#comment-14229232
 ] 

Alexandre Rafalovitch commented on SOLR-4792:
---------------------------------------------

bq. I don't understand why this issue exists in absence of the fully baked 
answer.

I understand why this issue exists. If we don't remove *war* file in 5, it will 
be there until 6. Which could be very long time.

But if we remove it in 5, we can fix the rest of the usability issues in 
5.1-5.3. Given that the timing of 5 is driven quite heavily by Lucene 5, it may 
be the best of both worlds.

At the same time, it would make sense to have the consequences/messaging clear. 
So, explicitly not sell Solr 5 to the package managers, etc. Tell them to stay 
with Solr 4 for now. Which sounds fine, but has secondary consequences. 

For example, people are starting to push schemaless Solr (to compete on 
messaging with Elasticsearch I guess). But the schemaless version of Solr in 4 
is not a full solution (e.g. no easy way to create new type definitions). In 5, 
it will be better. So, not pushing people to 5, means also not pushing 
schemaless Solr so much.

P.s. The solr-undertow is not in Java, right? I think I saw a Kotlin reference 
in the docs. I am not sure what the implications of that would be. 


> stop shipping a war in 5.0
> --------------------------
>
>                 Key: SOLR-4792
>                 URL: https://issues.apache.org/jira/browse/SOLR-4792
>             Project: Solr
>          Issue Type: Task
>          Components: Build
>            Reporter: Robert Muir
>            Assignee: Mark Miller
>             Fix For: 5.0, Trunk
>
>         Attachments: SOLR-4792.patch
>
>
> see the vote on the developer list.
> This is the first step: if we stop shipping a war then we are free to do 
> anything we want. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to