Apache
/
druid
mirror of https://github.com/apache/druid.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
druid/cassandra-storage/pom.xml

73 lines
2.6 KiB
XML
Raw Normal View History

Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Druid - a distributed column store.
~ Copyright (C) 2012, 2013 Metamarkets Group Inc.
~
~ This program is free software; you can redistribute it and/or
~ modify it under the terms of the GNU General Public License
~ as published by the Free Software Foundation; either version 2
~ of the License, or (at your option) any later version.
~
~ This program is distributed in the hope that it will be useful,
~ but WITHOUT ANY WARRANTY; without even the implied warranty of
~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
~ GNU General Public License for more details.
~
~ You should have received a copy of the GNU General Public License
~ along with this program; if not, write to the Free Software
~ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
fix bug and make it actually possible to load extensions
2013-10-16 14:59:01 -04:00
<groupId>io.druid.extensions</groupId>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
<artifactId>druid-cassandra-storage</artifactId>
<name>druid-cassandra-storage</name>
<description>druid-cassandra-storage</description>
<parent>
port docs over to 0.6 and a bunch of misc fixes
2013-10-11 21:38:53 -04:00
<groupId>io.druid</groupId>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
<artifactId>druid</artifactId>
[maven-release-plugin] prepare release druid-0.6.33
2013-12-12 21:53:14 -05:00
<version>0.6.33</version>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
</parent>
<dependencies>
<dependency>
Fix HadoopDruidIndexer to work with the new way of things There are multiple and sundry changes in here. First, "HadoopDruidIndexer" has been split into two pieces, (1) CliHadoop which pulls the hadoop version and builds up the right classpath with the proper hadoop version to run the indexer and (2) CliInternalHadoopIndexer which actually runs the indexer. In order to work around a bunch of jets3t version conflicts with Hadoop and Druid, I needed to extract the S3 deep storage stuff into its own module. I then also moved the HDFS stuff into its own module so that I could eliminate the dependency on Hadoop for druid-server. In doing these changes, I wanted to make the extensions buildable with only the druid-api jar, so a few other things had to move out of Druid and into druid-api. They are all API-level things, however, so they really belong in druid-api instead. Lastly, I removed the druid-realtime module and put it all in druid-server.
2013-10-09 16:15:41 -04:00
<groupId>io.druid</groupId>
<artifactId>druid-api</artifactId>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
</dependency>
<dependency>
<groupId>com.netflix.astyanax</groupId>
<artifactId>astyanax</artifactId>
<version>1.0.1</version>
</dependency>
Fix HadoopDruidIndexer to work with the new way of things There are multiple and sundry changes in here. First, "HadoopDruidIndexer" has been split into two pieces, (1) CliHadoop which pulls the hadoop version and builds up the right classpath with the proper hadoop version to run the indexer and (2) CliInternalHadoopIndexer which actually runs the indexer. In order to work around a bunch of jets3t version conflicts with Hadoop and Druid, I needed to extract the S3 deep storage stuff into its own module. I then also moved the HDFS stuff into its own module so that I could eliminate the dependency on Hadoop for druid-server. In doing these changes, I wanted to make the extensions buildable with only the druid-api jar, so a few other things had to move out of Druid and into druid-api. They are all API-level things, however, so they really belong in druid-api instead. Lastly, I removed the druid-realtime module and put it all in druid-server.
2013-10-09 16:15:41 -04:00
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
<!-- Tests -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Merge relevant changes from 'druid-version-info'
2013-12-03 23:51:19 -05:00
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
Fix issues with bindings and handling extensions The way the Guice bindings were setup previously, each process only had bindings for the things it cared about. This became problematic when adding extension modules that bound everything that they could possibly need expecting that the processes would only instantiate what they actually do need. Guice tries to fail-fast and verifies that all bindings exist before it does anything, which is a problem because the extension bind some objects that don't necessarily have all of their dependencies bound in all processes. The fix for this is to build a single Injector with all bindings in it and let each of the processes only load the things that they care about. This also requires the use of Module overrides and other such interesting things, which are node done. In doing the fix, I also swapped out the way that the DataSegmentPusher/Puller stuff is bound, as well as made the Cassandra stuff fail if its settings are not provided. This all of a sudden made all of the things require Cassandra's settings, so I migrated the Cassandra deep storage stuff into its own module. In doing these changes, I also discovered that some properties weren't properly converting for the ConvertProperties command (specifically, the properties related to data segment loading and pushing), so I fixed that.
2013-09-20 18:45:01 -04:00
</project>