The Intranet is a black hole... documents can only go in never to be found again. I needed to go back 3 months in my browsing history to find this, because why should it be found with keywords like upstream or downstream :P https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel Have fun, Noam. ----- Original Message ----- From: "Ofri Masad" <omasad@redhat.com> To: "Laszlo Hornyak" <lhornyak@redhat.com>, "Noam Slomianko" <nslomian@redhat.com> Cc: engine-devel@ovirt.org, "Alissa Bonas" <abonas@redhat.com> Sent: Tuesday, November 27, 2012 9:10:48 AM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki Hi, I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...) Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments. The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss. ----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Alissa Bonas" <abonas@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, November 26, 2012 6:52:52 PM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki Hi, That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)? ----- Original Message -----

From: "Alissa Bonas" <abonas@redhat.com> To: engine-devel@ovirt.org Sent: Monday, November 26, 2012 10:15:14 AM Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine

The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home. IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places.

The current settings look like this (note that java path is incorrect anyway, including /bin/java)

<jbossHome>/usr/share/jboss-as</jbossHome> <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>

How about changing settings.xml to something like:

<jbossHome>${env.JBOSS_HOME}</jbossHome> <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>

Does anyone see a problem with the suggested approach?

Thanks

Alissa

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On Tuesday 27 November 2012 02:06 PM, Noam Slomianko wrote:

Oh, sorry. Didnt notice it was sent to an ovit mailing list :D

so, my solution is:

create two different files (containing at least):

<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

<!--**************************** PROFILES ****************************-->

<localRepository>{maven_home}/{repository}</localRepository>

<activeProfiles> <activeProfile>oVirtEnvSettings</activeProfile> </activeProfiles>

<profiles> <profile> <id>oVirtEnvSettings</id> <properties> <jbossHome>{jboss location}</jbossHome> <JAVA_HOME>{java location}</JAVA_HOME> <gwt.userAgent>gecko1_8</gwt.userAgent> </properties> </profile> </profiles> </settings>

Between the two file you change: - {jboss location}, self explanatory - {java location}, only if they are of a different version - {repository}, so you dont get conflicting packages Of course they shouldn't be called Settings.xml

And then add a change script so its easy to switch via a soft link, mine is: if [ $1 = "up" ] then rm ~/.m2/settings.xml ln -s ~/.m2/settingsUp.xml ~/.m2/settings.xml echo "changed jboss to upstream (1.7)" else rm ~/.m2/settings.xml ln -s ~/.m2/settingsDown.xml ~/.m2/settings.xml echo "changed jboss to downstream (1.6)" fi

Another trick is to use the --settings option of maven e.g. mvn --settings ~/.m2/settingsUp.xml clean install -Pdep

----- Original Message ----- From: "Noam Slomianko" <nslomian@redhat.com> To: "Ofri Masad" <omasad@redhat.com> Cc: engine-devel@ovirt.org, "Alissa Bonas" <abonas@redhat.com>, "Laszlo Hornyak" <lhornyak@redhat.com> Sent: Tuesday, November 27, 2012 9:27:54 AM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

The Intranet is a black hole... documents can only go in never to be found again. I needed to go back 3 months in my browsing history to find this, because why should it be found with keywords like upstream or downstream :P

https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel

Have fun, Noam.

----- Original Message ----- From: "Ofri Masad" <omasad@redhat.com> To: "Laszlo Hornyak" <lhornyak@redhat.com>, "Noam Slomianko" <nslomian@redhat.com> Cc: engine-devel@ovirt.org, "Alissa Bonas" <abonas@redhat.com> Sent: Tuesday, November 27, 2012 9:10:48 AM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...)

Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments. The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss.

----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Alissa Bonas" <abonas@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, November 26, 2012 6:52:52 PM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----

...

From: "Alissa Bonas" <abonas@redhat.com> To: engine-devel@ovirt.org Sent: Monday, November 26, 2012 10:15:14 AM Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine

The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home. IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places.

The current settings look like this (note that java path is incorrect anyway, including /bin/java)

<jbossHome>/usr/share/jboss-as</jbossHome> <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>

How about changing settings.xml to something like:

<jbossHome>${env.JBOSS_HOME}</jbossHome> <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>

Does anyone see a problem with the suggested approach?

Thanks

Alissa

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

settings.xml is consumed by maven only, while other programs such as IDE, Jboss, etc consume environment variables set in other ways such as .bashrc. Thus we need them both - and this is why I think it's better to re-use the configuration from .bashrc in settings.xml. ----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Alissa Bonas" <abonas@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, November 26, 2012 6:52:52 PM Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki Hi, That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)? ----- Original Message -----

From: "Alissa Bonas" <abonas@redhat.com> To: engine-devel@ovirt.org Sent: Monday, November 26, 2012 10:15:14 AM Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine

The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home. IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places.

The current settings look like this (note that java path is incorrect anyway, including /bin/java)

<jbossHome>/usr/share/jboss-as</jbossHome> <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>

How about changing settings.xml to something like:

<jbossHome>${env.JBOSS_HOME}</jbossHome> <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>

Does anyone see a problem with the suggested approach?

Thanks

Alissa

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

<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? -Allon

----- Original Message -----

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: engine-devel@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@redhat.com> To: engine-devel@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.

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@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: engine-devel@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@redhat.com> To: engine-devel@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.

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

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@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: engine-devel@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@redhat.com> To: engine-devel@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 -- 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.

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@redhat.com> > To: "Allon Mureinik" <amureini@redhat.com> > Cc: engine-devel@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@redhat.com> >> To: engine-devel@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?

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@redhat.com> >>> To: "Allon Mureinik" <amureini@redhat.com> >>> Cc: engine-devel@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@redhat.com> >>>> To: engine-devel@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)

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@redhat.com> >>>>> To: "Allon Mureinik" <amureini@redhat.com> >>>>> Cc: engine-devel@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@redhat.com> >>>>>> To: engine-devel@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

On 11/28/2012 03:38 AM, Moti Asayag wrote:

On 11/28/2012 10:05 AM, Allon Mureinik wrote:

...

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

I don't think we should override an already existed shared configuration file.

user doesn't have to do this, and we can also suggest they run mvn with this file as an mvn option instead of copying it to default location.