[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:29:00 UTC 2012

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

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.

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