On 6 Dec 06, at 8:16 PM 6 Dec 06, Brett Porter wrote:
I generally agree with what John has said in the thread so far. I
think this is a good thing: a nice out of the box installation
Define nice? If it's an installation that is different then something
standard that users typically get then it is a not a good thing. I
can just see the threads now:
"I put my global stuff in the /etc/maven/settings.xml and blah blah
blah"
"In /etc/maven/settings, mine is in $MAVEN_HOME/conf/settings.xml"
"I don't have a $MAVEN_HOME/conf"
"What version are you using?"
"I'm just using what came with Redhat/BSD/Solaris"
So instead of having our standard platform neutral single directory
structure, we have each distro doing whatever they want. If it was a
package that dropped stuff into the standard way we are doing things
great. If not then I'm am so strongly -1 to any such work I can't be
emphatic enough. It will fracture out user base completely. I frankly
don't care about distros, I care about our users and their experience
and their ability to communicate with other users regardless of what
platform they are on. Having different setups because Redhat/Solaris/
BSD feel like doing things different is not a good thing.
For the enterprise I see an agent that can be installed on any OS and
pulls down our software from a Maven repository and lays down a
structure and pattern that is consistent across any machine for the
sake of providing a common infrastructure so that our users can
communicate effectively with one another regardless of what platform
they are using.
, but you can still roll your own if needed. I think it's important
that we break this down into the requirements like these listed
below and work through them, using the prototype as a starting
point. I agree we can't apply it 'as is', which I think was well
known, but some of the concepts are features we'd like to add to
Maven anyway so I don't see any problem working through it.
I think we have far more pressing concerns then worrying about. This
is definitely not a priority for the vast majority of our users.
Releasing 2.0.5, 2.1, and plugins are definitely of more interest I
would imagine.
The key requirement from me would be that Maven continues to
operate in the same way (warts and all). So, while we may be
considering unifying versions and other such things to install and
execute Maven, Maven builds should, by default, work the same.
It cannot possibly be the same if it's installed differently on
different platforms. It's just another form of vendor lock-in. If
Maven, Continuum, Archiva and the stack of our applications had to be
navigated differently and used slightly differently then something we
can certainly provide in a platform neutral way then I think that's
one of greatest disservices we could do to our users. Everyone has
lived without RPMs and I don't think we've ever had a single request
for one.
If it is something where a package was made and it looked the same as
we do now that's great. If it created a barrier where someone who was
using Maven on Windows and then moves to Redhat and installs Maven as
they are accustomed to and some default system version kicks in
because it's in the path first and produces completely unexpected
output then that's a bad thing.
I think this is a key issue we are going to need to work through,
but it also seems like one that isn't the primary concern from the
requirements below. These are phase 1: build and install Maven on
Fedora. Phase 2 is use Maven to build and install other things on
Fedora, which is where the other options and the contention comes
in, right?
So, next steps... should we start fleshing this out on a wiki
somewhere? Are there any non-conententious parts of the patches
that can be proposed in JIRA now?
Anyone can knock themselves out. I care about users on Linux system
but I frankly don't care about LHS for Java as I don't believe it
provides a good experience for our users and never could. Given that
the requests for RPM, Debian package, or Solaris package are zero I
think it's safe to say this is not a great concern to our user base.
Jason.
Thanks,
Brett
On 07/12/2006, at 7:02 AM, Carl Trieloff wrote:
John Casey wrote:
Let's start with: What are the requirements?
Regards,
John
yes that is good - I would not see the patches set as something to
commit as is but a prototype to see if it could
be done. we now think it can - and would do it in a way that works
for maven.
The key parts are:
- boot strap via build from source
- OS boot strap-able, with no network, this is more than just mvn -o
- meet fedora package guidelines
Can break those our one by one, unless Deepak or Rafi fill them
first.
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]
