[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [egit-dev] jgit and eclipse meta-data.
|
I've used the Maven build combo and PDE (or just JDT) in production
systems where I work in the past with no problem. It's not a big chore
to sort them out. I also think that the debate is not helping the
development of JGit in any valuable way, and that these are
potentially dissuading others from joining in.
Many projects have IDE specific files checked in to allow people to
check out and go. In this case, the Manifest is an example of a PDE/
IDE specific file - it doesn't have to be the final one in the build.
And even generated files can get checked in - EMF projects do this all
the time, for example. When you need to change a dependency, you can
just check it in.
Arguing that there must be only one way (whichever way that is) will
cause problems for the other. We can either take the middle road (and
use both) or leave JGit as a maven-only solution that is built and
developed outside of PDE. If that's the case, we might as well check
in a JAR into Orbit and treat JGit like any other third party
dependency and be done with it.
Alex
Sent from my (new) iPhone
On 9 Jan 2010, at 21:29, Jason van Zyl <jason@xxxxxxxxx> wrote:
On 2010-01-09, at 2:50 PM, Thomas Hallgren wrote:
Jason van Zyl wrote:
It is all eclipse tooling. If you're saying that it has to consist
of only tools that exist at eclipse.org then I'm going to tell you
you're being provincial.
I don't want to shut out Maven/Tycho. But I don't want Maven/Tycho
to shut out other ways of building either.
A given project generally doesn't have multiple ways to build. That
just doesn't happen in practice. It's just too hard for the
developers.
I'm trying to find a middle ground that would work for all without
enforcing use of Maven/Tycho. That's hardly provincial. Making the
project "maven only" could be perceived that way though.
How many projects do you know that have the developers maintaining
multiple ways of building the project? It just doesn't work. I have
been in many organizations where there were multiple build tools --
which is always going to be the case -- and they interoperated at
the repository level. Every project can't build with multiple tools.
That's just highly impractical. But I imagine that we can
interoperate at the P2 repository level.
So if I walk into a project that uses Buckminster to build are you
going to maintain a Maven build? Do you want to maintain the tools
to generate a Maven POM and all the development tools to make sure
it's a good experience everyone who wants to develop with Maven? I
highly doubt that. It simply wouldn't be practical.
There are thousands of open source projects that are Maven only, PDE
Build only, Ant only. Having a single project work at the
development level for multiple systems just isn't a workable
situation.
What I would be willing to do is figure out what the actual
requirements are for integrating into the production stream for
the standard distributions. From what I can tell this doesn't
require Buckminster but a P2 repository that can be integrated.
Several projects base their CI on Buckminster. Most others are
based either on Athena or something proprietary. None of them
introduce workflows that blocks other builders. I'm convinced that
the best path forward is to make the build systems interact, hence
and my interest in improved Maven integration for Buckminster.
Well, that's just not the way I've ever seen this done in a
production environment. That simply would not work in a large
organization and I doubt that would work here or be necessary. If
another build tool surfaces you are then going to posit that it
should interoperate with every other build tool here? I can build
Eclipse distributions with Tycho with a P2 repository regardless of
the source. If you're saying that Buckminster can't put together the
standard Eclipse distributions using normal P2 repositories then
maybe we can show you some example with Tycho that do not require N-
way integration between build tools. Maybe this long term is a more
practical solution.
The manifest is not the source of dependency information in the
case of the JGit project. The result bundle that is produced is
just a JAR, yes. And the manifest is present there when the build
is done, but it's not what's used during development of JGit.
That is being mediated by M2Eclipse during development.
It's probably not a horrible thing to check in the manifest but
will probably lead to spurious results and I think it's better not
to let that happen. The manifest information is abstracted in OSGi
itself so we're going to exploit that fact and we have another
source. We will, in short order make this work nicely with PDE. If
PDE understands it then development should be smooth.
I think the 'generated dependency' argument is a poor excuse for
forcefully generating the manifest. Package import/export
statements control visibility for the bundle and should be a
concern of the compiler and the runtime, not the build system.
Bundle start levels, activator, etc. are also integral parts of the
bundle. If Eclipse is targeted, then dependencies are better
captured higher up (in features). If not, then I guess the POM is a
good way to declare them. But that does not mean that you must
generate the manifest since the manifest typically won't list the
actual jars that it depends on.
I think you need to go look at BND as the maven-bundle-plugin is
only a thin wrapper around that. It can control anything that you
might put in a manifest. Some people use a BND file and generate the
manifest from that where it's just a convenience format. And others
use instructions in the POM to generate the manifest, but there is
additional configuration in the plugin to control the OSGi-ness of
the project. Peter Krien's wrote BND so I doubt any tool is going to
be any more OSGi friendly then what he makes.
If all files are checked in (.project, .classpath, manifest,
build.properties, pom, etc.) then I'm fairly certain that it would
not block any development, nor usage of the jgit bundle. The
current situation however, is indeed blocking every other usage
then Tycho/Maven.
Not my call. I'll leave it to the folks working on the project to
decide. But saying Tycho/Maven is blocking development is like
saying every Buckminster build is blocking every non-Buckminster
development effort. I think that's a fairly unreasonable assertion.
You may find using M2Eclipse or Tycho loathsome but it doesn't seem
like it bothers the developers on the project.
Regards,
Thomas Hallgren
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev