|
| Re: Can you clarify "competes with" [message #531405 is a reply to message #527904] |
Tue, 04 May 2010 18:14   |
 Oisin Hurley
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
I think Henrik wrote a useful short article on some of the differences between the solutions mentioned in the proposal, which all can read at [0]. That might help answer some items that may need clarification, although it's not an exhaustive comparison. We would need a live document that is maintained by all the available experts to make sure that the community can be clear about what the various differences are.
I can only give my 2c on the competition aspect - I would consider it to mean a couple of things:
- there is overlap with these other projects, but there are new approaches being applied that could help evolve the whole area, which is constructive in the medium term
- projects will be actively canvassed and helped to switch from their existing build approach to a Tycho build approach, which IMHO is not constructive as it aspires towards creation of a monoculture
That might work, for a certain value of 'work', but I think a lot of the decision-making on build is based upon individuals particular expertise and/or taste. Developers really want to write code, and build stuff is just an unsatisfactory thing for them to spend a lot of time on - like the chewing gum but without the flavo[u]ring. I had an example of this recently when I was putting out feelers on what people wanted to do for the various SOA TLP builds - turns out some people want Buckminster, some want Tycho and some want Buildr4osgi. It's build soup - and once a build is in place, people can take a lot of convincing to change the status quo, not because of the shiny new tech, but because of the "it works and I know how it works" factor and the lack of appetite for disruptions.
Looking at the Maven relationship, with Buckminster we are at the point where we can consume from/publish to Maven-style repos and Tycho will do the same, so there is overlap there in terms of capabilities. Tycho will build Eclipse things using the manifests, so in that way there is an overlap with what PDE does. Athena is an ease-of-use layer on top of PDE, and as far as I can make out b3 will be a interpretive layer that could pretty much sit on top of any executing builder. Henrik has another short article at [1] with some more info. The polyglot Maven stuff is interesting, but I don't think it comes into this arena as the 'glot' in the Tycho case is the OSGi manifest.
Well, the foregoing has been a very, very light assessment, but I'm thinking that while Tycho might not envelope the Eclipse ecosystem in its entirety, it will have a positive impact on the general wish and desire for OSGi tools in the wider world. b3 has the potential to do the same (IMHO), but it is an pre-early-stage technology and only time will tell how that will come out.
Howabout some Tycho users get on here and tell us what wows them about the Tycho experience?
--oh
[0] http://henrik-eclipse.blogspot.com/2010/04/eclipse-build-sys tems-in-perspective.html
[1] http://henrik-eclipse.blogspot.com/2010/04/eclipse-b3-succes s-at-eclipsecon.html
|
|
|
|
|
| Re: Can you clarify "competes with" [message #547414 is a reply to message #527904] |
Fri, 16 July 2010 16:54 |
Jason van Zyl
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
In your proposal, you say ... "There are existing solutions at Eclipse in the same space at Tycho. Among these solution are Buckminster, B3, PDE Build, and Athena. Tycho will collaborate with these projects on P2 interoperability issues, but aside from that Tycho competes with these projects."
Can you clarify what the difference is between your proposed project, and these others? Is it (only) that you use Maven and they don't?
JVZ: That is certainly a substantial part of the argument. But we also use P2, JDT, and Equinox in a way that provides the only existing hybrid at a fundamental level which integrates these technologies. No one is going to do that better on the Maven side, and we are working closely with Pascal on the P2 side. We also have down-to-the-bare-metal expertise on Equinox and JDT. Tycho was the driver for many in Maven itself which will ultimately yield a version of Maven that runs on OSGi. Another important aspect is the interoperability between the Maven world and the OSGi world. We will have this requirement for quite some time and it's not just integrating repositories of artifacts, it's the integration of the metadata, how this interoperability works in Eclipse, and how this interoperability works in repository managers. Our users want one way to build things regardless of the final output
What I'm looking for is not so much a technical details, but more why someone would pick your project to use (or participate in) vs. the others.
JVZ: We built Tycho for our own purposes, so you would probably want to talk the Jetty, EGit, Memory Analyzer, and Tigerstripe developers as to why they picked Tycho. I'm not sure where Oisin gets his information in that we solicited people to use Tycho. That's entirely erroneous information. All those groups approached us, or were already using Tycho before our first conversations. I think for most of those groups they were using Maven for another build and wanted infrastructural consistency. At least I know that to be the case for Jetty. We haven't converted anyone's builds for them and we're not going to. If we had to do that in order to get people to use Tycho I would consider Tycho an unviable technology.
Also, what's similar? What areas of collaboration would you expect? You say "P2 interoperability" but I don't know what that means.
JVZ: P2 interoperability means making sure the P2 repositories of IUs can be easily used across all of the build technologies. I thinks that's pretty much the case today.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02315 seconds
] 
Search
Help
Register
Login
Home
