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

Thu Nov 29 09:16:02 UTC 2012

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

(we can also consider hosting it as an interim in ovirt repo)