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

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