[Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building ovirt engine wiki)

Wed Nov 28 12:32:56 UTC 2012

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" <alonbl at redhat.com>
>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> 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" <amureini at redhat.com>
>>>>>> To: engine-devel at ovirt.org
>>>>>> 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

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.