
Microsoft Open-Sources Team Explorer Everywhere Eclipse Plugin - dstaheli
https://blogs.msdn.microsoft.com/visualstudioalm/2016/03/08/microsoft-open-sources-the-team-explorer-everywhere-eclipse-plugin-for-visual-studio-team-services-and-team-foundation-server/
======
dogma1138
.Net core, mssql on Linux, tfs support for eclipse all we now need is Steve
Balmmer in a Wario costume to officially christen bizzaro Microsoft.

~~~
arca_vorago
Embrace, extend, extinguish is not new for MS, they have just upped the first
parts in prep for the third. How people are so blind to this I dont know...
Windows 10 is a perfect example of MS true goals.

~~~
mikescandy
that was quick.

~~~
ocdtrekkie
It's amazing how many HN members haven't left the 1990s.

~~~
arca_vorago
For good reason. The battle for FOSS with the emphasis on F for Free (beer and
speech) is still a very real one that will affect the future of technology as
we know it. What amazes me is how much of hn has left that part of the 90s...

~~~
ocdtrekkie
Which is why it's so important we embrace companies choosing to release FOSS.
In order for the corporate world to push FOSS, they have to see that they're
successful when they do it, and that it's possible for them to run businesses
while contributing to and releasing their own work as FOSS.

------
oldmanhorton
As someone who has never done meaningful Java development, I always find the
project structure of Java codebases indecipherable. Why are there so many
folders? I understand that namespaces depend on directory path, but it just
seems like there is so much "stuff" here that I would have no idea where to
even begin looking for an entry point or useful code snippet.

~~~
jcdavis
Almost all Java dev is done via full-featured IDEs which support advanced
searching/finding, so simple file stucture isn't really considered a big
priority.

Additionally, here they seem to have structured thing as a bunch of smaller
projects, which seems pretty overkill but I'm not too familiar with it.

~~~
sterwill
One reason there are so many sub-projects is that TEE has many build outputs:
Eclipse plug-ins, a stand-alone application (I think this was removed), a
command-line client with no graphical dependencies. These different products
are built with different processes; Eclipse drives the Java compiler to build
Eclipse plug-ins, but the command-line client is just Maven and javac, etc.

There's also some machine-generated code. TEE web service client classes are
generated from TFS WSDL. That got stuck in its own project so the commit
history was cleaner.

Being a large-ish, old-ish project that has proprietary roots, there are also
a lot of compatibility and portability layers that a modern open source
project could probably shed or replace with external dependencies.

Excuse me if I'm misremembering some details, it's been about 4 years since I
worked on TEE.

------
Nemcue
Oh great, now everyone can enjoy the immense horribleness of TFS.

