On Tue, Feb 26, 2019 at 11:44 AM Vladimir Sitnikov < [email protected]> wrote:
> Philippe> Although I agree with sebb that not touching layout makes it > easier for us to study and work progressively with this migration. > Philippe> I am not sure we should keep layout AS-IS. > > That's false assumption. > There are tons of tools that can compare files and ignore file movements. > > For instance: > 1) Navigate to https://github.com/apache/jmeter/pull/448/files > 2) Open "javascript development console" (e.g. in Chrome) > 3) Type the following and press enter: $$('div.empty').forEach(function(e) > { e.parentElement.parentElement.style.display='none'; }) > Ok, still kind of hack no :-) ? > > Voilà! You see just the source diff, and all the renames are hidden. > > In the same way, `git -M ` in console can ignore "rename only" changes. > ok , better > So, do you have *technical* reasons for keeping the layout? > No > Philippe>What would we loose or have to do additionally if we don't touch > it as least in first migration step > > We will lose MY time, and we will get NOTHING out of it. > I understand this. > As I said above, source comparison is trivial (e.g. even GitHub UI works > for that) > Source layout has nothing to do with comparison of binary artifacts by the > way. > Yes But I guess the ideal situation was to have gradle build being worked on while being able to continue working on other features. If we do this move, we need to do it once, if at some step we have issues migrating a remaining Ant task to Gradle equivalent (built-in or scripted) , that might block a release: - Either we have to fix the gradle build - and if blocked change the Ant build But I understand your point, and it is an acceptable risk. Just to reduce the risk, and if you won't have further time, could you give a hint on your advised ways of migrating remaining Ant tasks that are not covered by POC ? Thanks for your contribution and help ! > Vladimir > > -- Cordialement. Philippe Mouawad.
