I should add that if the 1.x stuff is available somewhere now, we should just link to it.
I can't find it in the Maven repository, but perhaps I just don't know where to look. A link to the proper point in the SVN history might suffice on the source. I'm not trying to make more work for us, I'd just like to be nice to our future users... :) On Tue, Feb 26, 2013 at 11:31 PM, Bob Kerns <[email protected]> wrote: > This makes a certain amount of sense, but I'm concerned about current 1.x > users. How are they supposed to get the tools? > > Can we capture somehow what they would have gotten before the split, and > make it conveniently available? To the extent possible, I'd rather this be > more like "hosting the prior release" than releasing. > > A 1.x branch and tag would be good as well (if we can identify what the > tag should point to, anyway). If there's a need for 1.x work, and 1.x users > willing to do it, it would facilitate that. Or even if they don't > contribute it back to the code base, it gives them a clear starting point. > > But for our main line of development, I think your plan makes sense. I > think our first stake in the ground should tie us to the future, not the > past. > > > On Tue, Feb 26, 2013 at 10:13 PM, Adam Berry <[email protected]> wrote: > >> So with Bob's feature outline, I've been thinking a little more about >> this. >> >> If we want to do a developer focused release, it seems like initially >> targeting the 0.23/2.0 line would make sense, and then add back in the >> support to the 1.x stable line later on as we solidify the initial feature >> set. >> >> So this would just be shifting the current features (hdfs browsing, job >> launching, basic project source support) to support that target. >> >> Thoughts? >> >> Cheers, >> Adam >> >> On Sat, Feb 16, 2013 at 6:41 PM, Mattmann, Chris A (388J) < >> [email protected]> wrote: >> >> > Sounds great, Adam. +1 to releasing early, and often. >> > >> > We have a good opportunity here to release even a developer focused >> > release, and then improve docs with more releases that we do. >> > >> > Cheers, >> > Chris >> > >> > On 2/15/13 7:54 PM, "Adam Berry" <[email protected]> wrote: >> > >> > >On Mon, Feb 11, 2013 at 10:49 PM, Mattmann, Chris A (388J) < >> > >[email protected]> wrote: >> > > >> > >> Hey Adam, >> > >> >> > >> Great work! Do you think it's now time for a first release? Even if >> it's >> > >> not fully functional, and even if it doesn't support everything you >> > >> mention in paragraph #2 below, it will be a great incremental >> milestone. >> > >> >> > >> Thoughts? >> > >> >> > >> Cheers, >> > >> Chris >> > >> >> > >> >> > >> On 2/11/13 8:29 PM, "Adam Berry" <[email protected]> wrote: >> > >> >> > >> >Hey guys, >> > >> > >> > >> >So first, let me say thanks for the patience as I worked on this. >> > >> > >> > >> >I've split up the original single plugin into a few logical units >> as we >> > >> >discussed before. I've thrown up the beginnings of a wiki page, >> > >> >http://wiki.apache.org/hdt/HDTGettingStarted with the beginnings of >> > how >> > >> to >> > >> >grab this and work with it. The maven/tycho build support still >> needs >> > >>to >> > >> >go >> > >> >in, but I should be able to get to that this week. >> > >> > >> > >> >So now we are ready to start attacking multi hadoop version >> support! We >> > >> >need multi version clients for launching jobs on hadoop clusters, >> also >> > >>for >> > >> >interacting with hdfs on the same clusters, those will need the >> > >>connectors >> > >> >that we discussed before. The other spot is in the jars that get >> that >> > >> >added >> > >> >to the classpath for MapReduce projects. >> > >> > >> > >> >Although the plugins are logically split, some of the classes in >> them >> > >>need >> > >> >some more work to better split the work between core and ui, so >> keeping >> > >> >refactoring in mind as would be good I think. For now, the Hadoop >> > >>imports >> > >> >are satisfied using the org.apache.hadoop.eclipse plugin, which >> bundles >> > >> >Hadoop 1.0.4. >> > >> > >> > >> >I've added some JIRAs as trackers for this feature work, so feel >> free >> > >>to >> > >> >jump in to the source and chime in! >> > >> > >> > >> >Cheers, >> > >> >Adam >> > >> >> > >> Hey guys, >> > > >> > >sorry for the delay in responding, I was struck down by the flu. >> > > >> > >So I'm really not sure here, so comments and thoughts are more than >> > >welcome. >> > > >> > >We can probably make the current set of tools work with 1.0 without too >> > >much trouble, but we would also need some tests and documentation >> before >> > >release, not necessarily exhaustive, but at least something. Pursuing a >> > >release quickly would likely help to drive interest and momentum for >> the >> > >tools. >> > > >> > >I think I'm leaning in favor of doing that, gets us used to doing >> apache >> > >releases, and the other pieces of infrastructure, and would let us get >> > >visible within the hadoop community sooner. >> > > >> > >I believe its still important to start work on the multi version >> support >> > >as >> > >soon as possible, but I think we can do that in parallel to the >> release of >> > >some tools that support the 1.0 line. >> > > >> > >So let me know what you guys think, and we'll go from there. >> > > >> > >Cheers, >> > >Adam >> > >> > >> > >
