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

[Juan Hernandez]

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.

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

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