On 13 Dec 06, at 7:15 PM 13 Dec 06, Deepak Bhole wrote:
On Wed, 2006-12-13 at 18:30 -0500, Jason van Zyl wrote:
On 13 Dec 06, at 5:57 PM 13 Dec 06, Deepak Bhole wrote:
Hi,
I have read Brett's reply to this message. Just to add some more
info to
the points:
On Wed, 2006-12-13 at 10:57 -0500, Jason van Zyl wrote:
On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote:
I don't see that there is a consistent view yet on this. It would
be nice to get to a conclusion on whether the Maven community
would
like to work with the downstream distros teams so that we can
provide a consistent and good experience. Is there any more
information that is needed to get to a view point, and if so how
can I help?
If the distros works with us to provide something that is
familiar to
our current users, to which our documentation, practices, and
current
body of user knowledge apply then I don't think anyone would be
opposed here. So that means:
- Using an installation layout that is consistent with our current
setup
Short answer to this -- yes, this is doable and I don't see it as
being
an issue (I just sent an email to another thread a few minutes ago,
the
details are there).
- Using the Maven repository as the source for satisfying
dependencies for development work
This too, is doable. Any changes that the patches I posted makes,
are
optional. By default, the maven from the rpm behaves just like the
zipped maven, so all repositories can be used as needed. When the
appropriate switches/flags/properties/whatever are given, the idea
is to
switch maven to an "offline" only behaviour where it uses system
installed jars for everything.
Why is this useful? Simply for bootstrapping? If so, that's cool.
Why is offline behaviour useful?
No, optionally not using the Maven repository.
It is just the way Fedora does things
to ensure that everything is traceable. It is to ensure that the
entire
application is built ground up from sources. All of the "System
installed jars" that I am referring to above, are jars that come from
packages we built into Fedora, which would have been built from
source.
- Maven running with a standard JDK and not being compiled with GJC
or anything weird like that. With Java being GPL now that shouldn't
be a problem
Until Java can make it into FC, it will have to be built with gcj.
Java
may be GPL, but that is Java 7, not 5/6, and additionally, certain
parts
are encumbered/non-free and need working on. Until such a time that
the
entire class library is open, Fedora may not be able to include it,
and
may have to rely on gcj. However, Fedora uses ecj as the byte-code
compiler. ecj itself is quite stable and I don't think it'll be
much of
an issue. No more than say, using the BEA compiler to compile
maven2. If
the user then wants to use maven with the Sun class library, they
can
just install the Sun JVM afterwards.
If it passes all our integration tests then it should be
theoretically be ok. So we'll have to bolster our tests and if you
match the results of our standard suite of tests then I can live with
that.
Sure. We can run the suite and iron out any issues we find, to ensure
that all tests pass.
Any variation from this I would consider potentially harmful to
Maven
users and I personally would tell people to avoid the potential
complication for their enterprise environments. Simply conveying my
first hand experience. I really think this is the only way you're
going to get buy-in from from Maven users and would be a win-win
for
everyone involved. I have far stronger opinions about this stuff
and
you certainly don't need my buy in to do whatever you want and I'm
sure others here would work with you. I just don't see the point
frankly if you roll something different.
A couple questions that weren't really answered were:
- How far into the graph do you need to build from sources
This can be discussed in-depth at a later time, however, I think the
first couple or so levels (so direct dependencies of maven, and
their
dependencies, etc.) should be fine. We certainly wouldn't expect
all-level dependency building, as it may very well end up being the
entire java stack in Fedora, if not most of it.
Right now you get the first level, can you live with that to start.
This is what our bootstrap does and I'm not sure why one more level
would be of any use if we've built them and signed them. If you're
going to end up with a mix of stuff built with a standard java
compiler and GJC then what does it matter if you're not going to do
the whole graph?
There won't be any mix. Since everything is always built from
source in
the Fedora build system, everything is reproducible. Lets say
maven2 had
a single dependency -- say plexus-utils. And then plexus-utils had a
single dependency, say jdom. Then plexus-utils is the level1, and jdom
is the level2. If you were to build all level1, you would be building
plexus-utils only. That plexus-utils would be built against the jdom
that was already in Fedora, and that jdom would have been built from
source. Thus all of Fedora is built ground up from source.
What happens when you have conflicting versions?
- Would a self-contained Maven repository with the binary
dependencies work and then build Maven itself from source or do you
want to walk back down the entire graph?
Please see above. If only the top few levels are built by you, they
can
be built on top of lower levels (which too, will be from source, and
built by other maintainers). Everything in Fedora has to be built
from
source unless it is the initial bootstrap build.
Ok, I'm not quite understanding here. So you are going to build all
these packages from source? And you're not going to use JARs that we
have built? I have that clear?
Right. All jars that will be used should come from Fedora packages.
The
only exception is during a "bootstrap" build. Bootstrap builds are
builds to resolve circular dependencies. If A needs B and B needs
A, we
would build A in bootstrap mode and provide it with a pre-built binary
of B. We would then build B against this built A, and then rebuild A,
this time against the B that we just built (i.e. non-bootstrap). What
ends up in the final distribution has to be non-bootstrap.
If you're using GCJ then I guess you don't have much choice. Though I
still see this as sort of silly when you're using the Sun JDK. What
are you going to do when you can distribute the Sun JDK? At that
point I would say it would be simply easier to take the binaries we
built.
I don't think you're going to end up with the same thing using GJC ,
but let's try it and see what happens.
Jason.
Cheers,
Deepak
- Are you guys willing to compromise and make something that
uses our
current layout. I think we could live with some symlinks to /usr/
bin
or whatever
This is already the case. Please see my mail in the other
thread. /usr/bin/mvn is just a wrapper that does a pushd
into /usr/share/maven2 (the M2_HOME) and runs the bin/mvn there.
Cheers,
Deepak
Jason.
Carl.
------------------------------------------------------------------
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
