If it's a runtime dependency, you are fine. Apache only supports source releases. We vote on source tar ball and not binary artifacts.
Makes sense? Sent from my iPhone, Venkatesh > On Oct 6, 2016, at 12:40 PM, David Lotts <[email protected]> wrote: > > Yes, geotools is a runtime dependency. No geotools source code is > distributed. > > By that I mean: Geotools source code is not in our source code repository. > Only references: imports in our *.java files and dependencies entries in > our pom.xml. Because of this maven will package geotools JARs (binaries) > in our shaded/uber JAR and WAR files that we distribute. > > With option 1 or 2 as discussed, maven will exclude the geotools jars in > our JARs and WARs. Users of Rya can follow some instructions that we > provide to add "-P indexing" (or similar) to their Maven build command > create their own jar/war containing the optional Rya features and geotools > binaries. > > Your "you should be okay." mean which of these???? > A. option 1 and option 2 will work around the issue and we should proceed > before we release, > - OR - > B. We are already in compliance and this is not a blocker for release as > long as we are not redistributing geotools source code. > > Hopeful for interpretation B, but expecting and happy with A. > > david. > > On Thu, Oct 6, 2016 at 1:22 PM, Seetharam Venkatesh <[email protected]> > wrote: > >> Quick question - geotools is a runtime dependency? Are you shipping the >> source code? If not, you should be okay. >> >> Sent from my iPhone, >> Venkatesh >> >>> On Oct 6, 2016, at 7:52 AM, Puja Valiyil <[email protected]> wrote: >>> >>> Hi everyone, >>> Talking with Aaron, it seems like there were two paths forward for >>> refactoring in order to create a release. To refresh everyone's memory, >>> the issue was that the geo-indexing extensions to Rya pull in geotools, >>> which prohibits us from releasing Rya under an Apache 2 license. There >> may >>> be some more particulars that I'm glossing over -- someone please chime >> in >>> if they feel it is key to the discussion. >>> The two paths forward we had were: >>> 1. Make all of the indexing project and its downstream dependencies >>> optional and exclude them from a release >>> -- The indexing project includes several "optional" extensions to Rya >>> (advanced indexing strategies). Prior to Rya becoming an apache project, >>> these indexing extensions were optional and there was a separate profile >>> for including them. This option involves reverting back to that mindset. >>> The main argument against this is that these indexing >> strategies/extensions >>> are not in fact optional but are "core" to Rya and can't be excluded. >>> >>> 2. Refactor Rya to pull geoindexing into a separate project and exclude >>> that project from the release. >>> - We could refactor Rya to have geoindexing be its own project and add a >>> profile to include that in the build. This would invovle moving the >> class >>> mvm.rya.indexing.GeoIndexer and packages mem.rya.indexing.accumulo.geo >> and >>> mvm.rya.indexing.mongodb.geo to a separate project and then >> removing/moving >>> references to geoindexing anywhere else. Another option is to refactor >> the >>> GeoIndexer interface to remove the geotools dependency. >>> >>> I think #1 is a good immediate path for a release and that #2 is a good >>> longer term path forward. Since it's probably in our best interests as a >>> community to get an apache release sooner rather than later, I'd rather >> us >>> go with #1 since it would quicker. I also think that most users of Rya >>> would be ok with excluding the indexing project since it is not core >>> functionality for Rya. While #2 is a better long term plan, it involves >>> some pretty extensive refactoring that would be difficult to do well in a >>> timely manner. >>> >>> Any thoughts? >>
