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

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(a)redhat.com&gt; >>>>>>>>>> To: "Allon Mureinik" <amureini(a)redhat.com&gt; >>>>>>>>>> Cc: engine-devel(a)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(a)redhat.com&gt; >>>>>>>>>>> To: engine-devel(a)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.