Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
66 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator
Do you intend to convert to use Maven for building? I mean to replace Ant?
Else what does this add compared to Ant?

BTW are you aware of our policy of creating Jira in order to capture releases changes?
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges

Jacques

Le 17/04/2015 07:52, [hidden email] a écrit :

> Author: doogie
> Date: Fri Apr 17 05:52:32 2015
> New Revision: 1674216
>
> URL: http://svn.apache.org/r1674216
> Log:
> Well, this is the start of converting ofbiz to use maven for building
> and packaging.  There's a workable parent-pom, and I have converted
> framework/start to maven as well.  To use this, the following commands
> are useful:
>
> * mvn clean
> * mvn compile
> * mvn package
>
> All 3 can be run in either ${ofbiz.home.dir}, or in framework/start.
> The trick that made this simple, was that I was able to redefine maven's
> default file layout away from src/main/java and target/*, to something
> more ofbiz specific.  This way of doing things is just to get things
> going; eventually, we should adopt a more standard maven like layout.
>
> Another thing not dealt with in these first 2 files, is downloading of
> dependencies.  The top-level and framework/start have no external
> requirements, so it allowed me to get going quite quickly.
>
> Added:
>      ofbiz/trunk/framework/start/pom.xml
>      ofbiz/trunk/pom.xml
>
> Added: ofbiz/trunk/framework/start/pom.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/pom.xml?rev=1674216&view=auto
> ==============================================================================
> --- ofbiz/trunk/framework/start/pom.xml (added)
> +++ ofbiz/trunk/framework/start/pom.xml Fri Apr 17 05:52:32 2015
> @@ -0,0 +1,69 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> +Licensed to the Apache Software Foundation (ASF) under one
> +or more contributor license agreements.  See the NOTICE file
> +distributed with this work for additional information
> +regarding copyright ownership.  The ASF licenses this file
> +to you under the Apache License, Version 2.0 (the
> +"License"); you may not use this file except in compliance
> +with the License.  You may obtain a copy of the License at
> +
> +http://www.apache.org/licenses/LICENSE-2.0
> +
> +Unless required by applicable law or agreed to in writing,
> +software distributed under the License is distributed on an
> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +KIND, either express or implied.  See the License for the
> +specific language governing permissions and limitations
> +under the License.
> +-->
> +
> +<project>
> +  <parent>
> +    <groupId>org.apache.ofbiz</groupId>
> +    <artifactId>ofbiz-parent</artifactId>
> +    <version>TRUNK</version>
> +    <relativePath>../../pom.xml</relativePath>
> +  </parent>
> +  <modelVersion>4.0.0</modelVersion>
> +  <artifactId>ofbiz-start</artifactId>
> +
> +  <build>
> +    <finalName>ofbiz</finalName>
> +    <plugins>
> +      <plugin>
> +        <groupId>org.apache.maven.plugins</groupId>
> +        <artifactId>maven-jar-plugin</artifactId>
> +        <configuration>
> +          <archive>
> +            <manifestEntries>
> +              <Manifest-Version>1.0</Manifest-Version>
> +              <Implementation-Title>Apache OFBiz Startup</Implementation-Title>
> +              <Implementation-Vendor>The Apache Open for Business Project</Implementation-Vendor>
> +              <Main-Class>org.ofbiz.base.start.Start</Main-Class>
> +            </manifestEntries>
> +          </archive>
> +        </configuration>
> +      </plugin>
> +      <plugin>
> +        <groupId>org.apache.maven.plugins</groupId>
> +        <artifactId>maven-antrun-plugin</artifactId>
> +        <executions>
> +          <execution>
> +            <phase>package</phase>
> +            <configuration>
> +              <tasks>
> +                <copy todir="${project.parent.relativePath}/..">
> +                  <fileset dir="${project.build.directory}" includes="ofbiz.jar"/>
> +                </copy>
> +              </tasks>
> +            </configuration>
> +            <goals>
> +              <goal>run</goal>
> +            </goals>
> +          </execution>
> +        </executions>
> +      </plugin>
> +    </plugins>
> +  </build>
> +</project>
>
> Added: ofbiz/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/pom.xml?rev=1674216&view=auto
> ==============================================================================
> --- ofbiz/trunk/pom.xml (added)
> +++ ofbiz/trunk/pom.xml Fri Apr 17 05:52:32 2015
> @@ -0,0 +1,76 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> +Licensed to the Apache Software Foundation (ASF) under one
> +or more contributor license agreements.  See the NOTICE file
> +distributed with this work for additional information
> +regarding copyright ownership.  The ASF licenses this file
> +to you under the Apache License, Version 2.0 (the
> +"License"); you may not use this file except in compliance
> +with the License.  You may obtain a copy of the License at
> +
> +http://www.apache.org/licenses/LICENSE-2.0
> +
> +Unless required by applicable law or agreed to in writing,
> +software distributed under the License is distributed on an
> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +KIND, either express or implied.  See the License for the
> +specific language governing permissions and limitations
> +under the License.
> +-->
> +
> +<project>
> +  <modelVersion>4.0.0</modelVersion>
> +  <groupId>org.apache.ofbiz</groupId>
> +  <artifactId>ofbiz-parent</artifactId>
> +  <version>TRUNK</version>
> +  <packaging>pom</packaging>
> +
> +  <build>
> +    <directory>build/lib</directory>
> +    <outputDirectory>build/classes</outputDirectory>
> +    <finalName>${artifactId}</finalName>
> +    <sourceDirectory>src</sourceDirectory>
> +    <resources>
> +      <resource>
> +        <directory>src</directory>
> +        <includes>
> +          <include>**/*.properties</include>
> +          <include>**/*.groovy</include>
> +          <include>**/*.xml</include>
> +          <include>**/*.bsh</include>
> +          <include>**/*.logic</include>
> +          <include>**/*.hs</include>
> +          <include>**/*.jacl</include>
> +          <include>**/*.py</include>
> +          <include>META-INF/**</include>
> +        </includes>
> +      </resource>
> +      <resource>
> +        <directory>${project.parent.relativePath}/..</directory>
> +        <includes>
> +          <include>LICENSE</include>
> +          <include>NOTICE</include>
> +        </includes>
> +      </resource>
> +    </resources>
> +    <scriptSourceDirectory>scripts</scriptSourceDirectory>
> +    <plugins>
> +      <plugin>
> +        <groupId>org.apache.maven.plugins</groupId>
> +        <artifactId>maven-compiler-plugin</artifactId>
> +        <configuration>
> +          <source>1.7</source>
> +          <target>1.7</target>
> +        </configuration>
> +      </plugin>
> +    </plugins>
> +  </build>
> +
> +  <reporting>
> +    <outputDirectory>target/site</outputDirectory>
> +  </reporting>
> +
> +  <modules>
> +    <module>framework/start</module>
> +  </modules>
> +</project>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator
After installing and setting last Maven version (3.3.1) this does not work well on Windows (I miss the maven-compiler-plugin I guess)

Anyway I think we should really discuss before going in this direction.
I, for instance, am strongly against moving to Maven when we have Ant already embedded and so friendly.
Also I'd not like to have to move Maven related changes to Attic in a year or two because it's unfinished...

tested: ant clean && mvn clean compile && ant start

Jacques
PS:
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.ofbiz:ofbiz-start:jar:TRUNK
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ org.apache.ofbiz:ofbiz-parent:TRUNK,
C:\projectsASF\ofbiz\pom.xml, line 58, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ org.apache.ofbiz:ofbiz-start:[unknown-version],
C:\projectsASF\ofbiz\framework\start\pom.xml, line 34, colu
mn 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.ofbiz:ofbiz-parent:pom:TRUNK
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 58, column 15
[WARNING] The expression ${artifactId} is deprecated. Please use ${project.artifactId} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] ofbiz-parent
[INFO] ofbiz-start
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ofbiz-parent TRUNK
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-parent ---
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ofbiz-start TRUNK
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-start ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ofbiz-start ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 8 resources
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ofbiz-start ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!
[INFO] Compiling 8 source files to C:\projectsASF\ofbiz\framework\start\build\classes
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] ofbiz-parent ....................................... SUCCESS [  0.160 s]
[INFO] ofbiz-start ........................................ SUCCESS [  1.012 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.303 s
[INFO] Finished at: 2015-04-17T10:26:24+02:00
[INFO] Final Memory: 13M/308M
[INFO] ------------------------------------------------------------------------
"C:\Program Files\Java\jdk1.7.0_45\bin\java" -jar "c:\projectsASF\ofbiz\\framework\base\lib\ant-1.9.0-ant-launcher.jar" -lib
"c:\projectsASF\ofbiz\\framework\base\lib\ant" start -Dportoffset 1
Buildfile: c:\projectsASF\ofbiz\build.xml

start:
      [java] Error: Unable to access jarfile c:\projectsASF\ofbiz\ofbiz.jar
      [java] Java Result: 1

BUILD SUCCESSFUL
Total time: 1 second

Le 17/04/2015 10:08, Jacques Le Roux a écrit :

> Do you intend to convert to use Maven for building? I mean to replace Ant?
> Else what does this add compared to Ant?
>
> BTW are you aware of our policy of creating Jira in order to capture releases changes?
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges 
>
>
> Jacques
>
> Le 17/04/2015 07:52, [hidden email] a écrit :
>> Author: doogie
>> Date: Fri Apr 17 05:52:32 2015
>> New Revision: 1674216
>>
>> URL: http://svn.apache.org/r1674216
>> Log:
>> Well, this is the start of converting ofbiz to use maven for building
>> and packaging.  There's a workable parent-pom, and I have converted
>> framework/start to maven as well.  To use this, the following commands
>> are useful:
>>
>> * mvn clean
>> * mvn compile
>> * mvn package
>>
>> All 3 can be run in either ${ofbiz.home.dir}, or in framework/start.
>> The trick that made this simple, was that I was able to redefine maven's
>> default file layout away from src/main/java and target/*, to something
>> more ofbiz specific.  This way of doing things is just to get things
>> going; eventually, we should adopt a more standard maven like layout.
>>
>> Another thing not dealt with in these first 2 files, is downloading of
>> dependencies.  The top-level and framework/start have no external
>> requirements, so it allowed me to get going quite quickly.
>>
>> Added:
>>      ofbiz/trunk/framework/start/pom.xml
>>      ofbiz/trunk/pom.xml
>>
>> Added: ofbiz/trunk/framework/start/pom.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/pom.xml?rev=1674216&view=auto
>> ==============================================================================
>> --- ofbiz/trunk/framework/start/pom.xml (added)
>> +++ ofbiz/trunk/framework/start/pom.xml Fri Apr 17 05:52:32 2015
>> @@ -0,0 +1,69 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<!--
>> +Licensed to the Apache Software Foundation (ASF) under one
>> +or more contributor license agreements.  See the NOTICE file
>> +distributed with this work for additional information
>> +regarding copyright ownership.  The ASF licenses this file
>> +to you under the Apache License, Version 2.0 (the
>> +"License"); you may not use this file except in compliance
>> +with the License.  You may obtain a copy of the License at
>> +
>> +http://www.apache.org/licenses/LICENSE-2.0
>> +
>> +Unless required by applicable law or agreed to in writing,
>> +software distributed under the License is distributed on an
>> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> +KIND, either express or implied.  See the License for the
>> +specific language governing permissions and limitations
>> +under the License.
>> +-->
>> +
>> +<project>
>> +  <parent>
>> +    <groupId>org.apache.ofbiz</groupId>
>> +    <artifactId>ofbiz-parent</artifactId>
>> +    <version>TRUNK</version>
>> +    <relativePath>../../pom.xml</relativePath>
>> +  </parent>
>> +  <modelVersion>4.0.0</modelVersion>
>> +  <artifactId>ofbiz-start</artifactId>
>> +
>> +  <build>
>> +    <finalName>ofbiz</finalName>
>> +    <plugins>
>> +      <plugin>
>> +        <groupId>org.apache.maven.plugins</groupId>
>> +        <artifactId>maven-jar-plugin</artifactId>
>> +        <configuration>
>> +          <archive>
>> +            <manifestEntries>
>> + <Manifest-Version>1.0</Manifest-Version>
>> +              <Implementation-Title>Apache OFBiz Startup</Implementation-Title>
>> +              <Implementation-Vendor>The Apache Open for Business Project</Implementation-Vendor>
>> + <Main-Class>org.ofbiz.base.start.Start</Main-Class>
>> +            </manifestEntries>
>> +          </archive>
>> +        </configuration>
>> +      </plugin>
>> +      <plugin>
>> +        <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-antrun-plugin</artifactId>
>> +        <executions>
>> +          <execution>
>> +            <phase>package</phase>
>> +            <configuration>
>> +              <tasks>
>> +                <copy todir="${project.parent.relativePath}/..">
>> +                  <fileset dir="${project.build.directory}" includes="ofbiz.jar"/>
>> +                </copy>
>> +              </tasks>
>> +            </configuration>
>> +            <goals>
>> +              <goal>run</goal>
>> +            </goals>
>> +          </execution>
>> +        </executions>
>> +      </plugin>
>> +    </plugins>
>> +  </build>
>> +</project>
>>
>> Added: ofbiz/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/pom.xml?rev=1674216&view=auto
>> ==============================================================================
>> --- ofbiz/trunk/pom.xml (added)
>> +++ ofbiz/trunk/pom.xml Fri Apr 17 05:52:32 2015
>> @@ -0,0 +1,76 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<!--
>> +Licensed to the Apache Software Foundation (ASF) under one
>> +or more contributor license agreements.  See the NOTICE file
>> +distributed with this work for additional information
>> +regarding copyright ownership.  The ASF licenses this file
>> +to you under the Apache License, Version 2.0 (the
>> +"License"); you may not use this file except in compliance
>> +with the License.  You may obtain a copy of the License at
>> +
>> +http://www.apache.org/licenses/LICENSE-2.0
>> +
>> +Unless required by applicable law or agreed to in writing,
>> +software distributed under the License is distributed on an
>> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> +KIND, either express or implied.  See the License for the
>> +specific language governing permissions and limitations
>> +under the License.
>> +-->
>> +
>> +<project>
>> +  <modelVersion>4.0.0</modelVersion>
>> +  <groupId>org.apache.ofbiz</groupId>
>> +  <artifactId>ofbiz-parent</artifactId>
>> +  <version>TRUNK</version>
>> +  <packaging>pom</packaging>
>> +
>> +  <build>
>> +    <directory>build/lib</directory>
>> + <outputDirectory>build/classes</outputDirectory>
>> +    <finalName>${artifactId}</finalName>
>> +    <sourceDirectory>src</sourceDirectory>
>> +    <resources>
>> +      <resource>
>> +        <directory>src</directory>
>> +        <includes>
>> +          <include>**/*.properties</include>
>> +          <include>**/*.groovy</include>
>> +          <include>**/*.xml</include>
>> +          <include>**/*.bsh</include>
>> +          <include>**/*.logic</include>
>> +          <include>**/*.hs</include>
>> +          <include>**/*.jacl</include>
>> +          <include>**/*.py</include>
>> +          <include>META-INF/**</include>
>> +        </includes>
>> +      </resource>
>> +      <resource>
>> + <directory>${project.parent.relativePath}/..</directory>
>> +        <includes>
>> +          <include>LICENSE</include>
>> +          <include>NOTICE</include>
>> +        </includes>
>> +      </resource>
>> +    </resources>
>> + <scriptSourceDirectory>scripts</scriptSourceDirectory>
>> +    <plugins>
>> +      <plugin>
>> +        <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-compiler-plugin</artifactId>
>> +        <configuration>
>> +          <source>1.7</source>
>> +          <target>1.7</target>
>> +        </configuration>
>> +      </plugin>
>> +    </plugins>
>> +  </build>
>> +
>> +  <reporting>
>> +    <outputDirectory>target/site</outputDirectory>
>> +  </reporting>
>> +
>> +  <modules>
>> +    <module>framework/start</module>
>> +  </modules>
>> +</project>
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacopo Cappellato-5
On Apr 17, 2015, at 3:35 AM, Jacques Le Roux <[hidden email]> wrote:

> Anyway I think we should really discuss before going in this direction.

+1

Jacopo

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

taher
In reply to this post by Jacques Le Roux
Hi All,

Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.

Taher Alkhateeb

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

From: "Jacques Le Roux" <[hidden email]>
To: [hidden email], [hidden email]
Sent: Friday, 17 April, 2015 11:35:04 AM
Subject: Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

After installing and setting last Maven version (3.3.1) this does not work well on Windows (I miss the maven-compiler-plugin I guess)

Anyway I think we should really discuss before going in this direction.
I, for instance, am strongly against moving to Maven when we have Ant already embedded and so friendly.
Also I'd not like to have to move Maven related changes to Attic in a year or two because it's unfinished...

tested: ant clean && mvn clean compile && ant start

Jacques
PS:
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.ofbiz:ofbiz-start:jar:TRUNK
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ org.apache.ofbiz:ofbiz-parent:TRUNK,
C:\projectsASF\ofbiz\pom.xml, line 58, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ org.apache.ofbiz:ofbiz-start:[unknown-version],
C:\projectsASF\ofbiz\framework\start\pom.xml, line 34, colu
mn 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.ofbiz:ofbiz-parent:pom:TRUNK
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 58, column 15
[WARNING] The expression ${artifactId} is deprecated. Please use ${project.artifactId} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] ofbiz-parent
[INFO] ofbiz-start
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ofbiz-parent TRUNK
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-parent ---
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ofbiz-start TRUNK
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-start ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ofbiz-start ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 8 resources
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ofbiz-start ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!
[INFO] Compiling 8 source files to C:\projectsASF\ofbiz\framework\start\build\classes
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] ofbiz-parent ....................................... SUCCESS [ 0.160 s]
[INFO] ofbiz-start ........................................ SUCCESS [ 1.012 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.303 s
[INFO] Finished at: 2015-04-17T10:26:24+02:00
[INFO] Final Memory: 13M/308M
[INFO] ------------------------------------------------------------------------
"C:\Program Files\Java\jdk1.7.0_45\bin\java" -jar "c:\projectsASF\ofbiz\\framework\base\lib\ant-1.9.0-ant-launcher.jar" -lib
"c:\projectsASF\ofbiz\\framework\base\lib\ant" start -Dportoffset 1
Buildfile: c:\projectsASF\ofbiz\build.xml

start:
[java] Error: Unable to access jarfile c:\projectsASF\ofbiz\ofbiz.jar
[java] Java Result: 1

BUILD SUCCESSFUL
Total time: 1 second

Le 17/04/2015 10:08, Jacques Le Roux a écrit :

> Do you intend to convert to use Maven for building? I mean to replace Ant?
> Else what does this add compared to Ant?
>
> BTW are you aware of our policy of creating Jira in order to capture releases changes?
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges 
>
>
> Jacques
>
> Le 17/04/2015 07:52, [hidden email] a écrit :
>> Author: doogie
>> Date: Fri Apr 17 05:52:32 2015
>> New Revision: 1674216
>>
>> URL: http://svn.apache.org/r1674216 
>> Log:
>> Well, this is the start of converting ofbiz to use maven for building
>> and packaging. There's a workable parent-pom, and I have converted
>> framework/start to maven as well. To use this, the following commands
>> are useful:
>>
>> * mvn clean
>> * mvn compile
>> * mvn package
>>
>> All 3 can be run in either ${ofbiz.home.dir}, or in framework/start.
>> The trick that made this simple, was that I was able to redefine maven's
>> default file layout away from src/main/java and target/*, to something
>> more ofbiz specific. This way of doing things is just to get things
>> going; eventually, we should adopt a more standard maven like layout.
>>
>> Another thing not dealt with in these first 2 files, is downloading of
>> dependencies. The top-level and framework/start have no external
>> requirements, so it allowed me to get going quite quickly.
>>
>> Added:
>> ofbiz/trunk/framework/start/pom.xml
>> ofbiz/trunk/pom.xml
>>
>> Added: ofbiz/trunk/framework/start/pom.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/pom.xml?rev=1674216&view=auto 
>> ==============================================================================
>> --- ofbiz/trunk/framework/start/pom.xml (added)
>> +++ ofbiz/trunk/framework/start/pom.xml Fri Apr 17 05:52:32 2015
>> @@ -0,0 +1,69 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<!--
>> +Licensed to the Apache Software Foundation (ASF) under one
>> +or more contributor license agreements. See the NOTICE file
>> +distributed with this work for additional information
>> +regarding copyright ownership. The ASF licenses this file
>> +to you under the Apache License, Version 2.0 (the
>> +"License"); you may not use this file except in compliance
>> +with the License. You may obtain a copy of the License at
>> +
>> +http://www.apache.org/licenses/LICENSE-2.0 
>> +
>> +Unless required by applicable law or agreed to in writing,
>> +software distributed under the License is distributed on an
>> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> +KIND, either express or implied. See the License for the
>> +specific language governing permissions and limitations
>> +under the License.
>> +-->
>> +
>> +<project>
>> + <parent>
>> + <groupId>org.apache.ofbiz</groupId>
>> + <artifactId>ofbiz-parent</artifactId>
>> + <version>TRUNK</version>
>> + <relativePath>../../pom.xml</relativePath>
>> + </parent>
>> + <modelVersion>4.0.0</modelVersion>
>> + <artifactId>ofbiz-start</artifactId>
>> +
>> + <build>
>> + <finalName>ofbiz</finalName>
>> + <plugins>
>> + <plugin>
>> + <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-jar-plugin</artifactId>
>> + <configuration>
>> + <archive>
>> + <manifestEntries>
>> + <Manifest-Version>1.0</Manifest-Version>
>> + <Implementation-Title>Apache OFBiz Startup</Implementation-Title>
>> + <Implementation-Vendor>The Apache Open for Business Project</Implementation-Vendor>
>> + <Main-Class>org.ofbiz.base.start.Start</Main-Class>
>> + </manifestEntries>
>> + </archive>
>> + </configuration>
>> + </plugin>
>> + <plugin>
>> + <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-antrun-plugin</artifactId>
>> + <executions>
>> + <execution>
>> + <phase>package</phase>
>> + <configuration>
>> + <tasks>
>> + <copy todir="${project.parent.relativePath}/..">
>> + <fileset dir="${project.build.directory}" includes="ofbiz.jar"/>
>> + </copy>
>> + </tasks>
>> + </configuration>
>> + <goals>
>> + <goal>run</goal>
>> + </goals>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + </plugins>
>> + </build>
>> +</project>
>>
>> Added: ofbiz/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/pom.xml?rev=1674216&view=auto 
>> ==============================================================================
>> --- ofbiz/trunk/pom.xml (added)
>> +++ ofbiz/trunk/pom.xml Fri Apr 17 05:52:32 2015
>> @@ -0,0 +1,76 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<!--
>> +Licensed to the Apache Software Foundation (ASF) under one
>> +or more contributor license agreements. See the NOTICE file
>> +distributed with this work for additional information
>> +regarding copyright ownership. The ASF licenses this file
>> +to you under the Apache License, Version 2.0 (the
>> +"License"); you may not use this file except in compliance
>> +with the License. You may obtain a copy of the License at
>> +
>> +http://www.apache.org/licenses/LICENSE-2.0 
>> +
>> +Unless required by applicable law or agreed to in writing,
>> +software distributed under the License is distributed on an
>> +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> +KIND, either express or implied. See the License for the
>> +specific language governing permissions and limitations
>> +under the License.
>> +-->
>> +
>> +<project>
>> + <modelVersion>4.0.0</modelVersion>
>> + <groupId>org.apache.ofbiz</groupId>
>> + <artifactId>ofbiz-parent</artifactId>
>> + <version>TRUNK</version>
>> + <packaging>pom</packaging>
>> +
>> + <build>
>> + <directory>build/lib</directory>
>> + <outputDirectory>build/classes</outputDirectory>
>> + <finalName>${artifactId}</finalName>
>> + <sourceDirectory>src</sourceDirectory>
>> + <resources>
>> + <resource>
>> + <directory>src</directory>
>> + <includes>
>> + <include>**/*.properties</include>
>> + <include>**/*.groovy</include>
>> + <include>**/*.xml</include>
>> + <include>**/*.bsh</include>
>> + <include>**/*.logic</include>
>> + <include>**/*.hs</include>
>> + <include>**/*.jacl</include>
>> + <include>**/*.py</include>
>> + <include>META-INF/**</include>
>> + </includes>
>> + </resource>
>> + <resource>
>> + <directory>${project.parent.relativePath}/..</directory>
>> + <includes>
>> + <include>LICENSE</include>
>> + <include>NOTICE</include>
>> + </includes>
>> + </resource>
>> + </resources>
>> + <scriptSourceDirectory>scripts</scriptSourceDirectory>
>> + <plugins>
>> + <plugin>
>> + <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-compiler-plugin</artifactId>
>> + <configuration>
>> + <source>1.7</source>
>> + <target>1.7</target>
>> + </configuration>
>> + </plugin>
>> + </plugins>
>> + </build>
>> +
>> + <reporting>
>> + <outputDirectory>target/site</outputDirectory>
>> + </reporting>
>> +
>> + <modules>
>> + <module>framework/start</module>
>> + </modules>
>> +</project>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Michael Brohl-3
In reply to this post by Jacques Le Roux
+1!

We should have very strong reasons to make this move.

Michael
ecomify.de

Am 17.04.15 um 10:35 schrieb Jacques Le Roux:

> After installing and setting last Maven version (3.3.1) this does not
> work well on Windows (I miss the maven-compiler-plugin I guess)
>
> Anyway I think we should really discuss before going in this direction.
> I, for instance, am strongly against moving to Maven when we have Ant
> already embedded and so friendly.
> Also I'd not like to have to move Maven related changes to Attic in a
> year or two because it's unfinished...
>
> tested: ant clean && mvn clean compile && ant start
>
> Jacques


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacopo Cappellato-5
In reply to this post by taher
On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:

> Hi All,
>
> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>
> Taher Alkhateeb

I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Pierre Smits
On Apr 17, 2015, at 3:35 AM, Jacques Le Roux <[hidden email]>
wrote:

> Anyway I think we should really discuss before going in this direction.

+1

So please revert this commit, before it is another dead weight.

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Adrian Crum-3
In reply to this post by Jacopo Cappellato-5
+1 for a discussion.

One of the things I despise about working with Commons Convert is the
labyrinth of Maven files and dependencies. It's a complicated black box
that I can't understand, and when something doesn't work, I don't know
how to fix it.

I hope OFBiz doesn't end up the same way.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:

> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>
>> Hi All,
>>
>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>>
>> Taher Alkhateeb
>
> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>
> Jacopo
>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator

Le 17/04/2015 13:44, Adrian Crum a écrit :
> +1 for a discussion.
>
> One of the things I despise about working with Commons Convert is the labyrinth of Maven files and dependencies. It's a complicated black box that I
> can't understand, and when something doesn't work, I don't know how to fix it.
>
> I hope OFBiz doesn't end up the same way.

Thanks to well express my opinion Adrian, same fear here!

Jacques

>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:
>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming
>>> language build system based on groovy.
>>>
>>> Taher Alkhateeb
>>
>> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could
>> actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>>
>> Jacopo
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-5
Le 17/04/2015 12:49, Jacopo Cappellato a écrit :

> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>
>> Hi All,
>>
>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>>
>> Taher Alkhateeb
> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>
> Jacopo
>

I don't know if Gradle is stable now, but I'd surely be for instead of Maven. If ever we really desire to move from Ant, I don't clearly see the
necessity at this stage...

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Nicolas Malin-2
In reply to this post by Adrian Crum-3
Same remarks :)

Maven would be interesting for some site project, but directly add on
the ofbiz projet root ...

Adam if you want use maven with OFBiz, maybe we can add a
tools/contrib.xml use by ant who can prepare OFBiz for a specific system
but not maintain by us.

Like this :
$ ant mvn
-> download pom.xml from sourcefore, github or another community forge

And with the same logical than specialpurpose, the crontrib.xml would be
not link by default on the ofbiz ant configuration

Nicolas

Le 17/04/2015 13:44, Adrian Crum a écrit :

> +1 for a discussion.
>
> One of the things I despise about working with Commons Convert is the
> labyrinth of Maven files and dependencies. It's a complicated black
> box that I can't understand, and when something doesn't work, I don't
> know how to fix it.
>
> I hope OFBiz doesn't end up the same way.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:
>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb
>> <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>> Thank you for your work but I thought we are more inclined to move
>>> to gradle based build systems given its many advantages as a full
>>> programming language build system based on groovy.
>>>
>>> Taher Alkhateeb
>>
>> I agree: we could explore the switch to Gradle and also review the
>> way our source files (Java, Groovy and Minilang/xml) are organized
>> (we could actually follow the layout that is considered the default
>> for Maven and Gradle and possibly other tools).
>>
>> Jacopo
>>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Martin Becker
In reply to this post by Jacques Le Roux
+1 for lack of benefit (and for fear ;-))


My first thoughts:

=> If a change is desired, than Gradle would surely be a good choice as it is the next generation build tool witch tries to combine the advantages from tools like ant, maven and others…

=> I think the stability of Gradle is not a question as it is used by projects like Spring, Hibernate, Grails, Groovy and others…

=> With the ability to use ant tasks and whole ant build scripts within Gradle, a smooth migration could be an option

=> Maven rely on it’s convention over configuration pattern, so it is never a good idea to NOT follow it’s conventions by configuring it for a different project structure for example. So there may be the need for massive changes to the OFBiz project structure and so on.

=> Also the ability to only produce one artifact per project in maven would perhaps end up in configuring sub projects for each application and module in OFBiz with a frustrating handling of multi module configurations with version-/release-tags, dependency handling and so on...

=> I used maven in multi module project setups before and it has it’s nice features, although it is sometimes hard to understand details and effects of the build lifecycle or single plugins. But the main fact is, that this were green-field projects, so things in terms of convention over configuration are much easier to adopt than in legacy projects like an OFBiz…

=> The change of the build tool for OFBiz would be a fundamental change, particularly for upgrading existing installations. So a change to the project structure could be a deathblow to OFBiz vendor imports in customer projects. I think it could be a good starting point to look at Gradle and see if there is a wise way to use the strength and new features of a modern build tool without the need to turn things inside out in OFBiz.


Martin Becker
ecomify GmbH



> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <[hidden email]>:
>
> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>>>
>>> Taher Alkhateeb
>> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>>
>> Jacopo
>>
>
> I don't know if Gradle is stable now, but I'd surely be for instead of Maven. If ever we really desire to move from Ant, I don't clearly see the necessity at this stage...
>
> Jacques
>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator
Le 17/04/2015 16:27, Martin Becker a écrit :
> => I think the stability of Gradle is not a question as it is used by projects like Spring, Hibernate, Grails, Groovy and others…

I mean the stability/differences between versions. I know some crossed (minor?) issues...

Jacques
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Jacques Le Roux
Administrator
In reply to this post by Martin Becker
Thanks for your detailed heads-up Martin, notably your last point!

I mostly agree, and indeed I also think Maven might not be so bad when you start anew (or are forced to use it ;) ) but for OFBiz, really NO!

Jacques

Le 17/04/2015 16:27, Martin Becker a écrit :

> +1 for lack of benefit (and for fear ;-))
>
>
> My first thoughts:
>
> => If a change is desired, than Gradle would surely be a good choice as it is the next generation build tool witch tries to combine the advantages from tools like ant, maven and others…
>
> => I think the stability of Gradle is not a question as it is used by projects like Spring, Hibernate, Grails, Groovy and others…
>
> => With the ability to use ant tasks and whole ant build scripts within Gradle, a smooth migration could be an option
>
> => Maven rely on it’s convention over configuration pattern, so it is never a good idea to NOT follow it’s conventions by configuring it for a different project structure for example. So there may be the need for massive changes to the OFBiz project structure and so on.
>
> => Also the ability to only produce one artifact per project in maven would perhaps end up in configuring sub projects for each application and module in OFBiz with a frustrating handling of multi module configurations with version-/release-tags, dependency handling and so on...
>
> => I used maven in multi module project setups before and it has it’s nice features, although it is sometimes hard to understand details and effects of the build lifecycle or single plugins. But the main fact is, that this were green-field projects, so things in terms of convention over configuration are much easier to adopt than in legacy projects like an OFBiz…
>
> => The change of the build tool for OFBiz would be a fundamental change, particularly for upgrading existing installations. So a change to the project structure could be a deathblow to OFBiz vendor imports in customer projects. I think it could be a good starting point to look at Gradle and see if there is a wise way to use the strength and new features of a modern build tool without the need to turn things inside out in OFBiz.
>
>
> Martin Becker
> ecomify GmbH
>
>
>
>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <[hidden email]>:
>>
>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>>>>
>>>> Taher Alkhateeb
>>> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>>>
>>> Jacopo
>>>
>> I don't know if Gradle is stable now, but I'd surely be for instead of Maven. If ever we really desire to move from Ant, I don't clearly see the necessity at this stage...
>>
>> Jacques
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Adam Heath-2

On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
> Thanks for your detailed heads-up Martin, notably your last point!
>
> I mostly agree, and indeed I also think Maven might not be so bad when
> you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>
> Jacques
>
> Le 17/04/2015 16:27, Martin Becker a écrit :
>> +1 for lack of benefit (and for fear ;-))

The commit I did last night took me 45 minutes.  Full stop.  I started
at 12:03am.  And I did it while drinking a second beer. Maven was that
simple.  I had resisted for years.  Years!  But when I actually sat down
to do it, I realized that I did *not* have to change what I was doing.  
Maven could be configured to work with the existing design.

The benefits are:

* not having to write our own build system; ant is not a build system.

* full external dependency management.  This can be done very
incrementally.  I just got framework/base to compile, by reusing the
previously downloaded jars in framework/base/lib.  Then, when all
dependencies are *properly* listed, we can switch to the download
mechanism, and suddenly, the checkout becomes smaller.

* full internal dependency support.  As part of framework/base now
having a working pom.xml, it has a dep on framework/start.  This can
allow for end-users wanting to just install applications/party, and
having just what is required get downloaded.

* Each ofbiz component could be moved to separate repos, and development
can progress on its own.  All that specialpurpose/* stuff no longer
needs to be carried along with the rest of the codebase.

* continuous integration becomes so much simpler; the standard "mvn
package" call does command-line unit tests, *by default*.

* these poms do not break anything.  Nothing calls them.  Everyone can
continue to use ant, eclipse, or DIP switches, to compile and run
ofbiz.  So, having them in trunk won't cause issue for anyone else.  
This is the way linux-kernel functions.  Completely new, isolated
features, that affect no one else, are added to master/linux-next, so
that they can get pushed out to more users, for more testing.  If
something is done in a separate branch, they have discovered it doesn't
recieve enough widespread testing.

>>
>>
>> My first thoughts:
>>
>> => If a change is desired, than Gradle would surely be a good choice
>> as it is the next generation build tool witch tries to combine the
>> advantages from tools like ant, maven and others…

Sure, why not?


Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
common.xml, but really, lets not go there.

>>
>> => I think the stability of Gradle is not a question as it is used by
>> projects like Spring, Hibernate, Grails, Groovy and others…
>>
>> => With the ability to use ant tasks and whole ant build scripts
>> within Gradle, a smooth migration could be an option
>>

Maven can call ant.  I'm even doing so in the 2 poms that I added.

>> => Maven rely on it’s convention over configuration pattern, so it is
>> never a good idea to NOT follow it’s conventions by configuring it
>> for a different project structure for example. So there may be the
>> need for massive changes to the OFBiz project structure and so on.
>>

I just got framework/base to compile with maven.  This includes *NO*
changes to ofbiz layout.  framework/base/lib still exists.  Nothing is
being downloaded(except maven plugins, of course).

>> => Also the ability to only produce one artifact per project in maven
>> would perhaps end up in configuring sub projects for each application
>> and module in OFBiz with a frustrating handling of multi module
>> configurations with version-/release-tags, dependency handling and so
>> on...
>>

This is wrong.  You can produce multiple artifacts.  I've seen it done
in other projects.

>> => I used maven in multi module project setups before and it has it’s
>> nice features, although it is sometimes hard to understand details
>> and effects of the build lifecycle or single plugins. But the main
>> fact is, that this were green-field projects, so things in terms of
>> convention over configuration are much easier to adopt than in legacy
>> projects like an OFBiz…
>>



>> => The change of the build tool for OFBiz would be a fundamental
>> change, particularly for upgrading existing installations. So a
>> change to the project structure could be a deathblow to OFBiz vendor
>> imports in customer projects. I think it could be a good starting
>> point to look at Gradle and see if there is a wise way to use the
>> strength and new features of a modern build tool without the need to
>> turn things inside out in OFBiz.
>>

I'm not just some noob in ofbiz.  I've been around for quite a bit. I've
been around when ofbiz was still using CVS.  I was the first to start
using git locally for ofbiz development, and for our own ofbiz
extensions/fixes/client work.  I've also been invovled with Debian in
years past, being involved in several migrations.  I also added
generics(and enhanced for loops, etc), to *all* of framework, to
spearhead that project.  But seriously, moving on.

But, what structure changes have I propsed?  None.  I've got it working
with the exsting layout.  Nothing has turned inside out.

>>
>> Martin Becker
>> ecomify GmbH
>>
>>
>>
>>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux
>>> <[hidden email]>:
>>>
>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb
>>>> <[hidden email]> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Thank you for your work but I thought we are more inclined to move
>>>>> to gradle based build systems given its many advantages as a full
>>>>> programming language build system based on groovy.
>>>>>
>>>>> Taher Alkhateeb
>>>> I agree: we could explore the switch to Gradle and also review the
>>>> way our source files (Java, Groovy and Minilang/xml) are organized
>>>> (we could actually follow the layout that is considered the default
>>>> for Maven and Gradle and possibly other tools).
>>>>
>>>> Jacopo
>>>>
>>> I don't know if Gradle is stable now, but I'd surely be for instead
>>> of Maven. If ever we really desire to move from Ant, I don't clearly
>>> see the necessity at this stage...
>>>
>>> Jacques
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Pierre Smits
Full external dependency management relates to something I proposed already
in the beginning of 2014, see
https://issues.apache.org/jira/browse/OFBIZ-5464

A proof of concept established that downloads could be downsized to approx
35 mb. Something that would not only be to the benefit of adopters of this
project and its works, but also the ASF.

Best regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Apr 17, 2015 at 7:41 PM, Adam Heath <[hidden email]> wrote:

>
> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>
>> Thanks for your detailed heads-up Martin, notably your last point!
>>
>> I mostly agree, and indeed I also think Maven might not be so bad when
>> you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>>
>> Jacques
>>
>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>
>>> +1 for lack of benefit (and for fear ;-))
>>>
>>
> The commit I did last night took me 45 minutes.  Full stop.  I started at
> 12:03am.  And I did it while drinking a second beer. Maven was that
> simple.  I had resisted for years.  Years!  But when I actually sat down to
> do it, I realized that I did *not* have to change what I was doing.  Maven
> could be configured to work with the existing design.
>
> The benefits are:
>
> * not having to write our own build system; ant is not a build system.
>
> * full external dependency management.  This can be done very
> incrementally.  I just got framework/base to compile, by reusing the
> previously downloaded jars in framework/base/lib.  Then, when all
> dependencies are *properly* listed, we can switch to the download
> mechanism, and suddenly, the checkout becomes smaller.
>
> * full internal dependency support.  As part of framework/base now having
> a working pom.xml, it has a dep on framework/start.  This can allow for
> end-users wanting to just install applications/party, and having just what
> is required get downloaded.
>
> * Each ofbiz component could be moved to separate repos, and development
> can progress on its own.  All that specialpurpose/* stuff no longer needs
> to be carried along with the rest of the codebase.
>
> * continuous integration becomes so much simpler; the standard "mvn
> package" call does command-line unit tests, *by default*.
>
> * these poms do not break anything.  Nothing calls them.  Everyone can
> continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
> So, having them in trunk won't cause issue for anyone else.  This is the
> way linux-kernel functions.  Completely new, isolated features, that affect
> no one else, are added to master/linux-next, so that they can get pushed
> out to more users, for more testing.  If something is done in a separate
> branch, they have discovered it doesn't recieve enough widespread testing.
>
>
>>>
>>> My first thoughts:
>>>
>>> => If a change is desired, than Gradle would surely be a good choice as
>>> it is the next generation build tool witch tries to combine the advantages
>>> from tools like ant, maven and others…
>>>
>>
> Sure, why not?
>
>
> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
> common.xml, but really, lets not go there.
>
>
>>> => I think the stability of Gradle is not a question as it is used by
>>> projects like Spring, Hibernate, Grails, Groovy and others…
>>>
>>> => With the ability to use ant tasks and whole ant build scripts within
>>> Gradle, a smooth migration could be an option
>>>
>>>
> Maven can call ant.  I'm even doing so in the 2 poms that I added.
>
>  => Maven rely on it’s convention over configuration pattern, so it is
>>> never a good idea to NOT follow it’s conventions by configuring it for a
>>> different project structure for example. So there may be the need for
>>> massive changes to the OFBiz project structure and so on.
>>>
>>>
> I just got framework/base to compile with maven.  This includes *NO*
> changes to ofbiz layout.  framework/base/lib still exists.  Nothing is
> being downloaded(except maven plugins, of course).
>
>  => Also the ability to only produce one artifact per project in maven
>>> would perhaps end up in configuring sub projects for each application and
>>> module in OFBiz with a frustrating handling of multi module configurations
>>> with version-/release-tags, dependency handling and so on...
>>>
>>>
> This is wrong.  You can produce multiple artifacts.  I've seen it done in
> other projects.
>
>  => I used maven in multi module project setups before and it has it’s
>>> nice features, although it is sometimes hard to understand details and
>>> effects of the build lifecycle or single plugins. But the main fact is,
>>> that this were green-field projects, so things in terms of convention over
>>> configuration are much easier to adopt than in legacy projects like an
>>> OFBiz…
>>>
>>>
>
>
>  => The change of the build tool for OFBiz would be a fundamental change,
>>> particularly for upgrading existing installations. So a change to the
>>> project structure could be a deathblow to OFBiz vendor imports in customer
>>> projects. I think it could be a good starting point to look at Gradle and
>>> see if there is a wise way to use the strength and new features of a modern
>>> build tool without the need to turn things inside out in OFBiz.
>>>
>>>
> I'm not just some noob in ofbiz.  I've been around for quite a bit. I've
> been around when ofbiz was still using CVS.  I was the first to start using
> git locally for ofbiz development, and for our own ofbiz
> extensions/fixes/client work.  I've also been invovled with Debian in years
> past, being involved in several migrations.  I also added generics(and
> enhanced for loops, etc), to *all* of framework, to spearhead that
> project.  But seriously, moving on.
>
> But, what structure changes have I propsed?  None.  I've got it working
> with the exsting layout.  Nothing has turned inside out.
>
>
>
>>> Martin Becker
>>> ecomify GmbH
>>>
>>>
>>>
>>>  Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <
>>>> [hidden email]>:
>>>>
>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>
>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>  Hi All,
>>>>>>
>>>>>> Thank you for your work but I thought we are more inclined to move to
>>>>>> gradle based build systems given its many advantages as a full programming
>>>>>> language build system based on groovy.
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>> I agree: we could explore the switch to Gradle and also review the way
>>>>> our source files (Java, Groovy and Minilang/xml) are organized (we could
>>>>> actually follow the layout that is considered the default for Maven and
>>>>> Gradle and possibly other tools).
>>>>>
>>>>> Jacopo
>>>>>
>>>>>  I don't know if Gradle is stable now, but I'd surely be for instead
>>>> of Maven. If ever we really desire to move from Ant, I don't clearly see
>>>> the necessity at this stage...
>>>>
>>>> Jacques
>>>>
>>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

hans_bakker
In reply to this post by Adam Heath-2
We should seriously consider the comments from Adam and move to maven.

Regards,
Hans
antwebsystems.com


On 18/04/15 00:41, Adam Heath wrote:

>
> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>> Thanks for your detailed heads-up Martin, notably your last point!
>>
>> I mostly agree, and indeed I also think Maven might not be so bad
>> when you start anew (or are forced to use it ;) ) but for OFBiz,
>> really NO!
>>
>> Jacques
>>
>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>> +1 for lack of benefit (and for fear ;-))
>
> The commit I did last night took me 45 minutes.  Full stop.  I started
> at 12:03am.  And I did it while drinking a second beer. Maven was that
> simple.  I had resisted for years.  Years!  But when I actually sat
> down to do it, I realized that I did *not* have to change what I was
> doing.  Maven could be configured to work with the existing design.
>
> The benefits are:
>
> * not having to write our own build system; ant is not a build system.
>
> * full external dependency management.  This can be done very
> incrementally.  I just got framework/base to compile, by reusing the
> previously downloaded jars in framework/base/lib.  Then, when all
> dependencies are *properly* listed, we can switch to the download
> mechanism, and suddenly, the checkout becomes smaller.
>
> * full internal dependency support.  As part of framework/base now
> having a working pom.xml, it has a dep on framework/start.  This can
> allow for end-users wanting to just install applications/party, and
> having just what is required get downloaded.
>
> * Each ofbiz component could be moved to separate repos, and
> development can progress on its own.  All that specialpurpose/* stuff
> no longer needs to be carried along with the rest of the codebase.
>
> * continuous integration becomes so much simpler; the standard "mvn
> package" call does command-line unit tests, *by default*.
>
> * these poms do not break anything.  Nothing calls them.  Everyone can
> continue to use ant, eclipse, or DIP switches, to compile and run
> ofbiz.  So, having them in trunk won't cause issue for anyone else.  
> This is the way linux-kernel functions.  Completely new, isolated
> features, that affect no one else, are added to master/linux-next, so
> that they can get pushed out to more users, for more testing.  If
> something is done in a separate branch, they have discovered it
> doesn't recieve enough widespread testing.
>
>>>
>>>
>>> My first thoughts:
>>>
>>> => If a change is desired, than Gradle would surely be a good choice
>>> as it is the next generation build tool witch tries to combine the
>>> advantages from tools like ant, maven and others…
>
> Sure, why not?
>
>
> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
> common.xml, but really, lets not go there.
>
>>>
>>> => I think the stability of Gradle is not a question as it is used
>>> by projects like Spring, Hibernate, Grails, Groovy and others…
>>>
>>> => With the ability to use ant tasks and whole ant build scripts
>>> within Gradle, a smooth migration could be an option
>>>
>
> Maven can call ant.  I'm even doing so in the 2 poms that I added.
>
>>> => Maven rely on it’s convention over configuration pattern, so it
>>> is never a good idea to NOT follow it’s conventions by configuring
>>> it for a different project structure for example. So there may be
>>> the need for massive changes to the OFBiz project structure and so on.
>>>
>
> I just got framework/base to compile with maven.  This includes *NO*
> changes to ofbiz layout.  framework/base/lib still exists. Nothing is
> being downloaded(except maven plugins, of course).
>
>>> => Also the ability to only produce one artifact per project in
>>> maven would perhaps end up in configuring sub projects for each
>>> application and module in OFBiz with a frustrating handling of multi
>>> module configurations with version-/release-tags, dependency
>>> handling and so on...
>>>
>
> This is wrong.  You can produce multiple artifacts.  I've seen it done
> in other projects.
>
>>> => I used maven in multi module project setups before and it has
>>> it’s nice features, although it is sometimes hard to understand
>>> details and effects of the build lifecycle or single plugins. But
>>> the main fact is, that this were green-field projects, so things in
>>> terms of convention over configuration are much easier to adopt than
>>> in legacy projects like an OFBiz…
>>>
>
>
>
>>> => The change of the build tool for OFBiz would be a fundamental
>>> change, particularly for upgrading existing installations. So a
>>> change to the project structure could be a deathblow to OFBiz vendor
>>> imports in customer projects. I think it could be a good starting
>>> point to look at Gradle and see if there is a wise way to use the
>>> strength and new features of a modern build tool without the need to
>>> turn things inside out in OFBiz.
>>>
>
> I'm not just some noob in ofbiz.  I've been around for quite a bit.
> I've been around when ofbiz was still using CVS.  I was the first to
> start using git locally for ofbiz development, and for our own ofbiz
> extensions/fixes/client work.  I've also been invovled with Debian in
> years past, being involved in several migrations.  I also added
> generics(and enhanced for loops, etc), to *all* of framework, to
> spearhead that project.  But seriously, moving on.
>
> But, what structure changes have I propsed?  None.  I've got it
> working with the exsting layout.  Nothing has turned inside out.
>
>>>
>>> Martin Becker
>>> ecomify GmbH
>>>
>>>
>>>
>>>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux
>>>> <[hidden email]>:
>>>>
>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Thank you for your work but I thought we are more inclined to
>>>>>> move to gradle based build systems given its many advantages as a
>>>>>> full programming language build system based on groovy.
>>>>>>
>>>>>> Taher Alkhateeb
>>>>> I agree: we could explore the switch to Gradle and also review the
>>>>> way our source files (Java, Groovy and Minilang/xml) are organized
>>>>> (we could actually follow the layout that is considered the
>>>>> default for Maven and Gradle and possibly other tools).
>>>>>
>>>>> Jacopo
>>>>>
>>>> I don't know if Gradle is stable now, but I'd surely be for instead
>>>> of Maven. If ever we really desire to move from Ant, I don't
>>>> clearly see the necessity at this stage...
>>>>
>>>> Jacques
>>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Pierre Smits
Ant + IVY delivers as much dependency management functionality as maven
does.

Maven is good for building jar solutions. We don't build jar solutions. We
exploit jars!

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 7:51 AM, Hans Bakker <[hidden email]>
wrote:

> We should seriously consider the comments from Adam and move to maven.
>
> Regards,
> Hans
> antwebsystems.com
>
>
> On 18/04/15 00:41, Adam Heath wrote:
>
>>
>> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>>
>>> Thanks for your detailed heads-up Martin, notably your last point!
>>>
>>> I mostly agree, and indeed I also think Maven might not be so bad when
>>> you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>>>
>>> Jacques
>>>
>>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>>
>>>> +1 for lack of benefit (and for fear ;-))
>>>>
>>>
>> The commit I did last night took me 45 minutes.  Full stop.  I started at
>> 12:03am.  And I did it while drinking a second beer. Maven was that
>> simple.  I had resisted for years.  Years!  But when I actually sat down to
>> do it, I realized that I did *not* have to change what I was doing.  Maven
>> could be configured to work with the existing design.
>>
>> The benefits are:
>>
>> * not having to write our own build system; ant is not a build system.
>>
>> * full external dependency management.  This can be done very
>> incrementally.  I just got framework/base to compile, by reusing the
>> previously downloaded jars in framework/base/lib.  Then, when all
>> dependencies are *properly* listed, we can switch to the download
>> mechanism, and suddenly, the checkout becomes smaller.
>>
>> * full internal dependency support.  As part of framework/base now having
>> a working pom.xml, it has a dep on framework/start.  This can allow for
>> end-users wanting to just install applications/party, and having just what
>> is required get downloaded.
>>
>> * Each ofbiz component could be moved to separate repos, and development
>> can progress on its own.  All that specialpurpose/* stuff no longer needs
>> to be carried along with the rest of the codebase.
>>
>> * continuous integration becomes so much simpler; the standard "mvn
>> package" call does command-line unit tests, *by default*.
>>
>> * these poms do not break anything.  Nothing calls them.  Everyone can
>> continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
>> So, having them in trunk won't cause issue for anyone else.  This is the
>> way linux-kernel functions.  Completely new, isolated features, that affect
>> no one else, are added to master/linux-next, so that they can get pushed
>> out to more users, for more testing.  If something is done in a separate
>> branch, they have discovered it doesn't recieve enough widespread testing.
>>
>>
>>>>
>>>> My first thoughts:
>>>>
>>>> => If a change is desired, than Gradle would surely be a good choice as
>>>> it is the next generation build tool witch tries to combine the advantages
>>>> from tools like ant, maven and others…
>>>>
>>>
>> Sure, why not?
>>
>>
>> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
>> common.xml, but really, lets not go there.
>>
>>
>>>> => I think the stability of Gradle is not a question as it is used by
>>>> projects like Spring, Hibernate, Grails, Groovy and others…
>>>>
>>>> => With the ability to use ant tasks and whole ant build scripts within
>>>> Gradle, a smooth migration could be an option
>>>>
>>>>
>> Maven can call ant.  I'm even doing so in the 2 poms that I added.
>>
>>  => Maven rely on it’s convention over configuration pattern, so it is
>>>> never a good idea to NOT follow it’s conventions by configuring it for a
>>>> different project structure for example. So there may be the need for
>>>> massive changes to the OFBiz project structure and so on.
>>>>
>>>>
>> I just got framework/base to compile with maven.  This includes *NO*
>> changes to ofbiz layout.  framework/base/lib still exists. Nothing is being
>> downloaded(except maven plugins, of course).
>>
>>  => Also the ability to only produce one artifact per project in maven
>>>> would perhaps end up in configuring sub projects for each application and
>>>> module in OFBiz with a frustrating handling of multi module configurations
>>>> with version-/release-tags, dependency handling and so on...
>>>>
>>>>
>> This is wrong.  You can produce multiple artifacts.  I've seen it done in
>> other projects.
>>
>>  => I used maven in multi module project setups before and it has it’s
>>>> nice features, although it is sometimes hard to understand details and
>>>> effects of the build lifecycle or single plugins. But the main fact is,
>>>> that this were green-field projects, so things in terms of convention over
>>>> configuration are much easier to adopt than in legacy projects like an
>>>> OFBiz…
>>>>
>>>>
>>
>>
>>  => The change of the build tool for OFBiz would be a fundamental change,
>>>> particularly for upgrading existing installations. So a change to the
>>>> project structure could be a deathblow to OFBiz vendor imports in customer
>>>> projects. I think it could be a good starting point to look at Gradle and
>>>> see if there is a wise way to use the strength and new features of a modern
>>>> build tool without the need to turn things inside out in OFBiz.
>>>>
>>>>
>> I'm not just some noob in ofbiz.  I've been around for quite a bit. I've
>> been around when ofbiz was still using CVS.  I was the first to start using
>> git locally for ofbiz development, and for our own ofbiz
>> extensions/fixes/client work.  I've also been invovled with Debian in years
>> past, being involved in several migrations.  I also added generics(and
>> enhanced for loops, etc), to *all* of framework, to spearhead that
>> project.  But seriously, moving on.
>>
>> But, what structure changes have I propsed?  None.  I've got it working
>> with the exsting layout.  Nothing has turned inside out.
>>
>>
>>>> Martin Becker
>>>> ecomify GmbH
>>>>
>>>>
>>>>
>>>>  Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <
>>>>> [hidden email]>:
>>>>>
>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>
>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>  Hi All,
>>>>>>>
>>>>>>> Thank you for your work but I thought we are more inclined to move
>>>>>>> to gradle based build systems given its many advantages as a full
>>>>>>> programming language build system based on groovy.
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>> I agree: we could explore the switch to Gradle and also review the
>>>>>> way our source files (Java, Groovy and Minilang/xml) are organized (we
>>>>>> could actually follow the layout that is considered the default for Maven
>>>>>> and Gradle and possibly other tools).
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>  I don't know if Gradle is stable now, but I'd surely be for instead
>>>>> of Maven. If ever we really desire to move from Ant, I don't clearly see
>>>>> the necessity at this stage...
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>
>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Pierre Smits
Ant + IVY are a better fit for the OFBiz.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 1:02 PM, Pierre Smits <[hidden email]>
wrote:

> Ant + IVY delivers as much dependency management functionality as maven
> does.
>
> Maven is good for building jar solutions. We don't build jar solutions. We
> exploit jars!
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 7:51 AM, Hans Bakker <
> [hidden email]> wrote:
>
>> We should seriously consider the comments from Adam and move to maven.
>>
>> Regards,
>> Hans
>> antwebsystems.com
>>
>>
>> On 18/04/15 00:41, Adam Heath wrote:
>>
>>>
>>> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>>>
>>>> Thanks for your detailed heads-up Martin, notably your last point!
>>>>
>>>> I mostly agree, and indeed I also think Maven might not be so bad when
>>>> you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>>>>
>>>> Jacques
>>>>
>>>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>>>
>>>>> +1 for lack of benefit (and for fear ;-))
>>>>>
>>>>
>>> The commit I did last night took me 45 minutes.  Full stop.  I started
>>> at 12:03am.  And I did it while drinking a second beer. Maven was that
>>> simple.  I had resisted for years.  Years!  But when I actually sat down to
>>> do it, I realized that I did *not* have to change what I was doing.  Maven
>>> could be configured to work with the existing design.
>>>
>>> The benefits are:
>>>
>>> * not having to write our own build system; ant is not a build system.
>>>
>>> * full external dependency management.  This can be done very
>>> incrementally.  I just got framework/base to compile, by reusing the
>>> previously downloaded jars in framework/base/lib.  Then, when all
>>> dependencies are *properly* listed, we can switch to the download
>>> mechanism, and suddenly, the checkout becomes smaller.
>>>
>>> * full internal dependency support.  As part of framework/base now
>>> having a working pom.xml, it has a dep on framework/start.  This can allow
>>> for end-users wanting to just install applications/party, and having just
>>> what is required get downloaded.
>>>
>>> * Each ofbiz component could be moved to separate repos, and development
>>> can progress on its own.  All that specialpurpose/* stuff no longer needs
>>> to be carried along with the rest of the codebase.
>>>
>>> * continuous integration becomes so much simpler; the standard "mvn
>>> package" call does command-line unit tests, *by default*.
>>>
>>> * these poms do not break anything.  Nothing calls them.  Everyone can
>>> continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
>>> So, having them in trunk won't cause issue for anyone else.  This is the
>>> way linux-kernel functions.  Completely new, isolated features, that affect
>>> no one else, are added to master/linux-next, so that they can get pushed
>>> out to more users, for more testing.  If something is done in a separate
>>> branch, they have discovered it doesn't recieve enough widespread testing.
>>>
>>>
>>>>>
>>>>> My first thoughts:
>>>>>
>>>>> => If a change is desired, than Gradle would surely be a good choice
>>>>> as it is the next generation build tool witch tries to combine the
>>>>> advantages from tools like ant, maven and others…
>>>>>
>>>>
>>> Sure, why not?
>>>
>>>
>>> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
>>> common.xml, but really, lets not go there.
>>>
>>>
>>>>> => I think the stability of Gradle is not a question as it is used by
>>>>> projects like Spring, Hibernate, Grails, Groovy and others…
>>>>>
>>>>> => With the ability to use ant tasks and whole ant build scripts
>>>>> within Gradle, a smooth migration could be an option
>>>>>
>>>>>
>>> Maven can call ant.  I'm even doing so in the 2 poms that I added.
>>>
>>>  => Maven rely on it’s convention over configuration pattern, so it is
>>>>> never a good idea to NOT follow it’s conventions by configuring it for a
>>>>> different project structure for example. So there may be the need for
>>>>> massive changes to the OFBiz project structure and so on.
>>>>>
>>>>>
>>> I just got framework/base to compile with maven.  This includes *NO*
>>> changes to ofbiz layout.  framework/base/lib still exists. Nothing is being
>>> downloaded(except maven plugins, of course).
>>>
>>>  => Also the ability to only produce one artifact per project in maven
>>>>> would perhaps end up in configuring sub projects for each application and
>>>>> module in OFBiz with a frustrating handling of multi module configurations
>>>>> with version-/release-tags, dependency handling and so on...
>>>>>
>>>>>
>>> This is wrong.  You can produce multiple artifacts.  I've seen it done
>>> in other projects.
>>>
>>>  => I used maven in multi module project setups before and it has it’s
>>>>> nice features, although it is sometimes hard to understand details and
>>>>> effects of the build lifecycle or single plugins. But the main fact is,
>>>>> that this were green-field projects, so things in terms of convention over
>>>>> configuration are much easier to adopt than in legacy projects like an
>>>>> OFBiz…
>>>>>
>>>>>
>>>
>>>
>>>  => The change of the build tool for OFBiz would be a fundamental
>>>>> change, particularly for upgrading existing installations. So a change to
>>>>> the project structure could be a deathblow to OFBiz vendor imports in
>>>>> customer projects. I think it could be a good starting point to look at
>>>>> Gradle and see if there is a wise way to use the strength and new features
>>>>> of a modern build tool without the need to turn things inside out in OFBiz.
>>>>>
>>>>>
>>> I'm not just some noob in ofbiz.  I've been around for quite a bit. I've
>>> been around when ofbiz was still using CVS.  I was the first to start using
>>> git locally for ofbiz development, and for our own ofbiz
>>> extensions/fixes/client work.  I've also been invovled with Debian in years
>>> past, being involved in several migrations.  I also added generics(and
>>> enhanced for loops, etc), to *all* of framework, to spearhead that
>>> project.  But seriously, moving on.
>>>
>>> But, what structure changes have I propsed?  None.  I've got it working
>>> with the exsting layout.  Nothing has turned inside out.
>>>
>>>
>>>>> Martin Becker
>>>>> ecomify GmbH
>>>>>
>>>>>
>>>>>
>>>>>  Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <
>>>>>> [hidden email]>:
>>>>>>
>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>
>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>  Hi All,
>>>>>>>>
>>>>>>>> Thank you for your work but I thought we are more inclined to move
>>>>>>>> to gradle based build systems given its many advantages as a full
>>>>>>>> programming language build system based on groovy.
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>> I agree: we could explore the switch to Gradle and also review the
>>>>>>> way our source files (Java, Groovy and Minilang/xml) are organized (we
>>>>>>> could actually follow the layout that is considered the default for Maven
>>>>>>> and Gradle and possibly other tools).
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>  I don't know if Gradle is stable now, but I'd surely be for instead
>>>>>> of Maven. If ever we really desire to move from Ant, I don't clearly see
>>>>>> the necessity at this stage...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

David E. Jones-2
In reply to this post by hans_bakker

Not to muddy the waters... but Gradle might be a good alternative. There is a lot more in it than Ant that "just works" without needing to be explicit, especially when you follow Maven conventions for layout of src directories.

One big upside of Gradle is that all build files are Groovy scripts and you can do pretty much anything in them. One downside is the learning curve... there is an extensive DSL with pretty good documentation, but some things that would seem simple are non-obvious (to put it generously). On the other hand, there is fairly wide use so I still have yet to run anything where I couldn't find a solution quickly with a google search.

-David


> On 19 Apr 2015, at 22:51, Hans Bakker <[hidden email]> wrote:
>
> We should seriously consider the comments from Adam and move to maven.
>
> Regards,
> Hans
> antwebsystems.com
>
>
> On 18/04/15 00:41, Adam Heath wrote:
>>
>> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>>> Thanks for your detailed heads-up Martin, notably your last point!
>>>
>>> I mostly agree, and indeed I also think Maven might not be so bad when you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>>>
>>> Jacques
>>>
>>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>>> +1 for lack of benefit (and for fear ;-))
>>
>> The commit I did last night took me 45 minutes.  Full stop.  I started at 12:03am.  And I did it while drinking a second beer. Maven was that simple.  I had resisted for years.  Years!  But when I actually sat down to do it, I realized that I did *not* have to change what I was doing.  Maven could be configured to work with the existing design.
>>
>> The benefits are:
>>
>> * not having to write our own build system; ant is not a build system.
>>
>> * full external dependency management.  This can be done very incrementally.  I just got framework/base to compile, by reusing the previously downloaded jars in framework/base/lib.  Then, when all dependencies are *properly* listed, we can switch to the download mechanism, and suddenly, the checkout becomes smaller.
>>
>> * full internal dependency support.  As part of framework/base now having a working pom.xml, it has a dep on framework/start.  This can allow for end-users wanting to just install applications/party, and having just what is required get downloaded.
>>
>> * Each ofbiz component could be moved to separate repos, and development can progress on its own.  All that specialpurpose/* stuff no longer needs to be carried along with the rest of the codebase.
>>
>> * continuous integration becomes so much simpler; the standard "mvn package" call does command-line unit tests, *by default*.
>>
>> * these poms do not break anything.  Nothing calls them.  Everyone can continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.  So, having them in trunk won't cause issue for anyone else.  This is the way linux-kernel functions.  Completely new, isolated features, that affect no one else, are added to master/linux-next, so that they can get pushed out to more users, for more testing.  If something is done in a separate branch, they have discovered it doesn't recieve enough widespread testing.
>>
>>>>
>>>>
>>>> My first thoughts:
>>>>
>>>> => If a change is desired, than Gradle would surely be a good choice as it is the next generation build tool witch tries to combine the advantages from tools like ant, maven and others…
>>
>> Sure, why not?
>>
>>
>> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and common.xml, but really, lets not go there.
>>
>>>>
>>>> => I think the stability of Gradle is not a question as it is used by projects like Spring, Hibernate, Grails, Groovy and others…
>>>>
>>>> => With the ability to use ant tasks and whole ant build scripts within Gradle, a smooth migration could be an option
>>>>
>>
>> Maven can call ant.  I'm even doing so in the 2 poms that I added.
>>
>>>> => Maven rely on it’s convention over configuration pattern, so it is never a good idea to NOT follow it’s conventions by configuring it for a different project structure for example. So there may be the need for massive changes to the OFBiz project structure and so on.
>>>>
>>
>> I just got framework/base to compile with maven.  This includes *NO* changes to ofbiz layout.  framework/base/lib still exists. Nothing is being downloaded(except maven plugins, of course).
>>
>>>> => Also the ability to only produce one artifact per project in maven would perhaps end up in configuring sub projects for each application and module in OFBiz with a frustrating handling of multi module configurations with version-/release-tags, dependency handling and so on...
>>>>
>>
>> This is wrong.  You can produce multiple artifacts.  I've seen it done in other projects.
>>
>>>> => I used maven in multi module project setups before and it has it’s nice features, although it is sometimes hard to understand details and effects of the build lifecycle or single plugins. But the main fact is, that this were green-field projects, so things in terms of convention over configuration are much easier to adopt than in legacy projects like an OFBiz…
>>>>
>>
>>
>>
>>>> => The change of the build tool for OFBiz would be a fundamental change, particularly for upgrading existing installations. So a change to the project structure could be a deathblow to OFBiz vendor imports in customer projects. I think it could be a good starting point to look at Gradle and see if there is a wise way to use the strength and new features of a modern build tool without the need to turn things inside out in OFBiz.
>>>>
>>
>> I'm not just some noob in ofbiz.  I've been around for quite a bit. I've been around when ofbiz was still using CVS.  I was the first to start using git locally for ofbiz development, and for our own ofbiz extensions/fixes/client work.  I've also been invovled with Debian in years past, being involved in several migrations.  I also added generics(and enhanced for loops, etc), to *all* of framework, to spearhead that project.  But seriously, moving on.
>>
>> But, what structure changes have I propsed?  None.  I've got it working with the exsting layout.  Nothing has turned inside out.
>>
>>>>
>>>> Martin Becker
>>>> ecomify GmbH
>>>>
>>>>
>>>>
>>>>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <[hidden email]>:
>>>>>
>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming language build system based on groovy.
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>> I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>> I don't know if Gradle is stable now, but I'd surely be for instead of Maven. If ever we really desire to move from Ant, I don't clearly see the necessity at this stage...
>>>>>
>>>>> Jacques
>>>>>
>>>>
>>>>
>>
>

1234