[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] How to build [EJ]Git?
|
On Jan 8, 2010, at 00:09, Jason van Zyl wrote:
On 2010-01-07, at 6:25 PM, Alex Blewitt wrote:
That was because of a blocking issue with Tycho's generated
artefacts; specifically, that they couldn't be consumed in any form
by Maven 2 projects. I wouldn't call that a 'decided' as what's
preferable, but a workaround for something that couldn't be.
Tycho can certainly be made to do that and the for doing conversions
whether at build time or whether in the repository is going to be
the same. But I still think the pom-first mode for JGit is
preferable. We'll get it all to work in Eclipse and when that
happens there is no downside to have it work elsewhere too.
Whether it makes sense for JGit is somewhat orthogonal as to whether
Tycho-produced artefacts can be consumed as normal JARs by Maven 2.
JGit is the current example.
Did we get a bug filed for that? Otherwise, it would seem that any
Manifest-first project can only be used in conjunction with Maven
3, which means it's even less compatible with Maven 2 than just
using PDE to write the code and having Buckminster generate Maven 2
compatible artefacts.
I haven't filed a bug no.
Where can I file a bug?
Manifest-first was designed to work with OSGi projects and Tycho was
made to interoperate with PDE.
Yes, I saw this as being a great step forwards for both OSGi and
Maven. I saw the maturity (and reporting etc.) features of Maven
complementing the tooling in PDE which makes everything work together.
Much like Maven+Eclipse worked in the old days, where JDT would do the
(incremental) compilation but still be able to kick of a Maven build
for continuous integration purposes.
We are going to take care making all P2 and OBR artifacts through a
proxying mechanism in Nexus. The same way we just got it to work for
RubyGems:
Yes, that sounds like a good idea for the proxying/repository
management mechanisms, and in particular, transliterating the various
update forms.
We can debate the merits of build time versus on-demand conversion
but from my perspective converting OSGi <--> Maven can happen
dynamically with the results cached and then you only convert what's
actually requested and you can record demand.
The problem is that this conversion can't happen at a Maven 2 client
level. So if JGit gets built (tycho, manifest-first) and installed
into ibiblio, then suddenly people can't download and use that as a
Jar. That's the same kind of frustration as happens at the moment when
you download an ordinary Jar file which doesn't have OSGi manifest
information. It's not the end of the world, but it introduces a
separate step to make it happen.
Granted, if you've got a repository manager that knows how to do the
stuff, theng reat. But if you've just got your own local repo, which
you've built+installed in maven3, then run a local maven 2 build,
there's no repository manager involved. Nor if the artifact is
uploaded to (say) a website.
But if you want to add a feature request to Tycho as a reminder we
can get the build time conversion done too. I'm just thinking of the
general pragmatism in this case where JGit can work fine as pom-
first and I doubt anyone outside of Eclipse/OSGi land is going to
want EGit as a normal Maven dependency.
This is much bigger than EGit+JGit though. There are plenty of JARs
that are built by Eclipse which run both as OSGi and can be consumed
by regular Java clients from the command line. ECF has most of
them :-) EMF is another example. Yes, most of the tooling is OSGi/
Eclipse based - but the runtime Jars are both OSGi bundles and regular
JAR files. Given that most of the Eclipse.org hosted sites use
Manifest-first implicitly (for PDE) then any Tycho-based solution
which prevents generation of Maven 2 compatible JAR artefacts auto-
dooms the use of Tycho. One might even wonder whether there's even any
point to Tycho, if we can get Maven repo layout with Buckminster from
a PDE build.
My point is that the requirement - of being able to produce valid OSGi
bundles /as well as/ a normal JAR dependency for non-OSGi users is a
pretty much key thing for Maven to be able to take off in the OSGi
(Eclipse) world. Granted, there may be bigger pictures of others using
different tools and IDEs doing things in a pom-first way, but in the
OSGi subset of the world that is Eclipse, it's manifest-first all the
way.
It's a separate debate about what 'should' be done, but the reality is
that if we end up with this problem then it's basically limiting
Manifest-first dependencies to be used by Manifest-first clients only,
and that rules out many of the common Jars of Eclipse.
* SWT
* JFace
* EMF
* ECF
* JDT <- pretty sure Maven wraps/republishes the container from JDT
for compilation purposes, no?
* EclipseLink
* Jobs (I think)
* Eclipse CVS
* Help (webapp/infocenter)
* Jetty
* JGit
So, whether or not it's the right choice for JGit doesn't have any
impact on all these other projects, which need to be both consumable-
as-an-OSGi-bundle and consumable-as-a-JAR.
Alex
