Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] manifest first build requires maven3?

2009/12/28 Shawn O. Pearce <spearce@xxxxxxxxxxx>
Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx> wrote:
> 2009/12/25 Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
>
> > This actually makes me want to switch to maven-bundle-plugin[2],
> > because at least then our Maven repository is still usuable as a
> > Maven repository...
> >
> > [2] http://egit.eclipse.org/r/159
>
> I face two problems building JGit using [2] :
> - the manifest generated for org.eclipse.jgit looks weird
> [MANIFEST-jgit-felix] compared to the one packaged by tycho
> [MANIFEST-jgit-tycho.MF]

What's wrong with that?  The jgit-felix manifest is valid for OSGi.

Apparently there is actually a good reason to import back your own
packages that you export.

ah, obviously I am not yet an OSGi expert, I did some search based on your hint
and now I guess the reason is described here
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html.
I am not sure if that's really relevant for jgit but most probably it will do no harm.

Also, the jgit-felix manifest is setting version numbers on all of
the packages using a range, something we haven't done within the
Tycho based manifests.  But that's just a configuration in the
top level pom.xml, we could change it to be more strict in its
import range. 

I agree, I think we should also start using Eclipse API tooling
http://wiki.eclipse.org/PDE/API_Tools/User_Guide
to guide us on API relevant changes.
 
> - build of EGit update site using [3] fails (I don't understand why) :
> [ERROR] Failed to execute goal
> org.sonatype.tycho:maven-osgi-packaging-plugin:0.6.0:update-site
>
EGit can't locate JGit via an OSGi repository.  The top level pom.xml
is only searching the Galileo P2 release repository, which JGit
isn't part of.  I have no idea how Igor meant for this to find JGit,
but it seems it can't.

We probably have to add an additional P2 repository of something
like ../jgit/org.eclipse.jgit-site/target/site to scan the P2 site
produced by the JGit build.

Or, we teach EGit to build using maven-bundle-plugin and use the
standard Maven repository resolver to resolve JGit, and the P2
resolver to resolve everything else.

But that's EGit's problem, not JGit's problem, and has nothing to
do with the build process we run in JGit.

that's right



> If we build JGit using [2] is it still possible to clone the jgit repo using
> EGit or do we then have to use a different mechanism since the repo doesn't
> contain .project files any more ?

That's a bug in EGit then.

Many other projects beyond just JGit have only a Maven pom file in
the top level.  These should still be importable into Eclipse as
projects via the Maven project importer.  EGit isn't doing quite
the right thing yet post clone, because its only bringing up the
existing project importer.  IIRC the CVS team provider is able to
bring up the Maven project importer post checkout.

But, yes, until then, clone of JGit through EGit becomes a bit harder
as you need to clone first, then import the projects by hand after
the clone is complete.

ok, that will raise the incentive to close this gap ;-)

Anyway we should fix this to make EGit more attractive for all projects
using Maven as their build system.
 
--
Matthias

Back to the top