On 14 Dec 06, at 10:30 AM 14 Dec 06, Rafael Schloming wrote:
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.
Sure, but for Maven usage a JDK + a tarball of Maven in all practical
instances is enough for someone to get work done.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
