Proposal: redefining the components' directory layout for source files

[Jacques Le Roux]

I believe every good will is welcome, I wait Sharan's answer has she is currently more involved in this than anyone else

Jacques

Le 28/04/2015 10:32, Michael Brohl a écrit :

> Hi,
>
> we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly
> update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct
> links to the issues.
>
> It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without
> digging the MLs, commit history etc..
>
> I could provide this also in english for the OFbiz community if you like.
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
>
> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <[hidden email]> wrote:
>>
>>> This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people
>>> don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with
>>> Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>> I like the idea of resurrecting the blog and use it for official announcements of the project.
>> It would be great if we could include its feeds into the OFBiz main web page and replace the static "News" section we have now.
>>
>> Jacopo
>>
>
>

[Jacopo Cappellato-5]

On Apr 28, 2015, at 10:52 AM, Jacques Le Roux <[hidden email]> wrote:

> In custom projects I like to use simple-methods events...

We will not change your custom projects :-)

Jacopo

[Sharan-F]

Hi Michael

Thanks for the link and also the offer. It looks really good and I think
it would be great to have something like this on our site. So yes it
would be nice to have this information in English so that we can publish
it as part of a our official resurrected blog.


Thanks
Sharan


On 28.4.2015 10:32, Michael Brohl wrote:

> Hi,
>
> we currently maintain an OFBiz news section with monthly updates on
> our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The
> monthly update contains a summary of the latest community efforts,
> proposals and discussions and a more detailed summary of the changes
> in trunk with direct links to the issues.
>
> It is meant to be an information service for the german speaking OFBiz
> users to have easy access to the latest activities in the project
> without digging the MLs, commit history etc..
>
> I could provide this also in english for the OFbiz community if you like.
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
>
> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux
>> <[hidden email]> wrote:
>>
>>> This reminds me that long ago I created an Apache Roller blog for
>>> OFBiz but we never used it. This is a good reason to resurrect it.
>>> Some people don't use Twitter, don't follow the MLs, but they could
>>> still register to a blog which is only sending few messages/year! I
>>> spoke about it with Sharan the week ago
>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>> I like the idea of resurrecting the blog and use it for official
>> announcements of the project.
>> It would be great if we could include its feeds into the OFBiz main
>> web page and replace the static "News" section we have now.
>>
>> Jacopo
>>
>
>

[Pierre Smits]

Quoting:

We will not change your custom projects :-)


On top of that, with proper notification you can plan to address the
migration aspects to your wishes.

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 28, 2015 at 11:07 AM, Jacopo Cappellato <
[hidden email]> wrote:

> On Apr 28, 2015, at 10:52 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > In custom projects I like to use simple-methods events...
>
> We will not change your custom projects :-)
>
> Jacopo

[Pierre Smits]

With a blog by means of Apache Roller, the PMC can delegate authorship to
cater for blog posts in various languages and for various focus areas.

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 28, 2015 at 11:17 AM, Sharan Foga <[hidden email]> wrote:

> Hi Michael
>
> Thanks for the link and also the offer. It looks really good and I think
> it would be great to have something like this on our site. So yes it would
> be nice to have this information in English so that we can publish it as
> part of a our official resurrected blog.
>
>
> Thanks
> Sharan
>
>
>
> On 28.4.2015 10:32, Michael Brohl wrote:
>
>> Hi,
>>
>> we currently maintain an OFBiz news section with monthly updates on our
>> blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The
>> monthly update contains a summary of the latest community efforts,
>> proposals and discussions and a more detailed summary of the changes in
>> trunk with direct links to the issues.
>>
>> It is meant to be an information service for the german speaking OFBiz
>> users to have easy access to the latest activities in the project without
>> digging the MLs, commit history etc..
>>
>> I could provide this also in english for the OFbiz community if you like.
>>
>> Michael
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>>
>>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>  This reminds me that long ago I created an Apache Roller blog for OFBiz
>>>> but we never used it. This is a good reason to resurrect it. Some people
>>>> don't use Twitter, don't follow the MLs, but they could still register to a
>>>> blog which is only sending few messages/year! I spoke about it with Sharan
>>>> the week ago
>>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>>>>
>>> I like the idea of resurrecting the blog and use it for official
>>> announcements of the project.
>>> It would be great if we could include its feeds into the OFBiz main web
>>> page and replace the static "News" section we have now.
>>>
>>> Jacopo
>>>
>>>
>>
>>
>

[Jacques Le Roux]

Interesting proposition: +1

Jacques

Le 28/04/2015 11:28, Pierre Smits a écrit :

> With a blog by means of Apache Roller, the PMC can delegate authorship to
> cater for blog posts in various languages and for various focus areas.
>
> 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 28, 2015 at 11:17 AM, Sharan Foga <[hidden email]> wrote:
>
>> Hi Michael
>>
>> Thanks for the link and also the offer. It looks really good and I think
>> it would be great to have something like this on our site. So yes it would
>> be nice to have this information in English so that we can publish it as
>> part of a our official resurrected blog.
>>
>>
>> Thanks
>> Sharan
>>
>>
>>
>> On 28.4.2015 10:32, Michael Brohl wrote:
>>
>>> Hi,
>>>
>>> we currently maintain an OFBiz news section with monthly updates on our
>>> blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The
>>> monthly update contains a summary of the latest community efforts,
>>> proposals and discussions and a more detailed summary of the changes in
>>> trunk with direct links to the issues.
>>>
>>> It is meant to be an information service for the german speaking OFBiz
>>> users to have easy access to the latest activities in the project without
>>> digging the MLs, commit history etc..
>>>
>>> I could provide this also in english for the OFbiz community if you like.
>>>
>>> Michael
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>>>
>>>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>   This reminds me that long ago I created an Apache Roller blog for OFBiz
>>>>> but we never used it. This is a good reason to resurrect it. Some people
>>>>> don't use Twitter, don't follow the MLs, but they could still register to a
>>>>> blog which is only sending few messages/year! I spoke about it with Sharan
>>>>> the week ago
>>>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>>>>>
>>>> I like the idea of resurrecting the blog and use it for official
>>>> announcements of the project.
>>>> It would be great if we could include its feeds into the OFBiz main web
>>>> page and replace the static "News" section we have now.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>

[Ron Wheeler]

On 28/04/2015 3:31 AM, Jacques Le Roux wrote:

> Le 27/04/2015 16:52, Adam Heath a écrit :
>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>> You can already compile components separately by using the specific
>>> build files
>>
>> Yeah, I know, and it's a pain in my side.  I actually like being able
>> to *compile* each component separately, by changing to that folder,
>> and running ant.  I haven't yet been able to get maven to make that
>> possible.
>
> Yikes, that would be a Maven only solution (no Ant) blocker :/
>
> Jacques
>
>

Why would Ant have trouble with a different project structure?

Ant is the ultimate in flexibility.

The change will affect the existing Ant processes but I find it hard to
imagine how it would prevent Ant from building OFBiz.
I would be tempted to look at providing alternative Ant builds.

It might be nice to have a simple final assemble with Ant that pulls jar
files from Maven Central and uses these jars to build OFBiz
http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html

Having Ant scripts that build individual components or groups of
components should be pretty simple.

It is also possible to deploy artifacts built with Ant to Maven Central.
http://central.sonatype.org/pages/apache-ant.html


I don't see Ant support as a difficult part of a move to Maven but if
there is a real demand to support the use of Ant for 100% of the
development tasks, it can be part of the move to Maven and any
reorganization of the applications.

This will require a high level of cooperation between the experts in the
Ant build scripts and the experts promoting Maven.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Adam Heath-2]

On 04/28/2015 02:31 AM, Jacques Le Roux wrote:

> Le 27/04/2015 16:52, Adam Heath a écrit :
>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>> You can already compile components separately by using the specific
>>> build files
>>
>> Yeah, I know, and it's a pain in my side.  I actually like being able
>> to *compile* each component separately, by changing to that folder,
>> and running ant.  I haven't yet been able to get maven to make that
>> possible.
>
> Yikes, that would be a Maven only solution (no Ant) blocker :/
>

If each component were released separately, then it becomes a non-problem.

I haven't yet given up on this, tho.

[Adam Heath-2]

On 04/28/2015 03:16 AM, Jacques Le Roux wrote:

> Le 24/04/2015 17:01, Adam Heath a écrit :
>>
>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> wrote:
>>>
>>>>>> src/main/java/org/ofbiz/product/
>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>> src/main/groovy/...
>>>>>> src/test/java/org/ofbiz/product/
>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see
>>>> only one .groovy in framework/service/src, for the entire project.
>>> When I proposed this I was also thinking about to move the groovy
>>> (data preparation) scripts that are currently under WEB-INF/actions
>>> folders; most of them could be used in non web applications.
>>
>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the
>> action code was turned into services.  But, even in that case,
>> src/main/scripts would be used, as I think src/main/groovy is for
>> groovyc.  I'll find out today if that is the case.
>>
>>
>
> So you would like to suppress the concept of event? What about the
> validation and conversion with the map-processor (only in
> simple-method) and the convenience of events in some cases?
> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>
>

Way way way too much business logic is embedded and tied to events that
*require* javax.servlet.  This makes it hard to use ofbiz soley as a
backend api layer.

Not all servlet code can be removed.  Aka, the aforementioned parameter
validation/conversion logic.  However, all such input methods should
just pass the munged data stream(s) to the service engine, for
processing.  This includes the ShoppingCart code.

[Adam Heath-2]

On 04/28/2015 03:27 AM, Jacopo Cappellato wrote:
> On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> So you would like to suppress the concept of event?
> Most of the events are currently implemented in Java and are already under src folder.

Not what I mean.  The following method definition pattern is the problem:

==
public static String $methodName(HttpServletRequest request,
HttpServletResponse response) {
   Integer pageNum =
NumberParsingUtil.parseInt(request.getParameter("page"));
   ...
   // core logic starts here
   List<Map<String, Object>> searchDataResults =
dispatcher.runSync("doSearch", context);
   Map<String, Object> parsedData = new HashMap<>();
   int largeSizeCount = 0, smallSizeCount = 0;
   for (Map<String, Object> data: searchDataResults) {
     if (data.size() > 10) largeSizeCount++;
     if (data.size() > 5) smallSizeCount++;
   }
   parsedData.put("largeSizeCount", largeSizeCount);
   parsedData.put("smallSizeCount", smallSizeCount);
   parsedData.put("totalCount", searchDataResults.size());
   parsedData.put("results", searchDataResults);
   ..
   request.setAttribute("search:parsedData", parsedData);
   return "success";
}
==

There are 3 things going on here.  The first part reads the incoming
request data, fetching whatever it needs.  The second does some kind of
business logic.  The third then places the results of that back into the
request for later processing by further code.

The middle part needs to be extracted into a separate location that is
callable through the service engine.

ps: this is pseudo code

[Adam Heath-2]

On 04/28/2015 08:22 AM, Ron Wheeler wrote:

> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>> You can already compile components separately by using the specific
>>>> build files
>>>
>>> Yeah, I know, and it's a pain in my side.  I actually like being
>>> able to *compile* each component separately, by changing to that
>>> folder, and running ant.  I haven't yet been able to get maven to
>>> make that possible.
>>
>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>
>> Jacques
>>
>>
> Why would Ant have trouble with a different project structure?
>

You mis-parsed Jacques' statement.  Remove the (no Ant) part, and it
becomes: "that would be a Maven only solution blocker".  It is an issue
with maven, not ant.

[Jacques Le Roux]

Le 28/04/2015 15:22, Ron Wheeler a écrit :

> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>> You can already compile components separately by using the specific build files
>>>
>>> Yeah, I know, and it's a pain in my side.  I actually like being able to *compile* each component separately, by changing to that folder, and
>>> running ant.  I haven't yet been able to get maven to make that possible.
>>
>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>
>> Jacques
>>
>>
> Why would Ant have trouble with a different project structure?

No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker.

>
> Ant is the ultimate in flexibility.
>
> The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz.
> I would be tempted to look at providing alternative Ant builds.

I'm undecided on this, but it seems redundant to me and duplicate to maintain.

>
> It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz
> http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html

This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664

>
> Having Ant scripts that build individual components or groups of components should be pretty simple.

That exists already

>
> It is also possible to deploy artifacts built with Ant to Maven Central.
> http://central.sonatype.org/pages/apache-ant.html
>
>
> I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development
> tasks, it can be part of the move to Maven and any reorganization of the applications.
>
> This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven.

I think, if ever we go the Maven way, we will still need Ant around and ready

Jacques

>
> Ron
>

[Jacques Le Roux]

Le 28/04/2015 16:59, Adam Heath a écrit :

>
> On 04/28/2015 08:22 AM, Ron Wheeler wrote:
>> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>>> You can already compile components separately by using the specific build files
>>>>
>>>> Yeah, I know, and it's a pain in my side.  I actually like being able to *compile* each component separately, by changing to that folder, and
>>>> running ant.  I haven't yet been able to get maven to make that possible.
>>>
>>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>>
>>> Jacques
>>>
>>>
>> Why would Ant have trouble with a different project structure?
>>
>
> You mis-parsed Jacques' statement.  Remove the (no Ant) part, and it becomes: "that would be a Maven only solution blocker".  It is an issue with
> maven, not ant.

Yes, I'm a specialist of digressions in parenthesis, my mind is built that way it seems

Jacques

[Jacques Le Roux]

Le 28/04/2015 16:47, Adam Heath a écrit :

>
> On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
>> Le 24/04/2015 17:01, Adam Heath a écrit :
>>>
>>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> wrote:
>>>>
>>>>>>> src/main/java/org/ofbiz/product/
>>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>>> src/main/groovy/...
>>>>>>> src/test/java/org/ofbiz/product/
>>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>>>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders;
>>>> most of them could be used in non web applications.
>>>
>>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts
>>> would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.
>>>
>>>
>>
>> So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the
>> convenience of events in some cases?
>> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>>
>>
>
> Way way way too much business logic is embedded and tied to events that *require* javax.servlet.  This makes it hard to use ofbiz soley as a backend
> api layer.
>
> Not all servlet code can be removed.  Aka, the aforementioned parameter validation/conversion logic.  However, all such input methods should just
> pass the munged data stream(s) to the service engine, for processing.  This includes the ShoppingCart code.
>
>
>

Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an
architecture solution

Jacques

[Jacopo Cappellato-5]

On Apr 28, 2015, at 6:45 PM, Jacques Le Roux <[hidden email]> wrote:

> This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664

Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction.

Jacopo

[Jacques Le Roux]

Le 28/04/2015 18:59, Jacques Le Roux a écrit :

> Le 28/04/2015 16:47, Adam Heath a écrit :
>>
>> On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
>>> Le 24/04/2015 17:01, Adam Heath a écrit :
>>>>
>>>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> wrote:
>>>>>
>>>>>>>> src/main/java/org/ofbiz/product/
>>>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>>>> src/main/groovy/...
>>>>>>>> src/test/java/org/ofbiz/product/
>>>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>>>>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders;
>>>>> most of them could be used in non web applications.
>>>>
>>>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts
>>>> would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.
>>>>
>>>>
>>>
>>> So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and
>>> the convenience of events in some cases?
>>> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>>>
>>>
>>
>> Way way way too much business logic is embedded and tied to events that *require* javax.servlet.  This makes it hard to use ofbiz soley as a
>> backend api layer.
>>
>> Not all servlet code can be removed.  Aka, the aforementioned parameter validation/conversion logic.  However, all such input methods should just
>> pass the munged data stream(s) to the service engine, for processing.  This includes the ShoppingCart code.
>>
>>
>>
> Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an
> architecture solution
>
> Jacques
>

To clarify this was to reuse events inside services, notably the ShoppingCart...

Jacques

[Pierre Smits]

And the reasoning behind that is quite simple: saving on storage and
bandwidth, thus cost.

Best regards,

Pierre

Op dinsdag 28 april 2015 heeft Jacopo Cappellato <
[hidden email]> het volgende geschreven:

> On Apr 28, 2015, at 6:45 PM, Jacques Le Roux <[hidden email]
> <javascript:;>> wrote:
>
> > This is interesting, now I wonder if Jacopo still think the same than at
> https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664
>
> Recently I have read in some ASF thread that the ASF prefers that source
> releases do not contain binaries; in light of this I would not be against a
> change in this direction.
>
> Jacopo
>
>

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

I agree with you.
I have already committed to bilingualism in my development and system
administration  processes.

Once we get through this discussion, I  might put out an argument for an
installer like IzPack that can make deployment into different
environments with the appropriate seed data loaded a bit less
transparent and more user friendly.

Ron

On 28/04/2015 12:45 PM, Jacques Le Roux wrote:

>
> Le 28/04/2015 15:22, Ron Wheeler a écrit :
>> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>>> You can already compile components separately by using the
>>>>> specific build files
>>>>
>>>> Yeah, I know, and it's a pain in my side.  I actually like being
>>>> able to *compile* each component separately, by changing to that
>>>> folder, and running ant.  I haven't yet been able to get maven to
>>>> make that possible.
>>>
>>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>>
>>> Jacques
>>>
>>>
>> Why would Ant have trouble with a different project structure?
>
> No I meant if ever we would head to Maven only (no Ant build in the
> project) then it would be a blocker.
>
>>
>> Ant is the ultimate in flexibility.
>>
>> The change will affect the existing Ant processes but I find it hard
>> to imagine how it would prevent Ant from building OFBiz.
>> I would be tempted to look at providing alternative Ant builds.
>
> I'm undecided on this, but it seems redundant to me and duplicate to
> maintain.
>
>>
>> It might be nice to have a simple final assemble with Ant that pulls
>> jar files from Maven Central and uses these jars to build OFBiz
>> http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html 
>>
>
> This is interesting, now I wonder if Jacopo still think the same than
> at
> https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664
>
>>
>> Having Ant scripts that build individual components or groups of
>> components should be pretty simple.
>
> That exists already
>
>>
>> It is also possible to deploy artifacts built with Ant to Maven Central.
>> http://central.sonatype.org/pages/apache-ant.html
>>
>>
>> I don't see Ant support as a difficult part of a move to Maven but if
>> there is a real demand to support the use of Ant for 100% of the
>> development tasks, it can be part of the move to Maven and any
>> reorganization of the applications.
>>
>> This will require a high level of cooperation between the experts in
>> the Ant build scripts and the experts promoting Maven.
>
> I think, if ever we go the Maven way, we will still need Ant around
> and ready
>
> Jacques
>
>>
>> Ron
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[villivoker]

Цікавий і змістовний блог! Дуже сподобалося, як детально описано особливості місцевості та умови занурення. Особливо вразив огляд на https://traverse-team.org.ua/rozvidka-novogo-dajv-sajtu-karyer-bilya-malyna/ — корисна інформація для всіх, хто планує подорож або захоплюється дайвінгом. Дякую за таку корисну публікацію