Just to clarify the building from source situation, the real requirement
is that if we were in a concrete bunker somewhere with no connection to
the outside world, and all we had was an installed fedora box + all the
source rpms for fedora, we should be able to rebuild the entire OS.
Note that this doesn't require building everything from source all in
one go. That's impossible since there are cyclic dependencies, e.g. gcc
is used to build itself. It *does* require that we can completely turn
off all maven's attempts at remote access and preferably turn them into
nice error messages. Now I'm not sure how this translates into the
building one level from source vs building all levels from source
terminology, I would phrase it as we need to build all levels from
source, but we can build them one level at a time. This strict offline
bootstrapping requirement is necessary for producing consistent OS builds.
This does make it clear that a self contained binary repository will
work, as long as the self contained binary repository is part of every
fedora install. The only issue there is one of JPP vs maven conventions
for jar locations.
--Rafael
Carl Trieloff wrote:
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
This seems reasonable - we do need to work with jpackage so there might
be some items that come from that. If there are maybe we can see if we
can do it in a consistent way that can work for mainline also.
- Using the Maven repository as the source for satisfying dependencies
for development work
That was my assumption and if we can get all the items we needed merged
in a way maven is happy with upstream there would be no reason to do
anything else
- 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
There is a timeline issue with this. If we complete the Maven work
before JDK (GPL) is available then we might need to prove we can build
with GCJ, or build with mainline of the GPL version which will be ahead
1.6. Don't really know if worth debating now as GPL JDK is also a moving
target and we should eval once we get closer to completing the other
items that need to be done.
A couple questions that weren't really answered were:
- How far into the graph do you need to build from sources
-> All the way, or we can limit some modules and add them incrementally,
or maybe if the user needs them the we can
download them when mvn is run much like anaconda.
- 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?
-> All dependencies that are shipped in the distro or used to build the
distro need to be able to be built from source.
Suggestion:
Would a good starting point be to maybe be to create a branch where some
guys can work, and then we work item by item with the maven community.
once we get an issue out the way, and agreed by maven team we merge the
branch and start the next item?
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]
