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? 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.

> >> - 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.

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]

Reply via email to