0.90.7 to 0.90.9 : new dependencies


(gabriel.landais) #1

Hi,
before updating our project, I checked the new dependencies and found
that org.antlr:antlr-runtime:jar:3.5, org.ow2.asm:asm:jar:4.1
and org.ow2.asm:asm-commons:jar:4.1 have been added to this release.

I'm a bit surprised that these new libraries are not in the release notes.
I've seen some mails already about asm version conflict, but sure it will
happen again and again.

Also, as we have to use the full library to access ES (Jest is not an
alternative), I had a nice time resolving classpath conflicts. Maven shade
plugin was helpful, even if renaming classes used in services need some
hacks.

So two questions :

  • is a pure Java API is on the roadmap?
  • wouldn't be a great idea to provide a classpath safe version of ES, all
    classes inside a org.elasticsearch root package?

Thanks
Gabriel

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/44275fc3-bd0e-49ce-ba3b-75c567b8fedf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Jörg Prante) #2

The asm issue should also be forwarded to the Lucene team. The new ES
dependency lucene-suggest 4.6 includes asm (and antlr) dependency in the
Lucene pom, which might not be the way it should be.

asm is also used as a shaded dependency in mvel, which is the native script
language of ES right now, and mvel is broken under Java 8 build, so this
issue will not disappear for a while.

I wonder why the Lucene features are not delegated into separate ES plugins
any more, so anyone who wants it can extend ES, while the ES core keeps a
relatively small dependency tree.

For example, like the ICU plugin, ES never included lucene-icu into the
core (but, you know, lucene-icu is vital for me, and lucene-suggest is not).

If you are interested in building ES from source, you might exclude the
lucene-suggest asm dependency in the pom, that is the only method right now
I can think of. Also, it is up to a rebuild from source to extend the Maven
shade plugin to really shade all ES dependencies. If the code will still
work then - there may be subtle issues, e.g. class loader, hard coded class
names, resource names etc.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFCY4hT_fuLJO_2yHty%3D59Tf8oH0mYp2OoDejOsAjbzaA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Nik Everett) #3

From my perspective plugins are more of a pain then a feature:

Compared to installing the deb, plugins are very difficult to work with
especially when you are paranoid and won't use the installer. Now you have
to build a whole new way to install just this one piece of infrastructure.
And many of the plugins need to version in lock step with EP which means
that we have to coordinate two different installation/upgrade mechanisms.
It would be so much easier for us if everything was right in the core or
had its own deb.

Plugins must be tested on their own. If I make some change in
Elasticsearch I can't really be sure I'm not breaking plugins.

I don't use the Java API and wouldn't even if I were writing in Java
because the rest API has fewer backwards compatibility issues.

Nik

On Fri, Jan 3, 2014 at 7:21 AM, joergprante@gmail.com <joergprante@gmail.com

wrote:

The asm issue should also be forwarded to the Lucene team. The new ES
dependency lucene-suggest 4.6 includes asm (and antlr) dependency in the
Lucene pom, which might not be the way it should be.

asm is also used as a shaded dependency in mvel, which is the native
script language of ES right now, and mvel is broken under Java 8 build, so
this issue will not disappear for a while.

I wonder why the Lucene features are not delegated into separate ES
plugins any more, so anyone who wants it can extend ES, while the ES core
keeps a relatively small dependency tree.

For example, like the ICU plugin, ES never included lucene-icu into the
core (but, you know, lucene-icu is vital for me, and lucene-suggest is not).

If you are interested in building ES from source, you might exclude the
lucene-suggest asm dependency in the pom, that is the only method right now
I can think of. Also, it is up to a rebuild from source to extend the Maven
shade plugin to really shade all ES dependencies. If the code will still
work then - there may be subtle issues, e.g. class loader, hard coded class
names, resource names etc.

Jörg

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFCY4hT_fuLJO_2yHty%3D59Tf8oH0mYp2OoDejOsAjbzaA%40mail.gmail.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd3bkog-Ftqmr7Ej-cf89OXVBumC7ErmvDgTgjMLWraJuw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Jörg Prante) #4

That's why I started a while ago a modularization effort, to get rid of
zip-based plugins (at least the JVM based ones) and move over to Maven
dependencies as a method for including plugins online and resolving their
dependencies from remote repos. Each plugin would be versioned and loaded
by a separate classloader, so they can't break or conflict any more, also
not their dependencies (just like a war in a webapp container). Integration
testing would be a breeze in such an environment, just a mvn command.

Jörg

On Fri, Jan 3, 2014 at 3:42 PM, Nikolas Everett nik9000@gmail.com wrote:

Plugins must be tested on their own. If I make some change in
Elasticsearch I can't really be sure I'm not breaking plugins.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGt%3DEi8HmPngSjPHfR%2BeFwaV44UvGRzVpxe%3DpYaiVH6eQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #5