I was assuming that we would make the change for 0.2.4. :-) Aaron
On Wed, Nov 26, 2014 at 8:20 PM, Tim Williams <[email protected]> wrote: > Cool, I should have asked the first time but I'm wanting to get this > in for 0.2.4 - if you'd rather we wait please say something soon:) > > --tim > > On Wed, Nov 26, 2014 at 12:56 PM, Chris Rohr <[email protected]> wrote: > > I think I like this also. Thanks Tim! > > On Wed, Nov 26, 2014 at 12:07 PM Andrew <[email protected]> wrote: > > > >> This definitely looks like a good solution. This should also get rid of > the > >> maven warning that we always see about using a variable in the version. > >> > >> On Wed, Nov 26, 2014 at 9:51 AM, Aaron McCurry <[email protected]> > wrote: > >> > >> > I like this method better. This is how MRUnit handles the various > >> versions > >> > of Hadoop. > >> > > >> > Aaron > >> > > >> > On Wed, Nov 26, 2014 at 9:35 AM, Tim Williams <[email protected]> > >> > wrote: > >> > > >> > > We currently use profiles to support building to varying versions of > >> > > Hadoop and, inside the profile, we alter the "projectVersion" tag to > >> > > append the profile name. This mostly works, but it leads to > problems > >> > > publishing snaphot artifacts to some maven repos (e.g. artifactory). > >> > > > >> > > I believe the correct way to get the behavior we want is to leave > the > >> > > projectVersion alone and use "classifier" to get the same artifact > >> > > naming behavior. So, in the profile we'd set some classifier > property > >> > > (e.g. <hadoopClassifier>hadoop1</hadoopClassifier>), then in the jar > >> > > plugin refer to the profile's property (e.g. > >> > > <classifier>${hadoopClassifier}</classifier>) which will result in > the > >> > > classifier string being appended to the artifact name. > >> > > > >> > > The side effect of this is that dependencies on blur would need to > >> > > specify the classifier with their dependency. > >> > > > >> > > Thoughts? > >> > > > >> > > --tim > >> > > > >> > > **NOTE: There's a longer-term "fix" for this that involves > introducing > >> > > our own set of interfaces that can be implemented with various > hadoop > >> > > "projects" - which would allow us to get rid of profiles all > together > >> > > and just use dependencies. I'm looking for a quicker solution than > >> > > that right now. > >> > > > >> > > >> >
