On 11/29/2012 04:29 AM, Juan Hernandez wrote:
On 11/29/2012 10:16 AM, Itamar Heim wrote:
On 11/29/2012 03:19 AM, Juan Hernandez wrote:
On 11/28/2012 07:13 PM, Itamar Heim wrote:
On 11/28/2012 12:15 PM, Juan Hernandez wrote:
On 11/28/2012 01:32 PM, Juan Hernandez wrote:
On 11/28/2012 12:57 PM, Itamar Heim wrote:
On 11/28/2012 04:54 AM, Juan Hernandez wrote:
On 11/28/2012 09:55 AM, Itamar Heim wrote:
On 11/28/2012 03:50 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Alon Bar-Lev" <[email protected]>
To: "Allon Mureinik" <[email protected]>
Cc: [email protected]
Sent: Wednesday, November 28, 2012 10:14:02 AM
Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
(was RE: maven settings.xml in building
ovirt engine wiki)
----- Original Message -----
From: "Allon Mureinik" <[email protected]>
To: [email protected]
Sent: Wednesday, November 28, 2012 10:05:18 AM
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
repo (was RE: maven settings.xml in building
ovirt engine wiki)
<snipped>
Note that settings.xml isn't shifted with ovirt-engine, nor
stored
on
ovirt-engine git repository. Therefore there is no real method to
control its content expect updating the wiki page.
Spinning off from the previous discussion - we can't really control
the contents of settings.xml, but perhaps we can make them easier
to
get.
Today, the flow is like this:
1. git clone - depends on gerrit.ovirt.org
2. wget settings.xml - depends on wiki.ovirt.org
Suppose we ship settings.xml inside the configuration folder of
ovirt
(next to engine-code-format.xml and engine-commit-template.txt).
Then you'll have to do:
1. git clone - depends on gerrit.ovirt.org
2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
This may a bit simpler, and at the very least, when we update our
code (e.g., to assume java7, *hint*), we can make all the changes
in
a single commit, and not have to update the code and then upload a
file to the wiki.
Comments? Feedback?
First thing... I don't like changing global state of a machine only
because we require some setting...
So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
There is -gs parameter for maven to specify alternate settings file,
I strongly recommend people use it.
Also, as far as I understand we only need some attributes defined...
It is simple to use:
$ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
Before executing eclipse or make...
We can also integrate the environment variables idea into the maven
build, instead of using properties use environment variables... then
before executing build we:
$ export JBOSS_HOME=
$ export OVIRT_JDK_HOME= (optional)
If anyone prefers/chooses to use settings.xml he can create his
own...
So there are so many options, the last option is to use settings.xml
in my opinion... not that I against adding this template, but I
first suggest we consider removing its usage completely.... :)
Regards,
Alon
-Allon
I'll rephrase.
/today/ we provide an example of settings.xml in "Building the oVirt Engine"
wiki page.
People who understand maven will not overwrite their settings.xml with it, and
people who don't have a comfortable quick start.
I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
People who didn't overwrite their existing .m2 file still won't, and people who
did have an easier way of doing it.
i agree having the sample in the git will make it simpler, and we must
make it simpler (juan is working on cleaning up the 'setup devel' flow).
I am not against having that example in the git repository. But I don't
see how that is going to make life easier for newcomers. We will have to
instruct them (in the wiki) how to find the file instead of instructing
them how to create it, not much difference.
if we tell them to:
yum install X Y Z
git clone ...
cd ovirt-engine
mvn clean install --settings settings.xml
it should just work, unless i am missing something?
Yes, should work, but then we need to include this "--settings
$HOME/ovirt-engine/settings.xml" in all the example commands in the
wiki. It doesn't make things simpler.
for simplicity, please lets also assume the would be developer also
isn't intimate with eclipse/jboss, so default in the file should work
with someone doing:
yum install eclipse jbossas
Unfortunately using "yum install jbossas" is not an option currently, as
that requires the developer to use root, which causes a lot of trouble.
any way to solve this?
The easy solution is to use the .zip distribution, which works in any
distribution.
For the future, in my opinion, we should move towards a model where the
development environment is much more similar to the production
environment than what we have now. The build system should be able to
install the complete engine to a directory under the developer home
directory, with the same file system structure that we use in production
environments. Then the developer should be able to start/stop the engine
(and tools) using the same scripts that we use in production
environments. These scripts don't need write access to the jboss-as
installation directories, so as a side effect they solve this problem.
We have to instruct new developers to download the JBoss .zip file and
uncompress it somewhere, easiest is the developer's home directory. This
has the advantage that it also works in distributions that haven't
packaged JBoss yet.
Using "yum install eclipse" also has its drawbacks, as the version of
eclipse in Fedora doesn't include the maven plugin.
isn't the maven plugin just another rpm?
No, the maven plugin is not yet packaged for fedora:
https://bugzilla.redhat.com/814245
It can be installed manually as described in the wiki, and then it
should work (it doesn't in Fedora 18 as far as I can tell).
I would rather suggest using a lighter alternative, like including
working .project and .classpath files in the repository (I can foresee a
lot of people cursing me for proposing this) or generating them using
the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
[1] http://maven.apache.org/plugins/maven-eclipse-plugin
[2] http://eclipse.org/m2e
I just submitted a change to add a new eclipse.py script that creates
the Eclipse project files automatically:
http://gerrit.ovirt.org/9556
If this is accepted I can update the wiki add instructions on how to use it.
Of course those that prefer it can continue using m2e, this is just a
lighter and simpler alternative, specially for environments where m2e is
not available out of the box.
I'm pretty sure i saw some negative feelings about eclipse project files
vs. using m2e.
do we know what the gap the m2e plugin has to get into fedora?
The gap is that it needs someone willing to package it.
doesn't it only need a reviewer (hopefully the packager is still willing
to push this from his side)
Bug 847160 - Review Request: eclipse-m2e-core - Maven integration for
Eclipse
It is not ready for review, as far as I can tell, it needs more work
from the packager, and looks like the current packager lost interest in
the package.
(we can also consider hosting it as an interim in ovirt repo)
I think that is not worth, users can just install it from the
corresponding Eclipse repositories.
lets see the final result and see who many steps it has, then revisit if
neccesary
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
