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

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

lets see the final result and see who many steps it has, then revisit if 
neccesary