You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2015/04/17 10:08:45 UTC
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
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, doogie@apache.org 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>
>
>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 17, 2015, at 3:35 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> Anyway I think we should really discuss before going in this direction.
+1
Jacopo
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Michael Brohl <mi...@ecomify.de>.
+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
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <sl...@gmail.com> 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
>>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Nicolas Malin <ni...@nereide.fr>.
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
>> <sl...@gmail.com> 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
>>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Adrian Crum <ad...@sandglass-software.com>.
+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 <sl...@gmail.com> 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
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@gmail.com>
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 <
> mailinglist@antwebsystems.com> 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 <
>>>>>> jacques.le.roux@les7arts.com>:
>>>>>>
>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>
>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>> slidingfilaments@gmail.com> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
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 <ma...@antwebsystems.com>
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 <
>>>>> jacques.le.roux@les7arts.com>:
>>>>>
>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>
>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>> slidingfilaments@gmail.com> 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
>>>>>
>>>>>
>>>>
>>>>
>>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Sharan-F <sh...@gmail.com>.
Hi All
A reminder that this is a public list and while I understand that there is a
lot of heated discussions happening here - the use of swearwords or bad
language is not acceptable.
Thanks
Sharan
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1674216-in-ofbiz-trunk-framework-start-pom-xml-pom-xml-tp4666698p4667055.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit:
r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Ean Schuessler <ea...@brainfood.com>.
> From: "David E. Jones" <de...@me.com>
> Subject: Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
> pom.xml
>
> This is an appeal to popularity, not utility.
I don't think we've proven that those fail to converge over time.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/22/2015 12:52 PM, David E. Jones wrote:
>> On 21 Apr 2015, at 14:17, Adam Heath <do...@brainfood.com> wrote:
>>
>> Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons.
>>
>> In google, search for maven, then gradle. See how many responses each one gets.
>>
>> Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say "apache ant" or "apache maven", and/or add java terms.
>>
>> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>>
>> After doing this, maven is still the right choice.
> This is an appeal to popularity, not utility.
Did further. Read what is linked from google(or your search engine of
choice). Just like code formatting can be a proxy to code quality, so
can search result count. But you still have to investigate, and maven
does seem to have higher community, support, etc.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 -
in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
> On 21 Apr 2015, at 14:17, Adam Heath <do...@brainfood.com> wrote:
>
> Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons.
>
> In google, search for maven, then gradle. See how many responses each one gets.
>
> Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say "apache ant" or "apache maven", and/or add java terms.
>
> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>
> After doing this, maven is still the right choice.
This is an appeal to popularity, not utility.
-David
Re: Long: Re: discussion: Move to Maven was:Re: svn commit:
r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 22/04/2015 00:03, Adam Heath a écrit :
>
> On 04/21/2015 04:30 PM, Jacques Le Roux wrote:
>> Le 21/04/2015 23:17, Adam Heath a écrit :
>>>
>>> On 04/21/2015 04:06 PM, Nicolas Malin wrote:
>>>> Le 21/04/2015 22:37, Adam Heath a écrit :
>>>>> My commit is not breaking anything. Why remove something that is harmless?
>>>>>
>>>>> Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original
>>>>> committer will have to do more work to re-add what was removed.
>>>> Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven
>>>> would be a good improvement.
>>>>
>>>> Only, Jacopo start a discussion to improve OFBiz with Gradle
>>>> http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell.
>>>> If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value.
>>>>
>>>> Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!)
>>>>
>>>
>>> Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons.
>>>
>>> In google, search for maven, then gradle. See how many responses each one gets.
>>>
>>> Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say "apache ant" or "apache maven", and/or add java
>>> terms.
>>>
>>> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>>>
>>> After doing this, maven is still the right choice.
>>>
>>>
>>>
>>
>> Quantity is not quality
>>
>
> That seems to be a bit of an abrupt statement. Do you have anything more substantive to say? Did you actually attempt to dig down into the
> suggestions I gave? Or was this a knee-jerk response to my attempt at actually investigating gradle?
>
It was just a lack of time, I was then just leaving for few days. I always had and still have a reluctance against statistics and the world it's
creating around us (think big data). There is of course sound aspects but I fear the humanity will suffer of it in the long term. It relates to my
experience in the context of IA where you have mostly 2 approaches: statistical vs logical (OK they are mixing/mixed now
http://en.wikipedia.org/wiki/Artificial_intelligence )
So yes was more a knee-jerk response :) I have still not enough time to expand and be totally clear. I hope from my digression above I guess you get
my point.
Jacques
Jacques
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 04:30 PM, Jacques Le Roux wrote:
> Le 21/04/2015 23:17, Adam Heath a écrit :
>>
>> On 04/21/2015 04:06 PM, Nicolas Malin wrote:
>>> Le 21/04/2015 22:37, Adam Heath a écrit :
>>>> My commit is not breaking anything. Why remove something that is
>>>> harmless?
>>>>
>>>> Let's be positive and forward enabling; if a commit is reverted,
>>>> then that reversion has not stopped any discussion, and now the
>>>> original committer will have to do more work to re-add what was
>>>> removed.
>>> Definitely, all commiter try to have a positive attitude to improve
>>> OFBiz. Your commit break nothing (on technical aspect), and I'm sure
>>> maven would be a good improvement.
>>>
>>> Only, Jacopo start a discussion to improve OFBiz with Gradle
>>> http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
>>> and adding pom.xml has an effect of bombshell. If you explain before
>>> on this thread that maven is better and why, your commit would be
>>> appreciate in its just value.
>>>
>>> Before your commit I had not idea on gradle or maven, but with my
>>> french mentality now I prefer Gradle ;) (completely not subjective!)
>>>
>>
>> Gradle is a non-starter. When I saw that mentioned, I actually did
>> do some comparisons.
>>
>> In google, search for maven, then gradle. See how many responses
>> each one gets.
>>
>> Then, go to trends.google.com, compare the above 2 items, and then
>> add ant. You might want to say "apache ant" or "apache maven",
>> and/or add java terms.
>>
>> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>>
>> After doing this, maven is still the right choice.
>>
>>
>>
>
> Quantity is not quality
>
That seems to be a bit of an abrupt statement. Do you have anything
more substantive to say? Did you actually attempt to dig down into the
suggestions I gave? Or was this a knee-jerk response to my attempt at
actually investigating gradle?
Re: Long: Re: discussion: Move to Maven was:Re: svn commit:
r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 23:17, Adam Heath a écrit :
>
> On 04/21/2015 04:06 PM, Nicolas Malin wrote:
>> Le 21/04/2015 22:37, Adam Heath a écrit :
>>> My commit is not breaking anything. Why remove something that is harmless?
>>>
>>> Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original
>>> committer will have to do more work to re-add what was removed.
>> Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven
>> would be a good improvement.
>>
>> Only, Jacopo start a discussion to improve OFBiz with Gradle
>> http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If
>> you explain before on this thread that maven is better and why, your commit would be appreciate in its just value.
>>
>> Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!)
>>
>
> Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons.
>
> In google, search for maven, then gradle. See how many responses each one gets.
>
> Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say "apache ant" or "apache maven", and/or add java
> terms.
>
> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>
> After doing this, maven is still the right choice.
>
>
>
Quantity is not quality
Jacques
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
As another point, you keep responding with attacks, instead of
discussing actual datapoints. I'm mentioning features, additions,
whatever, but I see nothing constructive from your direction.
Let's move back to a technical discussion, and can we have a stop of
this vitriol?
On 04/21/2015 05:12 PM, Adam Heath wrote:
>
> On 04/21/2015 04:27 PM, Pierre Smits wrote:
>> The discussion whether or not to switch is still ongoing, is still
>> undecided. You have made your choice. That is your prerogative. No one
>> within this community can deny you that. But you're forcing... Your
>> preference without consensus within/of the Community.
>>
>> You're actions don't match the responsibilities that come with the
>> privileges. Not those of a committer. Even less those of a PMC Member.
>
> Bother. You're really burning bridges here. Seriously. This is a
> personal attack from you. Go read the code of conduct that Jacopo
> posted. NOW!
>
> ps: as a history lesson, look who added java 1.5 generics, enhanced
> for-loop, and other new features, to *ALL* of the framework. That was
> all done without any kind of automatic tool. I typed in *every*
> *single* *one* of those lines. Just to state again, *ALL* of
> framework. And realize what that means.
>
> pps: Also, I have since filed an issue, and will be further commiting
> into a branch; so, your personal attacks aren't holding water.
>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 04:27 PM, Pierre Smits wrote:
> The discussion whether or not to switch is still ongoing, is still
> undecided. You have made your choice. That is your prerogative. No one
> within this community can deny you that. But you're forcing... Your
> preference without consensus within/of the Community.
>
> You're actions don't match the responsibilities that come with the
> privileges. Not those of a committer. Even less those of a PMC Member.
Bother. You're really burning bridges here. Seriously. This is a
personal attack from you. Go read the code of conduct that Jacopo
posted. NOW!
ps: as a history lesson, look who added java 1.5 generics, enhanced
for-loop, and other new features, to *ALL* of the framework. That was
all done without any kind of automatic tool. I typed in *every*
*single* *one* of those lines. Just to state again, *ALL* of
framework. And realize what that means.
pps: Also, I have since filed an issue, and will be further commiting
into a branch; so, your personal attacks aren't holding water.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
The discussion whether or not to switch is still ongoing, is still
undecided. You have made your choice. That is your prerogative. No one
within this community can deny you that. But you're forcing... Your
preference without consensus within/of the Community.
You're actions don't match the responsibilities that come with the
privileges. Not those of a committer. Even less those of a PMC Member.
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 Tue, Apr 21, 2015 at 11:17 PM, Adam Heath <do...@brainfood.com> wrote:
>
> On 04/21/2015 04:06 PM, Nicolas Malin wrote:
>
>> Le 21/04/2015 22:37, Adam Heath a écrit :
>>
>>> My commit is not breaking anything. Why remove something that is
>>> harmless?
>>>
>>> Let's be positive and forward enabling; if a commit is reverted, then
>>> that reversion has not stopped any discussion, and now the original
>>> committer will have to do more work to re-add what was removed.
>>>
>> Definitely, all commiter try to have a positive attitude to improve
>> OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven
>> would be a good improvement.
>>
>> Only, Jacopo start a discussion to improve OFBiz with Gradle
>> http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
>> and adding pom.xml has an effect of bombshell. If you explain before on
>> this thread that maven is better and why, your commit would be appreciate
>> in its just value.
>>
>> Before your commit I had not idea on gradle or maven, but with my french
>> mentality now I prefer Gradle ;) (completely not subjective!)
>>
>>
> Gradle is a non-starter. When I saw that mentioned, I actually did do
> some comparisons.
>
> In google, search for maven, then gradle. See how many responses each one
> gets.
>
> Then, go to trends.google.com, compare the above 2 items, and then add
> ant. You might want to say "apache ant" or "apache maven", and/or add java
> terms.
>
> Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
>
> After doing this, maven is still the right choice.
>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 04:06 PM, Nicolas Malin wrote:
> Le 21/04/2015 22:37, Adam Heath a écrit :
>> My commit is not breaking anything. Why remove something that is
>> harmless?
>>
>> Let's be positive and forward enabling; if a commit is reverted, then
>> that reversion has not stopped any discussion, and now the original
>> committer will have to do more work to re-add what was removed.
> Definitely, all commiter try to have a positive attitude to improve
> OFBiz. Your commit break nothing (on technical aspect), and I'm sure
> maven would be a good improvement.
>
> Only, Jacopo start a discussion to improve OFBiz with Gradle
> http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
> and adding pom.xml has an effect of bombshell. If you explain before
> on this thread that maven is better and why, your commit would be
> appreciate in its just value.
>
> Before your commit I had not idea on gradle or maven, but with my
> french mentality now I prefer Gradle ;) (completely not subjective!)
>
Gradle is a non-starter. When I saw that mentioned, I actually did do
some comparisons.
In google, search for maven, then gradle. See how many responses each
one gets.
Then, go to trends.google.com, compare the above 2 items, and then add
ant. You might want to say "apache ant" or "apache maven", and/or add
java terms.
Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".
After doing this, maven is still the right choice.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Nicolas Malin <ni...@nereide.fr>.
Le 21/04/2015 22:37, Adam Heath a écrit :
> My commit is not breaking anything. Why remove something that is
> harmless?
>
> Let's be positive and forward enabling; if a commit is reverted, then
> that reversion has not stopped any discussion, and now the original
> committer will have to do more work to re-add what was removed.
Definitely, all commiter try to have a positive attitude to improve
OFBiz. Your commit break nothing (on technical aspect), and I'm sure
maven would be a good improvement.
Only, Jacopo start a discussion to improve OFBiz with Gradle
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
and adding pom.xml has an effect of bombshell. If you explain before on
this thread that maven is better and why, your commit would be
appreciate in its just value.
Before your commit I had not idea on gradle or maven, but with my french
mentality now I prefer Gradle ;) (completely not subjective!)
You are a competent commiter but please community over the code.
Regards
Nicolas
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
Ron
On 22/04/2015 5:25 AM, Pierre Smits wrote:
> The Groovy/Gradle approach enables this project to bring build/dependency
> management regarding base applications and optionals (special
> purpose/outside ASF solutions) from the CLI to an application. Increasing
> the user experience of those who manage the implementation for their users.
> Leading to potentially more adopters.
>
> I don't care particularly for the argument of the trend projection (Maven
> vs Gradle vs ANT+IVY). That is based on an algorithm that pulls in all
> kinds of stuff. And whether that stuff is applicable to the needs of this
> project can't be determined.
>
> What I see happening in this thread (and others similarly related to the
> subject) is projection of favouritism (Apple vs Microsoft, BMW vs Mercedes,
> et all).
>
> We should first focus on the need of the project, build consensus before
> moving on. Having a dev branch filled with something to evaluate comes
> second.
>
> 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 Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits <pi...@gmail.com>
> wrote:
>
>> I already establised a working solution for better dependency management
>> based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
>> checkout at that time (35 MBs). And it seems with less effort/less
>> complexity than is now is being shown in the OFBIZ-6172 branch...
>>
>> I suggested a dev branch back then (
>> https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
>> evaluate. Unfortunately it didn't gather momentum at the time.
>>
>> Does that mean that it is a worse fit? I dare say: not!
>>
>>
>>
>>
>>
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
>> rwheeler@artifact-software.com> wrote:
>>
>>> Perhaps it would be a good idea for some of the key people to take a
>>> close look at what has been done.
>>>
>>> This is potentially a big step forward in modernizing the product.
>>>
>>> Having a working solution takes a lot of the FUD out of the discussion
>>> and allows the approach to be tested by the people who are building OFBiz
>>> every day.
>>>
>>> Even if it actually does everything that Adam claims and the consensus of
>>> the committers is to move to Maven, it will still be a good idea to support
>>> the 2 build methods until everyone important is ready to commit to Maven.
>>> It may take a while to get the Maven approach sold to everyone even if they
>>> know that at some point they will be forced to move. Some will be early
>>> adopters and some will be late but if you don't have to force everyone to
>>> move at once, it does make the transition easier.
>>>
>>> If it is the consensus that the Ant build is still better, the Maven
>>> stuff is easy to remove without damaging the Ant build.
>>>
>>> I suggest leaving it in until everyone who needs to test it before the
>>> decision is made, has a chance to test it.
>>> It is unreasonable to expect each of the committers to make their own
>>> Maven build to test the idea.
>>>
>>> Adam has saved us a lot of speculation about what it means to move to
>>> Maven.
>>>
>>> Give the supporters and skeptics some time to test before removing it.
>>>
>>> Ron
>>>
>>>
>>> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>>>
>>>> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>>>>
>>>> My commit is not breaking anything. Why remove something that is
>>>>> harmless?
>>>>>
>>>> Hi Adam,
>>>>
>>>> The fact that a commit is harmless is not enough for its approval.
>>>> I know that your commit doesn't cause any side effects and I appreciate
>>>> that you are now doing your work in a feature branch.
>>>> I am asking you to revert that commit to trunk not because its quality
>>>> is bad or I see potential issues but only because the decision about the
>>>> official build tool for the project must be taken by the community and we
>>>> are not planning to maintain more than one alternative options in the
>>>> official repository.
>>>> Just to make it super clear, I restate my request: please revert 1674216
>>>> (it is the only commit to trunk) then let's continue the work about Maven
>>>> in the release branch you have created.
>>>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>>>> vs ..." will go on and its outcome will determine the final decision; since
>>>> there are clearly different points of view for the different tools we all
>>>> have to be open to consider other's opinions: crystallized positions will
>>>> not help much in this context.
>>>> The branch you have created is valuable because it provides a reference
>>>> implementation for the discussion, but it is important that you appreciate
>>>> that it may not be merged into the project (based on the outcome of the
>>>> ongoing discussion).
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
Maven is only one of the alternatives that could be investigated.
It would be nice if the people who build OFBiz every day tried to use
Adam's solution before it is removed.
Is it as easy to test Ant+Ivy.
Ron
On 22/04/2015 5:13 AM, Pierre Smits wrote:
> I already establised a working solution for better dependency management
> based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
> checkout at that time (35 MBs). And it seems with less effort/less
> complexity than is now is being shown in the OFBIZ-6172 branch...
>
> I suggested a dev branch back then (
> https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
> evaluate. Unfortunately it didn't gather momentum at the time.
>
> Does that mean that it is a worse fit? I dare say: not!
>
>
>
>
>
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
> rwheeler@artifact-software.com> wrote:
>
>> Perhaps it would be a good idea for some of the key people to take a close
>> look at what has been done.
>>
>> This is potentially a big step forward in modernizing the product.
>>
>> Having a working solution takes a lot of the FUD out of the discussion and
>> allows the approach to be tested by the people who are building OFBiz every
>> day.
>>
>> Even if it actually does everything that Adam claims and the consensus of
>> the committers is to move to Maven, it will still be a good idea to support
>> the 2 build methods until everyone important is ready to commit to Maven.
>> It may take a while to get the Maven approach sold to everyone even if they
>> know that at some point they will be forced to move. Some will be early
>> adopters and some will be late but if you don't have to force everyone to
>> move at once, it does make the transition easier.
>>
>> If it is the consensus that the Ant build is still better, the Maven stuff
>> is easy to remove without damaging the Ant build.
>>
>> I suggest leaving it in until everyone who needs to test it before the
>> decision is made, has a chance to test it.
>> It is unreasonable to expect each of the committers to make their own
>> Maven build to test the idea.
>>
>> Adam has saved us a lot of speculation about what it means to move to
>> Maven.
>>
>> Give the supporters and skeptics some time to test before removing it.
>>
>> Ron
>>
>>
>> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>>
>>> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>> My commit is not breaking anything. Why remove something that is
>>>> harmless?
>>>>
>>> Hi Adam,
>>>
>>> The fact that a commit is harmless is not enough for its approval.
>>> I know that your commit doesn't cause any side effects and I appreciate
>>> that you are now doing your work in a feature branch.
>>> I am asking you to revert that commit to trunk not because its quality is
>>> bad or I see potential issues but only because the decision about the
>>> official build tool for the project must be taken by the community and we
>>> are not planning to maintain more than one alternative options in the
>>> official repository.
>>> Just to make it super clear, I restate my request: please revert 1674216
>>> (it is the only commit to trunk) then let's continue the work about Maven
>>> in the release branch you have created.
>>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>>> vs ..." will go on and its outcome will determine the final decision; since
>>> there are clearly different points of view for the different tools we all
>>> have to be open to consider other's opinions: crystallized positions will
>>> not help much in this context.
>>> The branch you have created is valuable because it provides a reference
>>> implementation for the discussion, but it is important that you appreciate
>>> that it may not be merged into the project (based on the outcome of the
>>> ongoing discussion).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
The Groovy/Gradle approach enables this project to bring build/dependency
management regarding base applications and optionals (special
purpose/outside ASF solutions) from the CLI to an application. Increasing
the user experience of those who manage the implementation for their users.
Leading to potentially more adopters.
I don't care particularly for the argument of the trend projection (Maven
vs Gradle vs ANT+IVY). That is based on an algorithm that pulls in all
kinds of stuff. And whether that stuff is applicable to the needs of this
project can't be determined.
What I see happening in this thread (and others similarly related to the
subject) is projection of favouritism (Apple vs Microsoft, BMW vs Mercedes,
et all).
We should first focus on the need of the project, build consensus before
moving on. Having a dev branch filled with something to evaluate comes
second.
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 Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits <pi...@gmail.com>
wrote:
> I already establised a working solution for better dependency management
> based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
> checkout at that time (35 MBs). And it seems with less effort/less
> complexity than is now is being shown in the OFBIZ-6172 branch...
>
> I suggested a dev branch back then (
> https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
> evaluate. Unfortunately it didn't gather momentum at the time.
>
> Does that mean that it is a worse fit? I dare say: not!
>
>
>
>
>
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
> rwheeler@artifact-software.com> wrote:
>
>> Perhaps it would be a good idea for some of the key people to take a
>> close look at what has been done.
>>
>> This is potentially a big step forward in modernizing the product.
>>
>> Having a working solution takes a lot of the FUD out of the discussion
>> and allows the approach to be tested by the people who are building OFBiz
>> every day.
>>
>> Even if it actually does everything that Adam claims and the consensus of
>> the committers is to move to Maven, it will still be a good idea to support
>> the 2 build methods until everyone important is ready to commit to Maven.
>> It may take a while to get the Maven approach sold to everyone even if they
>> know that at some point they will be forced to move. Some will be early
>> adopters and some will be late but if you don't have to force everyone to
>> move at once, it does make the transition easier.
>>
>> If it is the consensus that the Ant build is still better, the Maven
>> stuff is easy to remove without damaging the Ant build.
>>
>> I suggest leaving it in until everyone who needs to test it before the
>> decision is made, has a chance to test it.
>> It is unreasonable to expect each of the committers to make their own
>> Maven build to test the idea.
>>
>> Adam has saved us a lot of speculation about what it means to move to
>> Maven.
>>
>> Give the supporters and skeptics some time to test before removing it.
>>
>> Ron
>>
>>
>> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>>
>>> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>> My commit is not breaking anything. Why remove something that is
>>>> harmless?
>>>>
>>> Hi Adam,
>>>
>>> The fact that a commit is harmless is not enough for its approval.
>>> I know that your commit doesn't cause any side effects and I appreciate
>>> that you are now doing your work in a feature branch.
>>> I am asking you to revert that commit to trunk not because its quality
>>> is bad or I see potential issues but only because the decision about the
>>> official build tool for the project must be taken by the community and we
>>> are not planning to maintain more than one alternative options in the
>>> official repository.
>>> Just to make it super clear, I restate my request: please revert 1674216
>>> (it is the only commit to trunk) then let's continue the work about Maven
>>> in the release branch you have created.
>>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>>> vs ..." will go on and its outcome will determine the final decision; since
>>> there are clearly different points of view for the different tools we all
>>> have to be open to consider other's opinions: crystallized positions will
>>> not help much in this context.
>>> The branch you have created is valuable because it provides a reference
>>> implementation for the discussion, but it is important that you appreciate
>>> that it may not be merged into the project (based on the outcome of the
>>> ongoing discussion).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
In order to give the project the best basis for reaching a sound decision
(pro-con comparison between the three suggested angles - ant+ivy, gradle,
maven), we could just as easily create also dev branches for the other two
options and have proponents work on that so that these can also be
evaluated by all.
I am willing to work on the ant+ivy angle.
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 Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits <pi...@gmail.com>
wrote:
> I already establised a working solution for better dependency management
> based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
> checkout at that time (35 MBs). And it seems with less effort/less
> complexity than is now is being shown in the OFBIZ-6172 branch...
>
> I suggested a dev branch back then (
> https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
> evaluate. Unfortunately it didn't gather momentum at the time.
>
> Does that mean that it is a worse fit? I dare say: not!
>
>
>
>
>
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
> rwheeler@artifact-software.com> wrote:
>
>> Perhaps it would be a good idea for some of the key people to take a
>> close look at what has been done.
>>
>> This is potentially a big step forward in modernizing the product.
>>
>> Having a working solution takes a lot of the FUD out of the discussion
>> and allows the approach to be tested by the people who are building OFBiz
>> every day.
>>
>> Even if it actually does everything that Adam claims and the consensus of
>> the committers is to move to Maven, it will still be a good idea to support
>> the 2 build methods until everyone important is ready to commit to Maven.
>> It may take a while to get the Maven approach sold to everyone even if they
>> know that at some point they will be forced to move. Some will be early
>> adopters and some will be late but if you don't have to force everyone to
>> move at once, it does make the transition easier.
>>
>> If it is the consensus that the Ant build is still better, the Maven
>> stuff is easy to remove without damaging the Ant build.
>>
>> I suggest leaving it in until everyone who needs to test it before the
>> decision is made, has a chance to test it.
>> It is unreasonable to expect each of the committers to make their own
>> Maven build to test the idea.
>>
>> Adam has saved us a lot of speculation about what it means to move to
>> Maven.
>>
>> Give the supporters and skeptics some time to test before removing it.
>>
>> Ron
>>
>>
>> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>>
>>> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>> My commit is not breaking anything. Why remove something that is
>>>> harmless?
>>>>
>>> Hi Adam,
>>>
>>> The fact that a commit is harmless is not enough for its approval.
>>> I know that your commit doesn't cause any side effects and I appreciate
>>> that you are now doing your work in a feature branch.
>>> I am asking you to revert that commit to trunk not because its quality
>>> is bad or I see potential issues but only because the decision about the
>>> official build tool for the project must be taken by the community and we
>>> are not planning to maintain more than one alternative options in the
>>> official repository.
>>> Just to make it super clear, I restate my request: please revert 1674216
>>> (it is the only commit to trunk) then let's continue the work about Maven
>>> in the release branch you have created.
>>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>>> vs ..." will go on and its outcome will determine the final decision; since
>>> there are clearly different points of view for the different tools we all
>>> have to be open to consider other's opinions: crystallized positions will
>>> not help much in this context.
>>> The branch you have created is valuable because it provides a reference
>>> implementation for the discussion, but it is important that you appreciate
>>> that it may not be merged into the project (based on the outcome of the
>>> ongoing discussion).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
I already establised a working solution for better dependency management
based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
checkout at that time (35 MBs). And it seems with less effort/less
complexity than is now is being shown in the OFBIZ-6172 branch...
I suggested a dev branch back then (
https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
evaluate. Unfortunately it didn't gather momentum at the time.
Does that mean that it is a worse fit? I dare say: not!
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
rwheeler@artifact-software.com> wrote:
> Perhaps it would be a good idea for some of the key people to take a close
> look at what has been done.
>
> This is potentially a big step forward in modernizing the product.
>
> Having a working solution takes a lot of the FUD out of the discussion and
> allows the approach to be tested by the people who are building OFBiz every
> day.
>
> Even if it actually does everything that Adam claims and the consensus of
> the committers is to move to Maven, it will still be a good idea to support
> the 2 build methods until everyone important is ready to commit to Maven.
> It may take a while to get the Maven approach sold to everyone even if they
> know that at some point they will be forced to move. Some will be early
> adopters and some will be late but if you don't have to force everyone to
> move at once, it does make the transition easier.
>
> If it is the consensus that the Ant build is still better, the Maven stuff
> is easy to remove without damaging the Ant build.
>
> I suggest leaving it in until everyone who needs to test it before the
> decision is made, has a chance to test it.
> It is unreasonable to expect each of the committers to make their own
> Maven build to test the idea.
>
> Adam has saved us a lot of speculation about what it means to move to
> Maven.
>
> Give the supporters and skeptics some time to test before removing it.
>
> Ron
>
>
> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>
>> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>>
>> My commit is not breaking anything. Why remove something that is
>>> harmless?
>>>
>> Hi Adam,
>>
>> The fact that a commit is harmless is not enough for its approval.
>> I know that your commit doesn't cause any side effects and I appreciate
>> that you are now doing your work in a feature branch.
>> I am asking you to revert that commit to trunk not because its quality is
>> bad or I see potential issues but only because the decision about the
>> official build tool for the project must be taken by the community and we
>> are not planning to maintain more than one alternative options in the
>> official repository.
>> Just to make it super clear, I restate my request: please revert 1674216
>> (it is the only commit to trunk) then let's continue the work about Maven
>> in the release branch you have created.
>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>> vs ..." will go on and its outcome will determine the final decision; since
>> there are clearly different points of view for the different tools we all
>> have to be open to consider other's opinions: crystallized positions will
>> not help much in this context.
>> The branch you have created is valuable because it provides a reference
>> implementation for the discussion, but it is important that you appreciate
>> that it may not be merged into the project (based on the outcome of the
>> ongoing discussion).
>>
>> Regards,
>>
>> Jacopo
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
Perhaps it would be a good idea for some of the key people to take a
close look at what has been done.
This is potentially a big step forward in modernizing the product.
Having a working solution takes a lot of the FUD out of the discussion
and allows the approach to be tested by the people who are building
OFBiz every day.
Even if it actually does everything that Adam claims and the consensus
of the committers is to move to Maven, it will still be a good idea to
support the 2 build methods until everyone important is ready to commit
to Maven. It may take a while to get the Maven approach sold to everyone
even if they know that at some point they will be forced to move. Some
will be early adopters and some will be late but if you don't have to
force everyone to move at once, it does make the transition easier.
If it is the consensus that the Ant build is still better, the Maven
stuff is easy to remove without damaging the Ant build.
I suggest leaving it in until everyone who needs to test it before the
decision is made, has a chance to test it.
It is unreasonable to expect each of the committers to make their own
Maven build to test the idea.
Adam has saved us a lot of speculation about what it means to move to Maven.
Give the supporters and skeptics some time to test before removing it.
Ron
On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
> On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>
>> My commit is not breaking anything. Why remove something that is harmless?
> Hi Adam,
>
> The fact that a commit is harmless is not enough for its approval.
> I know that your commit doesn't cause any side effects and I appreciate that you are now doing your work in a feature branch.
> I am asking you to revert that commit to trunk not because its quality is bad or I see potential issues but only because the decision about the official build tool for the project must be taken by the community and we are not planning to maintain more than one alternative options in the official repository.
> Just to make it super clear, I restate my request: please revert 1674216 (it is the only commit to trunk) then let's continue the work about Maven in the release branch you have created.
> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle vs ..." will go on and its outcome will determine the final decision; since there are clearly different points of view for the different tools we all have to be open to consider other's opinions: crystallized positions will not help much in this context.
> The branch you have created is valuable because it provides a reference implementation for the discussion, but it is important that you appreciate that it may not be merged into the project (based on the outcome of the ongoing discussion).
>
> Regards,
>
> Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 21, 2015, at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
> My commit is not breaking anything. Why remove something that is harmless?
Hi Adam,
The fact that a commit is harmless is not enough for its approval.
I know that your commit doesn't cause any side effects and I appreciate that you are now doing your work in a feature branch.
I am asking you to revert that commit to trunk not because its quality is bad or I see potential issues but only because the decision about the official build tool for the project must be taken by the community and we are not planning to maintain more than one alternative options in the official repository.
Just to make it super clear, I restate my request: please revert 1674216 (it is the only commit to trunk) then let's continue the work about Maven in the release branch you have created.
In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle vs ..." will go on and its outcome will determine the final decision; since there are clearly different points of view for the different tools we all have to be open to consider other's opinions: crystallized positions will not help much in this context.
The branch you have created is valuable because it provides a reference implementation for the discussion, but it is important that you appreciate that it may not be merged into the project (based on the outcome of the ongoing discussion).
Regards,
Jacopo
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
The nice thing about Maven is that very few people actually have to
learn it.
Once you have the pom set up and the projects structured, the
maintenance is very simple and you don't really need to know Maven to do
most common operations (update dependency version - change a property in
the pom, add a new dependency - add a GAV).
You are right for those who want to restructure the project or change
the deliverable structure but you have the same problem with Ant.
From the core committers' (project managers/gatekeeper) points of view,
it is easier to see what libraries are being used and easy to know if
someone tries to change one.
I found it very easy to add junior programmers to our project since they
did not have to learn the build system at all except for being able to
click on the POM and select "install".
If there are a few Maven experts in the project, that should be sufficient.
Ron
On 21/04/2015 5:07 PM, Heidi Dehaes wrote:
> Step forward to use Maven !
> Easy to use. Difficult to learn.
>
> Eric
> Olagos bvba
> Heidi Dehaes
> Kerkstraat 34
> 2570 Duffel
> Belgium
> Tel. : 015/31 53 04
> GSM : 0485/22 35 80
> E-mail : info.olagos@gmail.com
> http://www.olagos.eu
> http://www.olagos.com
> http://www.olagos.be
> http://www.olagos.nl
>
>
>
>
> 2015-04-21 22:37 GMT+02:00 Adam Heath <do...@brainfood.com>:
>> On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:
>>> On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>>> (picking a random email to respond to; I haven't read anything of this
>>>> thread all weekend, I will need to spend some time doing so)
>>>>
>>>> Fyi, I have framework/start, base, and entity all compiling with maven
>>>> now. API test cases work. Separate foo.jar and foo-test.jar are done.
>>>> META-INF/services/ all located properly. Everything in base/lib/** and
>>>> entity/lib/** has <dependency> settings in pom.xml, but *without* having to
>>>> download anything(yet). I can't stress enough that there are *no* changes
>>>> to any existing files. Absolutely none.
>>>>
>>>> As such, due to the volume of this discussion, I will be coming up with a
>>>> way to have all these poms overlayed(or some other technical solution) to an
>>>> unmodified ofbiz checkout. Git submodules might not be the right approach,
>>>> I need to look at git subtree a bit more.
>>>>
>>>> ps: It's suprising how quickly I was able to start getting maven to work.
>>>> I thought it would be extremely difficult.
>>>>
>>>> pps: I did a comparison of ant, ivy, maven, and gradle at
>>>> http://trends.google.com/. Maven is the correct choice, gradle is too new.
>>> Hi Adam,
>>>
>>> I would suggest you to revert your commit until this discussion settles
>>> down and a final decision is taken by the community.
>>
>> My commit is not breaking anything. Why remove something that is harmless?
>>
>> Let's be positive and forward enabling; if a commit is reverted, then that
>> reversion has not stopped any discussion, and now the original committer
>> will have to do more work to re-add what was removed.
>>
>> This particular commit has not changed anyone's workflow, has not altered
>> any existing file; it hasn't even broken any automated tests. Has anyone
>> complained about eclipse or netbeans ceasing to function, because suddenly
>> there is a pom.xml at the top level? in fact, no one will notice unless
>> they run maven themselves. Seriously, what is the harm in leaving this early
>> POC in trunk, esp. when I am willing to move over to an svn branch away from
>> trunk?
>>
>> You have my attention. I have altered my off-work hours, to give up some of
>> my free time, to improve the project. That is a big deal for me. Why not
>> make use of this time in a productive matter? I am willing to do work. I
>> am willing to move forward. I am implementing.
>>
>> Also, and this may sound like I'm tooting my own horn(well, ok, it is), but
>> *I* implemented macros.xml and common.xml. I made the build system simpler.
>> We used to have to copy the full build.xml into every component, and any
>> changes had to be done to all of them. With this new build system(stating
>> again, nothing has been broken *at all* with what has been added), not only
>> will we be able to have the same set of current features, but we will get
>> *even more*.
>>
>> Proper inter-project dependencies. Proper downloading of external
>> libraries. No longer will anything be embedded. The LICENSE and NOTICE
>> files will be reduced to a fraction of their size(and auto-generated,
>> there's a maven plugin for this, based on all listed <dependency> items).
>> All those project pages you see about project info, javadocs, etc, are
>> produced by maven plugins. Better project distribution(maven can publish
>> directory to a repo). Automatic version updates(all that TRUNK stuff in my
>> examples). OFBiz will be a better behaved system in the Apache Family. Less
>> work will be needed to maintain our own custom build.xml, as now the
>> community at large will continue to improve the maven ecosystem. Less NIH.
>>
>> ps: In case you didn't notice, I have created a JIRA issue for
>> this(OFBIZ-6271), and an svn branch. I will not be submitting separate
>> patches into that issue; instead, changes will be in the branch. This
>> allows for proper history to be maintained, once the change is merged in. I
>> will continue to use git locally for this(as I always have), and will go
>> silent for a short bit, but then mass-commit changes afterI have finessed
>> them into something presentable. A new burst is coming in a few hours.
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 04:07 PM, Heidi Dehaes wrote:
> Step forward to use Maven !
> Easy to use. Difficult to learn.
If you had asked me a week ago, at the start of ApacheCon, whether I
thought a move to maven was possible, I would have gone postal; No way,
hell no, not going to happen.
By the end of day Thursday, I had a working PoC. And, I was returning
from ApacheCon on Thursday, and didn't get home until 6pm or so. And
this PoC was only 45 minutes of time investment. So, difficult to
learn? No, not really.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Heidi Dehaes <in...@gmail.com>.
Step forward to use Maven !
Easy to use. Difficult to learn.
Eric
Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM : 0485/22 35 80
E-mail : info.olagos@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl
2015-04-21 22:37 GMT+02:00 Adam Heath <do...@brainfood.com>:
>
> On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:
>>
>> On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
>>
>>> (picking a random email to respond to; I haven't read anything of this
>>> thread all weekend, I will need to spend some time doing so)
>>>
>>> Fyi, I have framework/start, base, and entity all compiling with maven
>>> now. API test cases work. Separate foo.jar and foo-test.jar are done.
>>> META-INF/services/ all located properly. Everything in base/lib/** and
>>> entity/lib/** has <dependency> settings in pom.xml, but *without* having to
>>> download anything(yet). I can't stress enough that there are *no* changes
>>> to any existing files. Absolutely none.
>>>
>>> As such, due to the volume of this discussion, I will be coming up with a
>>> way to have all these poms overlayed(or some other technical solution) to an
>>> unmodified ofbiz checkout. Git submodules might not be the right approach,
>>> I need to look at git subtree a bit more.
>>>
>>> ps: It's suprising how quickly I was able to start getting maven to work.
>>> I thought it would be extremely difficult.
>>>
>>> pps: I did a comparison of ant, ivy, maven, and gradle at
>>> http://trends.google.com/. Maven is the correct choice, gradle is too new.
>>
>> Hi Adam,
>>
>> I would suggest you to revert your commit until this discussion settles
>> down and a final decision is taken by the community.
>
>
> My commit is not breaking anything. Why remove something that is harmless?
>
> Let's be positive and forward enabling; if a commit is reverted, then that
> reversion has not stopped any discussion, and now the original committer
> will have to do more work to re-add what was removed.
>
> This particular commit has not changed anyone's workflow, has not altered
> any existing file; it hasn't even broken any automated tests. Has anyone
> complained about eclipse or netbeans ceasing to function, because suddenly
> there is a pom.xml at the top level? in fact, no one will notice unless
> they run maven themselves. Seriously, what is the harm in leaving this early
> POC in trunk, esp. when I am willing to move over to an svn branch away from
> trunk?
>
> You have my attention. I have altered my off-work hours, to give up some of
> my free time, to improve the project. That is a big deal for me. Why not
> make use of this time in a productive matter? I am willing to do work. I
> am willing to move forward. I am implementing.
>
> Also, and this may sound like I'm tooting my own horn(well, ok, it is), but
> *I* implemented macros.xml and common.xml. I made the build system simpler.
> We used to have to copy the full build.xml into every component, and any
> changes had to be done to all of them. With this new build system(stating
> again, nothing has been broken *at all* with what has been added), not only
> will we be able to have the same set of current features, but we will get
> *even more*.
>
> Proper inter-project dependencies. Proper downloading of external
> libraries. No longer will anything be embedded. The LICENSE and NOTICE
> files will be reduced to a fraction of their size(and auto-generated,
> there's a maven plugin for this, based on all listed <dependency> items).
> All those project pages you see about project info, javadocs, etc, are
> produced by maven plugins. Better project distribution(maven can publish
> directory to a repo). Automatic version updates(all that TRUNK stuff in my
> examples). OFBiz will be a better behaved system in the Apache Family. Less
> work will be needed to maintain our own custom build.xml, as now the
> community at large will continue to improve the maven ecosystem. Less NIH.
>
> ps: In case you didn't notice, I have created a JIRA issue for
> this(OFBIZ-6271), and an svn branch. I will not be submitting separate
> patches into that issue; instead, changes will be in the branch. This
> allows for proper history to be maintained, once the change is merged in. I
> will continue to use git locally for this(as I always have), and will go
> silent for a short bit, but then mass-commit changes afterI have finessed
> them into something presentable. A new burst is coming in a few hours.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/22/2015 12:53 PM, David E. Jones wrote:
>> On 21 Apr 2015, at 14:09, Pierre Smits <pi...@gmail.com> wrote:
>>
>> Is this the path you want to walk? Code over Community? Engage in commit
>> wars, just to force your way? Please don't! Collaborating is easier than
>> forcing. The latter harms the project more than the first.
> Really? Doing a POC and proposing a direction implies all of this to you?
I haven't done any forcing. I haven't done any commit wars. I've done
a POC, as David mentions.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
@David: Really? No, I projected a scenario that could happen if due process
isn't upheld. I rather not see such a scenario unfolding. And in this case
I feel the gun was jumped. While still debating over pros and cons. A bit
of patience applied would not have led to that projection.
And remember I did a PoC on Ant+IVY (outside of our repository) and opened
the discussion regarding opening a dev branch so that people evaluate that
alternative and learn from my insights gathered in the beginning of 2014.
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 Wed, Apr 22, 2015 at 7:53 PM, David E. Jones <de...@me.com> wrote:
>
> > On 21 Apr 2015, at 14:09, Pierre Smits <pi...@gmail.com> wrote:
> >
> > Is this the path you want to walk? Code over Community? Engage in commit
> > wars, just to force your way? Please don't! Collaborating is easier than
> > forcing. The latter harms the project more than the first.
>
> Really? Doing a POC and proposing a direction implies all of this to you?
>
> -David
>
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 -
in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
> On 21 Apr 2015, at 14:09, Pierre Smits <pi...@gmail.com> wrote:
>
> Is this the path you want to walk? Code over Community? Engage in commit
> wars, just to force your way? Please don't! Collaborating is easier than
> forcing. The latter harms the project more than the first.
Really? Doing a POC and proposing a direction implies all of this to you?
-David
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Adam,
Shall we let other committers, who favour the ANT+IVY approach also move
forward and implement their stuff as well as it will surely not break
anything as well?
Shall we also let other committers, who favour the Groovy/Gradle approach
also move forward and implement their solutions as well as it will surely
not break anything?
Is this the path you want to walk? Code over Community? Engage in commit
wars, just to force your way? Please don't! Collaborating is easier than
forcing. The latter harms the project more than the first.
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 Tue, Apr 21, 2015 at 10:37 PM, Adam Heath <do...@brainfood.com> wrote:
>
> On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:
>
>> On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
>>
>> (picking a random email to respond to; I haven't read anything of this
>>> thread all weekend, I will need to spend some time doing so)
>>>
>>> Fyi, I have framework/start, base, and entity all compiling with maven
>>> now. API test cases work. Separate foo.jar and foo-test.jar are done.
>>> META-INF/services/ all located properly. Everything in base/lib/** and
>>> entity/lib/** has <dependency> settings in pom.xml, but *without* having to
>>> download anything(yet). I can't stress enough that there are *no* changes
>>> to any existing files. Absolutely none.
>>>
>>> As such, due to the volume of this discussion, I will be coming up with
>>> a way to have all these poms overlayed(or some other technical solution) to
>>> an unmodified ofbiz checkout. Git submodules might not be the right
>>> approach, I need to look at git subtree a bit more.
>>>
>>> ps: It's suprising how quickly I was able to start getting maven to
>>> work. I thought it would be extremely difficult.
>>>
>>> pps: I did a comparison of ant, ivy, maven, and gradle at
>>> http://trends.google.com/. Maven is the correct choice, gradle is too
>>> new.
>>>
>> Hi Adam,
>>
>> I would suggest you to revert your commit until this discussion settles
>> down and a final decision is taken by the community.
>>
>
> My commit is not breaking anything. Why remove something that is harmless?
>
> Let's be positive and forward enabling; if a commit is reverted, then that
> reversion has not stopped any discussion, and now the original committer
> will have to do more work to re-add what was removed.
>
> This particular commit has not changed anyone's workflow, has not altered
> any existing file; it hasn't even broken any automated tests. Has anyone
> complained about eclipse or netbeans ceasing to function, because suddenly
> there is a pom.xml at the top level? in fact, no one will notice unless
> they run maven themselves. Seriously, what is the harm in leaving this
> early POC in trunk, esp. when I am willing to move over to an svn branch
> away from trunk?
>
> You have my attention. I have altered my off-work hours, to give up some
> of my free time, to improve the project. That is a big deal for me. Why
> not make use of this time in a productive matter? I am willing to do
> work. I am willing to move forward. I am implementing.
>
> Also, and this may sound like I'm tooting my own horn(well, ok, it is),
> but *I* implemented macros.xml and common.xml. I made the build system
> simpler. We used to have to copy the full build.xml into every component,
> and any changes had to be done to all of them. With this new build
> system(stating again, nothing has been broken *at all* with what has been
> added), not only will we be able to have the same set of current features,
> but we will get *even more*.
>
> Proper inter-project dependencies. Proper downloading of external
> libraries. No longer will anything be embedded. The LICENSE and NOTICE
> files will be reduced to a fraction of their size(and auto-generated,
> there's a maven plugin for this, based on all listed <dependency> items).
> All those project pages you see about project info, javadocs, etc, are
> produced by maven plugins. Better project distribution(maven can publish
> directory to a repo). Automatic version updates(all that TRUNK stuff in my
> examples). OFBiz will be a better behaved system in the Apache Family.
> Less work will be needed to maintain our own custom build.xml, as now the
> community at large will continue to improve the maven ecosystem. Less NIH.
>
> ps: In case you didn't notice, I have created a JIRA issue for
> this(OFBIZ-6271), and an svn branch. I will not be submitting separate
> patches into that issue; instead, changes will be in the branch. This
> allows for proper history to be maintained, once the change is merged in.
> I will continue to use git locally for this(as I always have), and will go
> silent for a short bit, but then mass-commit changes afterI have finessed
> them into something presentable. A new burst is coming in a few hours.
>
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adrian Crum <ad...@sandglass-software.com>.
Adam,
This all sounds good to me. I will have time to review your improvements
after May 1.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 9:37 PM, Adam Heath wrote:
>
> On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:
>> On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
>>
>>> (picking a random email to respond to; I haven't read anything of
>>> this thread all weekend, I will need to spend some time doing so)
>>>
>>> Fyi, I have framework/start, base, and entity all compiling with
>>> maven now. API test cases work. Separate foo.jar and foo-test.jar
>>> are done. META-INF/services/ all located properly. Everything in
>>> base/lib/** and entity/lib/** has <dependency> settings in pom.xml,
>>> but *without* having to download anything(yet). I can't stress
>>> enough that there are *no* changes to any existing files. Absolutely
>>> none.
>>>
>>> As such, due to the volume of this discussion, I will be coming up
>>> with a way to have all these poms overlayed(or some other technical
>>> solution) to an unmodified ofbiz checkout. Git submodules might not
>>> be the right approach, I need to look at git subtree a bit more.
>>>
>>> ps: It's suprising how quickly I was able to start getting maven to
>>> work. I thought it would be extremely difficult.
>>>
>>> pps: I did a comparison of ant, ivy, maven, and gradle at
>>> http://trends.google.com/. Maven is the correct choice, gradle is
>>> too new.
>> Hi Adam,
>>
>> I would suggest you to revert your commit until this discussion
>> settles down and a final decision is taken by the community.
>
> My commit is not breaking anything. Why remove something that is harmless?
>
> Let's be positive and forward enabling; if a commit is reverted, then
> that reversion has not stopped any discussion, and now the original
> committer will have to do more work to re-add what was removed.
>
> This particular commit has not changed anyone's workflow, has not
> altered any existing file; it hasn't even broken any automated tests.
> Has anyone complained about eclipse or netbeans ceasing to function,
> because suddenly there is a pom.xml at the top level? in fact, no one
> will notice unless they run maven themselves. Seriously, what is the
> harm in leaving this early POC in trunk, esp. when I am willing to move
> over to an svn branch away from trunk?
>
> You have my attention. I have altered my off-work hours, to give up
> some of my free time, to improve the project. That is a big deal for
> me. Why not make use of this time in a productive matter? I am willing
> to do work. I am willing to move forward. I am implementing.
>
> Also, and this may sound like I'm tooting my own horn(well, ok, it is),
> but *I* implemented macros.xml and common.xml. I made the build system
> simpler. We used to have to copy the full build.xml into every
> component, and any changes had to be done to all of them. With this new
> build system(stating again, nothing has been broken *at all* with what
> has been added), not only will we be able to have the same set of
> current features, but we will get *even more*.
>
> Proper inter-project dependencies. Proper downloading of external
> libraries. No longer will anything be embedded. The LICENSE and NOTICE
> files will be reduced to a fraction of their size(and auto-generated,
> there's a maven plugin for this, based on all listed <dependency>
> items). All those project pages you see about project info, javadocs,
> etc, are produced by maven plugins. Better project distribution(maven
> can publish directory to a repo). Automatic version updates(all that
> TRUNK stuff in my examples). OFBiz will be a better behaved system in
> the Apache Family. Less work will be needed to maintain our own custom
> build.xml, as now the community at large will continue to improve the
> maven ecosystem. Less NIH.
>
> ps: In case you didn't notice, I have created a JIRA issue for
> this(OFBIZ-6271), and an svn branch. I will not be submitting separate
> patches into that issue; instead, changes will be in the branch. This
> allows for proper history to be maintained, once the change is merged
> in. I will continue to use git locally for this(as I always have), and
> will go silent for a short bit, but then mass-commit changes afterI have
> finessed them into something presentable. A new burst is coming in a
> few hours.
Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216
- in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:
> On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
>
>> (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so)
>>
>> Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has <dependency> settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none.
>>
>> As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more.
>>
>> ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult.
>>
>> pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new.
> Hi Adam,
>
> I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community.
My commit is not breaking anything. Why remove something that is harmless?
Let's be positive and forward enabling; if a commit is reverted, then
that reversion has not stopped any discussion, and now the original
committer will have to do more work to re-add what was removed.
This particular commit has not changed anyone's workflow, has not
altered any existing file; it hasn't even broken any automated tests.
Has anyone complained about eclipse or netbeans ceasing to function,
because suddenly there is a pom.xml at the top level? in fact, no one
will notice unless they run maven themselves. Seriously, what is the
harm in leaving this early POC in trunk, esp. when I am willing to move
over to an svn branch away from trunk?
You have my attention. I have altered my off-work hours, to give up
some of my free time, to improve the project. That is a big deal for
me. Why not make use of this time in a productive matter? I am willing
to do work. I am willing to move forward. I am implementing.
Also, and this may sound like I'm tooting my own horn(well, ok, it is),
but *I* implemented macros.xml and common.xml. I made the build system
simpler. We used to have to copy the full build.xml into every
component, and any changes had to be done to all of them. With this new
build system(stating again, nothing has been broken *at all* with what
has been added), not only will we be able to have the same set of
current features, but we will get *even more*.
Proper inter-project dependencies. Proper downloading of external
libraries. No longer will anything be embedded. The LICENSE and NOTICE
files will be reduced to a fraction of their size(and auto-generated,
there's a maven plugin for this, based on all listed <dependency>
items). All those project pages you see about project info, javadocs,
etc, are produced by maven plugins. Better project distribution(maven
can publish directory to a repo). Automatic version updates(all that
TRUNK stuff in my examples). OFBiz will be a better behaved system in
the Apache Family. Less work will be needed to maintain our own custom
build.xml, as now the community at large will continue to improve the
maven ecosystem. Less NIH.
ps: In case you didn't notice, I have created a JIRA issue for
this(OFBIZ-6271), and an svn branch. I will not be submitting separate
patches into that issue; instead, changes will be in the branch. This
allows for proper history to be maintained, once the change is merged
in. I will continue to use git locally for this(as I always have), and
will go silent for a short bit, but then mass-commit changes afterI have
finessed them into something presentable. A new burst is coming in a
few hours.
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 21, 2015, at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
> (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so)
>
> Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has <dependency> settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none.
>
> As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more.
>
> ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult.
>
> pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new.
Hi Adam,
I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community.
Jacopo
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Quoting:
pps: I did a comparison of ant, ivy, maven, and gradle at
http://trends.google.com/. Maven is the correct choice, gradle is too new.
Ohh. Then we could just as well wait and sit it out to see another 'winner'
rising to the top? Following the fad (http://en.wikipedia.org/wiki/Fad) is
a good argument? I dare to say: not!
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 Tue, Apr 21, 2015 at 12:33 AM, Adam Heath <do...@brainfood.com> wrote:
> (picking a random email to respond to; I haven't read anything of this
> thread all weekend, I will need to spend some time doing so)
>
> Fyi, I have framework/start, base, and entity all compiling with maven
> now. API test cases work. Separate foo.jar and foo-test.jar are done.
> META-INF/services/ all located properly. Everything in base/lib/** and
> entity/lib/** has <dependency> settings in pom.xml, but *without* having to
> download anything(yet). I can't stress enough that there are *no* changes
> to any existing files. Absolutely none.
>
> As such, due to the volume of this discussion, I will be coming up with a
> way to have all these poms overlayed(or some other technical solution) to
> an unmodified ofbiz checkout. Git submodules might not be the right
> approach, I need to look at git subtree a bit more.
>
> ps: It's suprising how quickly I was able to start getting maven to work.
> I thought it would be extremely difficult.
>
> pps: I did a comparison of ant, ivy, maven, and gradle at
> http://trends.google.com/. Maven is the correct choice, gradle is too
> new.
>
> On 04/20/2015 01:43 PM, Pierre Smits wrote:
>
>> Assumptions are the Mother of all Fuckups, is often said.
>>
>> Nevertheless, bringing all viewpoints and insights together (without the
>> assumptions and/or coloured projections) will lead to a better informed
>> community, enabling it to take the right decision.
>>
>> 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 8:31 PM, Ron Wheeler <
>> rwheeler@artifact-software.com
>>
>>> wrote:
>>> Sorry Pierre.
>>> I hope it did not not ruin your evening.
>>> I guess old tools are like old homes.
>>> Hard to say goodbye even if the new house fits your needs better.
>>> (Assuming that the consensus is that Ant needs replacing)
>>>
>>> Ron
>>>
>>> On 20/04/2015 2:17 PM, Pierre Smits wrote:
>>>
>>> Thanks for sharing the viewpoints. I could (just barely) suppress a
>>>> physical reaction when I read 'Getting rid of ant is a good thing
>>>> regardless'.
>>>>
>>>> Luckily we implement changes based on consensus, not the preference of
>>>> the
>>>> few.
>>>>
>>>> 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 8:00 PM, Ron Wheeler <
>>>> rwheeler@artifact-software.com
>>>>
>>>> wrote:
>>>>> Maven imposes a philosophy on builds that you either follow or fight
>>>>> (and
>>>>> lose).
>>>>>
>>>>> The good side is that once you have your structure and supporting
>>>>> processes in place anyone who knows a little bit of Maven can run a
>>>>> build
>>>>> without looking at the pom and can add a dependency without destroying
>>>>> the
>>>>> build.
>>>>> You can build plug-ins to encapsulate best practices or to accomplish
>>>>> tasks that are not part of the software build.
>>>>> It is still possible to misuse Maven but it takes a lot of work and
>>>>> there
>>>>> is an active community to help avoid doing silly things.
>>>>> It is also actively supported with regular new versions so bug fixes
>>>>> and
>>>>> enhancement do get released quickly.
>>>>>
>>>>> I have used Maven for years and like it a lot.
>>>>>
>>>>> Gradle is new and getting a lot of attention so it might be a better
>>>>> choice but I have never used it.
>>>>> Flexibility is nice until some bad practices get put into a build
>>>>> process
>>>>> to solve a problem quickly rather than well.
>>>>>
>>>>> I love Ant and use it for other things but as a build tool it is too
>>>>> flexible and does not impose any structure or "Best Practices".
>>>>>
>>>>> It also is an additional step on the learning curve which acts as a
>>>>> barrier to attracting developers; specially younger members who have
>>>>> been
>>>>> using more modern tools.
>>>>>
>>>>> Getting rid of Ant is a "good thing" regardless of where you go.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>>>>>
>>>>> Some of the build files are really ugly at the moment and difficult
>>>>> to
>>>>>
>>>>>> read: see the macros.xml, src-extra-set etc...
>>>>>> The ability to write real code snippets may greatly simplify them.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>>>>>
>>>>>> That gets back to the question of why change in the first place...
>>>>>> build
>>>>>>
>>>>>> files may be smaller and easier to maintain, but there may not be a
>>>>>>> good
>>>>>>> reason!
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> David,
>>>>>>>>
>>>>>>>> Thanks for sharing your insights. You talk about 'pretty much
>>>>>>>> anything
>>>>>>>> can be done with'. What, in your experience, can't be done -at the
>>>>>>>> moment- in relation to OFBiz?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Pierre
>>>>>>>>
>>>>>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>>>>>> volgende
>>>>>>>> geschreven:
>>>>>>>>
>>>>>>>> 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 <
>>>>>>>>> mailinglist@antwebsystems.com
>>>>>>>>> <javascript:;>> 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 <
>>>>>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>>>
>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>
>>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Pierre Smits
>>>>>>>>
>>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>>> Services & Solutions for Cloud-
>>>>>>>> Based Manufacturing, Professional
>>>>>>>> Services and Retail & Trade
>>>>>>>> http://www.orrtiz.com
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>>>
>>>>>
>>>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Adam Heath <do...@brainfood.com>.
(picking a random email to respond to; I haven't read anything of this
thread all weekend, I will need to spend some time doing so)
Fyi, I have framework/start, base, and entity all compiling with maven
now. API test cases work. Separate foo.jar and foo-test.jar are done.
META-INF/services/ all located properly. Everything in base/lib/** and
entity/lib/** has <dependency> settings in pom.xml, but *without* having
to download anything(yet). I can't stress enough that there are *no*
changes to any existing files. Absolutely none.
As such, due to the volume of this discussion, I will be coming up with
a way to have all these poms overlayed(or some other technical solution)
to an unmodified ofbiz checkout. Git submodules might not be the right
approach, I need to look at git subtree a bit more.
ps: It's suprising how quickly I was able to start getting maven to
work. I thought it would be extremely difficult.
pps: I did a comparison of ant, ivy, maven, and gradle at
http://trends.google.com/. Maven is the correct choice, gradle is too new.
On 04/20/2015 01:43 PM, Pierre Smits wrote:
> Assumptions are the Mother of all Fuckups, is often said.
>
> Nevertheless, bringing all viewpoints and insights together (without the
> assumptions and/or coloured projections) will lead to a better informed
> community, enabling it to take the right decision.
>
> 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 8:31 PM, Ron Wheeler <rwheeler@artifact-software.com
>> wrote:
>> Sorry Pierre.
>> I hope it did not not ruin your evening.
>> I guess old tools are like old homes.
>> Hard to say goodbye even if the new house fits your needs better.
>> (Assuming that the consensus is that Ant needs replacing)
>>
>> Ron
>>
>> On 20/04/2015 2:17 PM, Pierre Smits wrote:
>>
>>> Thanks for sharing the viewpoints. I could (just barely) suppress a
>>> physical reaction when I read 'Getting rid of ant is a good thing
>>> regardless'.
>>>
>>> Luckily we implement changes based on consensus, not the preference of the
>>> few.
>>>
>>> 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 8:00 PM, Ron Wheeler <
>>> rwheeler@artifact-software.com
>>>
>>>> wrote:
>>>> Maven imposes a philosophy on builds that you either follow or fight (and
>>>> lose).
>>>>
>>>> The good side is that once you have your structure and supporting
>>>> processes in place anyone who knows a little bit of Maven can run a build
>>>> without looking at the pom and can add a dependency without destroying
>>>> the
>>>> build.
>>>> You can build plug-ins to encapsulate best practices or to accomplish
>>>> tasks that are not part of the software build.
>>>> It is still possible to misuse Maven but it takes a lot of work and there
>>>> is an active community to help avoid doing silly things.
>>>> It is also actively supported with regular new versions so bug fixes and
>>>> enhancement do get released quickly.
>>>>
>>>> I have used Maven for years and like it a lot.
>>>>
>>>> Gradle is new and getting a lot of attention so it might be a better
>>>> choice but I have never used it.
>>>> Flexibility is nice until some bad practices get put into a build process
>>>> to solve a problem quickly rather than well.
>>>>
>>>> I love Ant and use it for other things but as a build tool it is too
>>>> flexible and does not impose any structure or "Best Practices".
>>>>
>>>> It also is an additional step on the learning curve which acts as a
>>>> barrier to attracting developers; specially younger members who have been
>>>> using more modern tools.
>>>>
>>>> Getting rid of Ant is a "good thing" regardless of where you go.
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>>>>
>>>> Some of the build files are really ugly at the moment and difficult to
>>>>> read: see the macros.xml, src-extra-set etc...
>>>>> The ability to write real code snippets may greatly simplify them.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>>>>
>>>>> That gets back to the question of why change in the first place...
>>>>> build
>>>>>
>>>>>> files may be smaller and easier to maintain, but there may not be a
>>>>>> good
>>>>>> reason!
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>>>>>> can be done with'. What, in your experience, can't be done -at the
>>>>>>> moment- in relation to OFBiz?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre
>>>>>>>
>>>>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>>>>> volgende
>>>>>>> geschreven:
>>>>>>>
>>>>>>> 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 <
>>>>>>>> mailinglist@antwebsystems.com
>>>>>>>> <javascript:;>> 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 <
>>>>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>>>>>
>>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>>>>> --
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
I tried to express my experience with Maven and Ant
I also expressed my sentiments about Gradle.
I hope that my bias for build systems that impose a bit of discipline
was clear.
It is based on many years of software development, application support
and system administration as well as recent experience running a small
team of developers (with wildly differing backgrounds) building a a few
medium sized applications (SaaS LMS with over 70 maven projects,
eComerce front-end for virtual ILT and an ETVL product).
I am aware that other viewpoints exist and that ANT has worked for many
years.
Ron
On 20/04/2015 2:43 PM, Pierre Smits wrote:
> Assumptions are the Mother of all Fuckups, is often said.
>
> Nevertheless, bringing all viewpoints and insights together (without the
> assumptions and/or coloured projections) will lead to a better informed
> community, enabling it to take the right decision.
>
> 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 8:31 PM, Ron Wheeler <rwheeler@artifact-software.com
>> wrote:
>> Sorry Pierre.
>> I hope it did not not ruin your evening.
>> I guess old tools are like old homes.
>> Hard to say goodbye even if the new house fits your needs better.
>> (Assuming that the consensus is that Ant needs replacing)
>>
>> Ron
>>
>> On 20/04/2015 2:17 PM, Pierre Smits wrote:
>>
>>> Thanks for sharing the viewpoints. I could (just barely) suppress a
>>> physical reaction when I read 'Getting rid of ant is a good thing
>>> regardless'.
>>>
>>> Luckily we implement changes based on consensus, not the preference of the
>>> few.
>>>
>>> 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 8:00 PM, Ron Wheeler <
>>> rwheeler@artifact-software.com
>>>
>>>> wrote:
>>>> Maven imposes a philosophy on builds that you either follow or fight (and
>>>> lose).
>>>>
>>>> The good side is that once you have your structure and supporting
>>>> processes in place anyone who knows a little bit of Maven can run a build
>>>> without looking at the pom and can add a dependency without destroying
>>>> the
>>>> build.
>>>> You can build plug-ins to encapsulate best practices or to accomplish
>>>> tasks that are not part of the software build.
>>>> It is still possible to misuse Maven but it takes a lot of work and there
>>>> is an active community to help avoid doing silly things.
>>>> It is also actively supported with regular new versions so bug fixes and
>>>> enhancement do get released quickly.
>>>>
>>>> I have used Maven for years and like it a lot.
>>>>
>>>> Gradle is new and getting a lot of attention so it might be a better
>>>> choice but I have never used it.
>>>> Flexibility is nice until some bad practices get put into a build process
>>>> to solve a problem quickly rather than well.
>>>>
>>>> I love Ant and use it for other things but as a build tool it is too
>>>> flexible and does not impose any structure or "Best Practices".
>>>>
>>>> It also is an additional step on the learning curve which acts as a
>>>> barrier to attracting developers; specially younger members who have been
>>>> using more modern tools.
>>>>
>>>> Getting rid of Ant is a "good thing" regardless of where you go.
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>>>>
>>>> Some of the build files are really ugly at the moment and difficult to
>>>>> read: see the macros.xml, src-extra-set etc...
>>>>> The ability to write real code snippets may greatly simplify them.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>>>>
>>>>> That gets back to the question of why change in the first place...
>>>>> build
>>>>>
>>>>>> files may be smaller and easier to maintain, but there may not be a
>>>>>> good
>>>>>> reason!
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>>>>>> can be done with'. What, in your experience, can't be done -at the
>>>>>>> moment- in relation to OFBiz?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre
>>>>>>>
>>>>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>>>>> volgende
>>>>>>> geschreven:
>>>>>>>
>>>>>>> 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 <
>>>>>>>> mailinglist@antwebsystems.com
>>>>>>>> <javascript:;>> 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 <
>>>>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>>>>>
>>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>>>>> --
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Assumptions are the Mother of all Fuckups, is often said.
Nevertheless, bringing all viewpoints and insights together (without the
assumptions and/or coloured projections) will lead to a better informed
community, enabling it to take the right decision.
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 8:31 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> Sorry Pierre.
> I hope it did not not ruin your evening.
> I guess old tools are like old homes.
> Hard to say goodbye even if the new house fits your needs better.
> (Assuming that the consensus is that Ant needs replacing)
>
> Ron
>
> On 20/04/2015 2:17 PM, Pierre Smits wrote:
>
>> Thanks for sharing the viewpoints. I could (just barely) suppress a
>> physical reaction when I read 'Getting rid of ant is a good thing
>> regardless'.
>>
>> Luckily we implement changes based on consensus, not the preference of the
>> few.
>>
>> 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 8:00 PM, Ron Wheeler <
>> rwheeler@artifact-software.com
>>
>>> wrote:
>>> Maven imposes a philosophy on builds that you either follow or fight (and
>>> lose).
>>>
>>> The good side is that once you have your structure and supporting
>>> processes in place anyone who knows a little bit of Maven can run a build
>>> without looking at the pom and can add a dependency without destroying
>>> the
>>> build.
>>> You can build plug-ins to encapsulate best practices or to accomplish
>>> tasks that are not part of the software build.
>>> It is still possible to misuse Maven but it takes a lot of work and there
>>> is an active community to help avoid doing silly things.
>>> It is also actively supported with regular new versions so bug fixes and
>>> enhancement do get released quickly.
>>>
>>> I have used Maven for years and like it a lot.
>>>
>>> Gradle is new and getting a lot of attention so it might be a better
>>> choice but I have never used it.
>>> Flexibility is nice until some bad practices get put into a build process
>>> to solve a problem quickly rather than well.
>>>
>>> I love Ant and use it for other things but as a build tool it is too
>>> flexible and does not impose any structure or "Best Practices".
>>>
>>> It also is an additional step on the learning curve which acts as a
>>> barrier to attracting developers; specially younger members who have been
>>> using more modern tools.
>>>
>>> Getting rid of Ant is a "good thing" regardless of where you go.
>>>
>>> Ron
>>>
>>>
>>> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>>>
>>> Some of the build files are really ugly at the moment and difficult to
>>>> read: see the macros.xml, src-extra-set etc...
>>>> The ability to write real code snippets may greatly simplify them.
>>>>
>>>> Jacopo
>>>>
>>>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>>>
>>>> That gets back to the question of why change in the first place...
>>>> build
>>>>
>>>>> files may be smaller and easier to maintain, but there may not be a
>>>>> good
>>>>> reason!
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>>>>> can be done with'. What, in your experience, can't be done -at the
>>>>>> moment- in relation to OFBiz?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre
>>>>>>
>>>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>>>> volgende
>>>>>> geschreven:
>>>>>>
>>>>>> 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 <
>>>>>>> mailinglist@antwebsystems.com
>>>>>>> <javascript:;>> 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 <
>>>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>>>>
>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>
>>>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
Sorry Pierre.
I hope it did not not ruin your evening.
I guess old tools are like old homes.
Hard to say goodbye even if the new house fits your needs better.
(Assuming that the consensus is that Ant needs replacing)
Ron
On 20/04/2015 2:17 PM, Pierre Smits wrote:
> Thanks for sharing the viewpoints. I could (just barely) suppress a
> physical reaction when I read 'Getting rid of ant is a good thing
> regardless'.
>
> Luckily we implement changes based on consensus, not the preference of the
> few.
>
> 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 8:00 PM, Ron Wheeler <rwheeler@artifact-software.com
>> wrote:
>> Maven imposes a philosophy on builds that you either follow or fight (and
>> lose).
>>
>> The good side is that once you have your structure and supporting
>> processes in place anyone who knows a little bit of Maven can run a build
>> without looking at the pom and can add a dependency without destroying the
>> build.
>> You can build plug-ins to encapsulate best practices or to accomplish
>> tasks that are not part of the software build.
>> It is still possible to misuse Maven but it takes a lot of work and there
>> is an active community to help avoid doing silly things.
>> It is also actively supported with regular new versions so bug fixes and
>> enhancement do get released quickly.
>>
>> I have used Maven for years and like it a lot.
>>
>> Gradle is new and getting a lot of attention so it might be a better
>> choice but I have never used it.
>> Flexibility is nice until some bad practices get put into a build process
>> to solve a problem quickly rather than well.
>>
>> I love Ant and use it for other things but as a build tool it is too
>> flexible and does not impose any structure or "Best Practices".
>>
>> It also is an additional step on the learning curve which acts as a
>> barrier to attracting developers; specially younger members who have been
>> using more modern tools.
>>
>> Getting rid of Ant is a "good thing" regardless of where you go.
>>
>> Ron
>>
>>
>> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>>
>>> Some of the build files are really ugly at the moment and difficult to
>>> read: see the macros.xml, src-extra-set etc...
>>> The ability to write real code snippets may greatly simplify them.
>>>
>>> Jacopo
>>>
>>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>>
>>> That gets back to the question of why change in the first place... build
>>>> files may be smaller and easier to maintain, but there may not be a good
>>>> reason!
>>>>
>>>> -David
>>>>
>>>>
>>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com> wrote:
>>>>> David,
>>>>>
>>>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>>>> can be done with'. What, in your experience, can't be done -at the
>>>>> moment- in relation to OFBiz?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre
>>>>>
>>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>>> volgende
>>>>> geschreven:
>>>>>
>>>>> 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 <mailinglist@antwebsystems.com
>>>>>> <javascript:;>> 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 <
>>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>
>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>>>
>>>>>> --
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Thanks for sharing the viewpoints. I could (just barely) suppress a
physical reaction when I read 'Getting rid of ant is a good thing
regardless'.
Luckily we implement changes based on consensus, not the preference of the
few.
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 8:00 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> Maven imposes a philosophy on builds that you either follow or fight (and
> lose).
>
> The good side is that once you have your structure and supporting
> processes in place anyone who knows a little bit of Maven can run a build
> without looking at the pom and can add a dependency without destroying the
> build.
> You can build plug-ins to encapsulate best practices or to accomplish
> tasks that are not part of the software build.
> It is still possible to misuse Maven but it takes a lot of work and there
> is an active community to help avoid doing silly things.
> It is also actively supported with regular new versions so bug fixes and
> enhancement do get released quickly.
>
> I have used Maven for years and like it a lot.
>
> Gradle is new and getting a lot of attention so it might be a better
> choice but I have never used it.
> Flexibility is nice until some bad practices get put into a build process
> to solve a problem quickly rather than well.
>
> I love Ant and use it for other things but as a build tool it is too
> flexible and does not impose any structure or "Best Practices".
>
> It also is an additional step on the learning curve which acts as a
> barrier to attracting developers; specially younger members who have been
> using more modern tools.
>
> Getting rid of Ant is a "good thing" regardless of where you go.
>
> Ron
>
>
> On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
>
>> Some of the build files are really ugly at the moment and difficult to
>> read: see the macros.xml, src-extra-set etc...
>> The ability to write real code snippets may greatly simplify them.
>>
>> Jacopo
>>
>> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>>
>> That gets back to the question of why change in the first place... build
>>> files may be smaller and easier to maintain, but there may not be a good
>>> reason!
>>>
>>> -David
>>>
>>>
>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com> wrote:
>>>>
>>>> David,
>>>>
>>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>>> can be done with'. What, in your experience, can't be done -at the
>>>> moment- in relation to OFBiz?
>>>>
>>>> Best regards,
>>>>
>>>> Pierre
>>>>
>>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het
>>>> volgende
>>>> geschreven:
>>>>
>>>> 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 <mailinglist@antwebsystems.com
>>>>>>
>>>>> <javascript:;>> 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 <
>>>>>>>>>>
>>>>>>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>
>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>
>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>> --
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
Maven imposes a philosophy on builds that you either follow or fight
(and lose).
The good side is that once you have your structure and supporting
processes in place anyone who knows a little bit of Maven can run a
build without looking at the pom and can add a dependency without
destroying the build.
You can build plug-ins to encapsulate best practices or to accomplish
tasks that are not part of the software build.
It is still possible to misuse Maven but it takes a lot of work and
there is an active community to help avoid doing silly things.
It is also actively supported with regular new versions so bug fixes and
enhancement do get released quickly.
I have used Maven for years and like it a lot.
Gradle is new and getting a lot of attention so it might be a better
choice but I have never used it.
Flexibility is nice until some bad practices get put into a build
process to solve a problem quickly rather than well.
I love Ant and use it for other things but as a build tool it is too
flexible and does not impose any structure or "Best Practices".
It also is an additional step on the learning curve which acts as a
barrier to attracting developers; specially younger members who have
been using more modern tools.
Getting rid of Ant is a "good thing" regardless of where you go.
Ron
On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:
> Some of the build files are really ugly at the moment and difficult to read: see the macros.xml, src-extra-set etc...
> The ability to write real code snippets may greatly simplify them.
>
> Jacopo
>
> On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>
>> That gets back to the question of why change in the first place... build files may be smaller and easier to maintain, but there may not be a good reason!
>>
>> -David
>>
>>
>>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>> David,
>>>
>>> Thanks for sharing your insights. You talk about 'pretty much anything
>>> can be done with'. What, in your experience, can't be done -at the
>>> moment- in relation to OFBiz?
>>>
>>> Best regards,
>>>
>>> Pierre
>>>
>>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het volgende
>>> geschreven:
>>>
>>>> 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 <mailinglist@antwebsystems.com
>>>> <javascript:;>> 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 <
>>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>>
>>>>>>>>
>>>>
>>> --
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
Some of the build files are really ugly at the moment and difficult to read: see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.
Jacopo
On Apr 20, 2015, at 7:00 PM, David E. Jones <de...@me.com> wrote:
>
> That gets back to the question of why change in the first place... build files may be smaller and easier to maintain, but there may not be a good reason!
>
> -David
>
>
>> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com> wrote:
>>
>> David,
>>
>> Thanks for sharing your insights. You talk about 'pretty much anything
>> can be done with'. What, in your experience, can't be done -at the
>> moment- in relation to OFBiz?
>>
>> Best regards,
>>
>> Pierre
>>
>> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het volgende
>> geschreven:
>>
>>>
>>> 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 <mailinglist@antwebsystems.com
>>> <javascript:;>> 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 <
>>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>>
>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> --
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
Pierre is right to be cautious.
It is not just s swap of one build program for another.
There is a real change in the way one looks at software applications.
The current mixup with the dependencies would be much harder to do under
Maven.
Moving to Maven would almost certainly require that this be fixed.
The software parts of the project would probably have to be restructured
into a much more cleanly layered set of dependencies.
One would want to look at the structure of seed data and the whole
process of installing OFBiz.
One would also want to look at the Framework as a separate product (if
the community wants to promote this use of OFBiz) and set that up as a
separate deliverable with a separate build structure that produces a jar
of code and a process to deliver and install the seed data required for
a non-ERP application to call on the Framework as a dependency.
This would have many advantages for building custom ERPs based on OFBiz
but would require some work and consensus building that might be hard to
say the least.
Ron
On 20/04/2015 2:58 PM, Pierre Smits wrote:
> Quoting: 'why change in the first place'. That is one of the most important
> question, perhaps even 'the most important'.... And it seems, that one
> isn't answered to the fullest.
>
> I like: if it aint broken, don't try to fix it'. But also 'a square peg
> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
> current mechanism a square peg?
>
> But beyond that: have we fully explored the all/other paths? We currently
> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
> solutions (at least according to their sites, but the writers of any of
> those pages could be disregarded as experts). But there are also Apache
> Buildr and Continiuum, according to this site listing options:
> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>
> Should we explore inviting the real experts (those of all these tools) to
> share their insights, so that we can base the decision on real information
> than just conjecture/limited experiences?
>
> And on another and related aspect: how much effort would the benefit of
> each option require to have it fully operational for OFBiz? That should
> help determination too.
>
> 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:00 PM, David E. Jones <de...@me.com> wrote:
>
>> That gets back to the question of why change in the first place... build
>> files may be smaller and easier to maintain, but there may not be a good
>> reason!
>>
>> -David
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Yes, managing the perception regarding 'Expert' is a smart decision. You
used one of the correct means.
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 10:38 PM, Ron Wheeler <
rwheeler@artifact-software.com> wrote:
> On 20/04/2015 4:15 PM, David E. Jones wrote:
>
>> On 20 Apr 2015, at 12:29, Ron Wheeler <rw...@artifact-software.com>
>>> wrote:
>>>
>>> On 20/04/2015 3:19 PM, David E. Jones wrote:
>>>
>>>> Buildr is similar to Gradle, though Ruby-based where Gradle is
>>>> Groovy-based and so has more affinity with OFBiz. Continuum is a different
>>>> sort of animal, a continuous integration tool that can run a variety of
>>>> build tools.
>>>>
>>>> BTW, what is an expert, let alone a "real" expert? A little like the
>>>> term "true Scotsman" and the corresponding logical fallacy IMO...
>>>>
>>> I was always told that an expert was "a man with a briefcase 50 miles
>>> from home".
>>> Not sure how this translates into the modern virtual world taking into
>>> account the role of women.
>>>
>> Not a bad definition, representative of the concept including often
>> arbitrary inclusion/exclusion. ;)
>>
>> I say that having been a man with a briefcase over 50 miles from home on
>> regular occasions...
>>
> Having been in that situation, I can assure you that in the "olden days",
> once was usually enough.
> Of course when you went back to your home office the next day or week ,
> the designation ceased.
> In one case where a vice-president of one division of a company
> recommended me to another division in his company, I asked what would be a
> reasonable charge.
> The answer was "Charge enough so that they know you are an expert".
>
> In the end I did save them over $500,000 so I did not feel to bad about
> the fee.
>
>
>
>
>> -David
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 20/04/2015 4:15 PM, David E. Jones wrote:
>> On 20 Apr 2015, at 12:29, Ron Wheeler <rw...@artifact-software.com> wrote:
>>
>> On 20/04/2015 3:19 PM, David E. Jones wrote:
>>> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>>>
>>> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
>> I was always told that an expert was "a man with a briefcase 50 miles from home".
>> Not sure how this translates into the modern virtual world taking into account the role of women.
> Not a bad definition, representative of the concept including often arbitrary inclusion/exclusion. ;)
>
> I say that having been a man with a briefcase over 50 miles from home on regular occasions...
Having been in that situation, I can assure you that in the "olden
days", once was usually enough.
Of course when you went back to your home office the next day or week ,
the designation ceased.
In one case where a vice-president of one division of a company
recommended me to another division in his company, I asked what would be
a reasonable charge.
The answer was "Charge enough so that they know you are an expert".
In the end I did save them over $500,000 so I did not feel to bad about
the fee.
>
> -David
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
> On 20 Apr 2015, at 12:29, Ron Wheeler <rw...@artifact-software.com> wrote:
>
> On 20/04/2015 3:19 PM, David E. Jones wrote:
>> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>>
>> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
> I was always told that an expert was "a man with a briefcase 50 miles from home".
> Not sure how this translates into the modern virtual world taking into account the role of women.
Not a bad definition, representative of the concept including often arbitrary inclusion/exclusion. ;)
I say that having been a man with a briefcase over 50 miles from home on regular occasions...
-David
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 20/04/2015 3:19 PM, David E. Jones wrote:
> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>
> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
I was always told that an expert was "a man with a briefcase 50 miles
from home".
Not sure how this translates into the modern virtual world taking into
account the role of women.
Ron
>
> -David
>
>
>> On 20 Apr 2015, at 11:58, Pierre Smits <pi...@gmail.com> wrote:
>>
>> Quoting: 'why change in the first place'. That is one of the most important
>> question, perhaps even 'the most important'.... And it seems, that one
>> isn't answered to the fullest.
>>
>> I like: if it aint broken, don't try to fix it'. But also 'a square peg
>> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
>> current mechanism a square peg?
>>
>> But beyond that: have we fully explored the all/other paths? We currently
>> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
>> solutions (at least according to their sites, but the writers of any of
>> those pages could be disregarded as experts). But there are also Apache
>> Buildr and Continiuum, according to this site listing options:
>> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>>
>> Should we explore inviting the real experts (those of all these tools) to
>> share their insights, so that we can base the decision on real information
>> than just conjecture/limited experiences?
>>
>> And on another and related aspect: how much effort would the benefit of
>> each option require to have it fully operational for OFBiz? That should
>> help determination too.
>>
>> 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:00 PM, David E. Jones <de...@me.com> wrote:
>>
>>> That gets back to the question of why change in the first place... build
>>> files may be smaller and easier to maintain, but there may not be a good
>>> reason!
>>>
>>> -David
>>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
-David
> On 20 Apr 2015, at 11:58, Pierre Smits <pi...@gmail.com> wrote:
>
> Quoting: 'why change in the first place'. That is one of the most important
> question, perhaps even 'the most important'.... And it seems, that one
> isn't answered to the fullest.
>
> I like: if it aint broken, don't try to fix it'. But also 'a square peg
> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
> current mechanism a square peg?
>
> But beyond that: have we fully explored the all/other paths? We currently
> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
> solutions (at least according to their sites, but the writers of any of
> those pages could be disregarded as experts). But there are also Apache
> Buildr and Continiuum, according to this site listing options:
> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>
> Should we explore inviting the real experts (those of all these tools) to
> share their insights, so that we can base the decision on real information
> than just conjecture/limited experiences?
>
> And on another and related aspect: how much effort would the benefit of
> each option require to have it fully operational for OFBiz? That should
> help determination too.
>
> 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:00 PM, David E. Jones <de...@me.com> wrote:
>
>>
>> That gets back to the question of why change in the first place... build
>> files may be smaller and easier to maintain, but there may not be a good
>> reason!
>>
>> -David
>>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
Quoting: 'why change in the first place'. That is one of the most important
question, perhaps even 'the most important'.... And it seems, that one
isn't answered to the fullest.
I like: if it aint broken, don't try to fix it'. But also 'a square peg
doesn't fit in a round hole'. Is our current build mechanism broken? Is our
current mechanism a square peg?
But beyond that: have we fully explored the all/other paths? We currently
have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
solutions (at least according to their sites, but the writers of any of
those pages could be disregarded as experts). But there are also Apache
Buildr and Continiuum, according to this site listing options:
http://en.wikipedia.org/wiki/List_of_build_automation_software.
Should we explore inviting the real experts (those of all these tools) to
share their insights, so that we can base the decision on real information
than just conjecture/limited experiences?
And on another and related aspect: how much effort would the benefit of
each option require to have it fully operational for OFBiz? That should
help determination too.
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:00 PM, David E. Jones <de...@me.com> wrote:
>
> That gets back to the question of why change in the first place... build
> files may be smaller and easier to maintain, but there may not be a good
> reason!
>
> -David
>
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
That gets back to the question of why change in the first place... build files may be smaller and easier to maintain, but there may not be a good reason!
-David
> On 20 Apr 2015, at 09:37, Pierre Smits <pi...@gmail.com> wrote:
>
> David,
>
> Thanks for sharing your insights. You talk about 'pretty much anything
> can be done with'. What, in your experience, can't be done -at the
> moment- in relation to OFBiz?
>
> Best regards,
>
> Pierre
>
> Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het volgende
> geschreven:
>
>>
>> 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 <mailinglist@antwebsystems.com
>> <javascript:;>> 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 <
>> jacques.le.roux@les7arts.com <javascript:;>>:
>>>>>>>
>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>> slidingfilaments@gmail.com <javascript:;>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>
> --
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
David,
Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?
Best regards,
Pierre
Op maandag 20 april 2015 heeft David E. Jones <de...@me.com> het volgende
geschreven:
>
> 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 <mailinglist@antwebsystems.com
> <javascript:;>> 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 <
> jacques.le.roux@les7arts.com <javascript:;>>:
> >>>>>
> >>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
> >>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
> slidingfilaments@gmail.com <javascript:;>> 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
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>
--
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in
/ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by "David E. Jones" <de...@me.com>.
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 <ma...@antwebsystems.com> 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 <ja...@les7arts.com>:
>>>>>
>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <sl...@gmail.com> 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
>>>>>
>>>>
>>>>
>>
>
discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk:
framework/start/pom.xml pom.xml
Posted by Hans Bakker <ma...@antwebsystems.com>.
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
>>>> <ja...@les7arts.com>:
>>>>
>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb
>>>>> <sl...@gmail.com> 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
>>>>
>>>
>>>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
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 <do...@brainfood.com> 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 <
>>>> jacques.le.roux@les7arts.com>:
>>>>
>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>
>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>> slidingfilaments@gmail.com> 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
>>>>
>>>>
>>>
>>>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Adam Heath <do...@brainfood.com>.
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
>>> <ja...@les7arts.com>:
>>>
>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb
>>>> <sl...@gmail.com> 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
>>>
>>
>>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@les7arts.com>:
>>
>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <sl...@gmail.com> 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
>>
>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Martin Becker <ma...@ecomify.de>.
+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 <ja...@les7arts.com>:
>
> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <sl...@gmail.com> 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
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <sl...@gmail.com> 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
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Pierre Smits <pi...@gmail.com>.
On Apr 17, 2015, at 3:35 AM, Jacques Le Roux <ja...@les7arts.com>
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
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <sl...@gmail.com> 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
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Taher Alkhateeb <sl...@gmail.com>.
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" <ja...@les7arts.com>
To: dev@ofbiz.apache.org, doogie@apache.org
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, doogie@apache.org 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>
>>
>>
>>
>
Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml
pom.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
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, doogie@apache.org 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>
>>
>>
>>
>