asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Maxon <>
Subject Re: Merging of AsterixDB and Hyracks repositories
Date Fri, 08 May 2015 20:58:12 GMT
Releasing would be the same, probably simpler actually. I suppose I haven't
tried it so I can't be totally certain, but performing 'mvn release' in a
module directly doesn't do anything different than when it is run from a
higher-up pom as a submodule. Nothing would change if a user is dependent
on a stable version of Hyracks, because they only ever see binary artifacts
from Maven. 'hyracks' will still be called 'hyracks' and have the same
coordinates in Maven.

- Ian

On Fri, May 8, 2015 at 1:47 PM, Till Westmann <> wrote:

> Hmm, and what do we do about the other dependents of Hyracks (e.g.
> VXQuery)?
> We had separate releases of Hyracks for those in the past.
> How would releases (branching, tagging ...) work in that case?
> Cheers,
> Till
> On 8 May 2015, at 13:17, Ian Maxon wrote:
> > Hi all,
> > An idea was brought up today in the meeting (I believe by Yingyi) for
> > solving the issues we have right now with maven project
> interdependencies.
> > The idea is to just merge AsterixDB and Hyracks into one git repository,
> > and to have them as separate maven projects with a top level pom joining
> > them. We actually have part of this implemented already (in the tlp/
> folder
> > a pom.xml exists for this). Doing this change would eliminate the
> necessity
> > of the topic field hack in Gerrit, as well as ensure changes in Hyracks
> > don't break AsterixDB.
> >
> > I went ahead and made a branch that has this change implemented, please
> > take a look at
> >
> > to get an idea of what's proposed. I merged the Hyracks repository into a
> > subtree of the asterix repository- so all of the commit history is merged
> > properly. I think we would want to not commit this change through Gerrit,
> > because if we did all of the Hyracks commit history would not be
> included,
> > which would be unfortunate.
> >
> > - Ian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message