Thread: [Exist-development] gradle vs maven

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello,

It here http://www.gradle.org/

thoughts?

-- 
Dmitriy Shabanov

I did consider in some detail Gradle, Buildr and Ivy+Ant before
settling on Maven.

The main advantage to Gradle is complete flexibility as its written in
programming code i.e. Groovy.
The main disadvantage to Gradle is complete flexibilty and having to
write code in Groovy.

I decided on Maven and not Gradle because -
1) Many more people know Maven than Gradle.
2) The tooling and support for Maven is much much better than Gradle.
3) I didnt want to have to learn Groovy and ship a Groovy run-time
with my application.
4) I think a build system should be declarative, i.e. I want to build
these things, NOT how to build these things. Maven allows you to
describe what things to build, Gradle allows complete flexibility a
bit like Ant but more so, I didnt want to end up in the situation
where we are with Ant now, i.e. maintaining thousands of lines
describing how to build something.

I did actually put together a presentation for the eXist developers
meetup in Prague, but there was not actually enough time to give it
formally - you can find my slides for that here -
http://www.adamretter.org.uk/presentations.xml

On 17 October 2011 07:14, Dmitriy Shabanov <sha...@gm...> wrote:
> Hello,
> It here http://www.gradle.org/
>
> thoughts?
> --
> Dmitriy Shabanov
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

So, we have two fronts: one wants how, another - what.
Is it possible to find consensus? The answer is not clear for me after year
and 9 months =)

Is it possible to have top level of Gradle declarative? My guess, yes. That
can give features that Dannes want and keep it declarative as Adam would
like to have.

Adam, did Gradle change after your last look on it?

Dannes, your notes?

Others?

On Mon, Oct 17, 2011 at 5:36 PM, Adam Retter <ad...@ex...> wrote:

> I did consider in some detail Gradle, Buildr and Ivy+Ant before
> settling on Maven.
>
> The main advantage to Gradle is complete flexibility as its written in
> programming code i.e. Groovy.
> The main disadvantage to Gradle is complete flexibilty and having to
> write code in Groovy.
>
> I decided on Maven and not Gradle because -
> 1) Many more people know Maven than Gradle.
> 2) The tooling and support for Maven is much much better than Gradle.
> 3) I didnt want to have to learn Groovy and ship a Groovy run-time
> with my application.
> 4) I think a build system should be declarative, i.e. I want to build
> these things, NOT how to build these things. Maven allows you to
> describe what things to build, Gradle allows complete flexibility a
> bit like Ant but more so, I didnt want to end up in the situation
> where we are with Ant now, i.e. maintaining thousands of lines
> describing how to build something.
>
> I did actually put together a presentation for the eXist developers
> meetup in Prague, but there was not actually enough time to give it
> formally - you can find my slides for that here -
> http://www.adamretter.org.uk/presentations.xml
>
>
-- 
Dmitriy Shabanov

Did I miss something where Dannes said he wanted something?

On 17 October 2011 17:25, Dmitriy Shabanov <sha...@gm...> wrote:
> So, we have two fronts: one wants how, another - what.
> Is it possible to find consensus? The answer is not clear for me after year
> and 9 months =)
>
> Is it possible to have top level of Gradle declarative? My guess, yes. That
> can give features that Dannes want and keep it declarative as Adam would
> like to have.
>
> Adam, did Gradle change after your last look on it?
>
> Dannes, your notes?
>
> Others?
>
> On Mon, Oct 17, 2011 at 5:36 PM, Adam Retter <ad...@ex...> wrote:
>>
>> I did consider in some detail Gradle, Buildr and Ivy+Ant before
>> settling on Maven.
>>
>> The main advantage to Gradle is complete flexibility as its written in
>> programming code i.e. Groovy.
>> The main disadvantage to Gradle is complete flexibilty and having to
>> write code in Groovy.
>>
>> I decided on Maven and not Gradle because -
>> 1) Many more people know Maven than Gradle.
>> 2) The tooling and support for Maven is much much better than Gradle.
>> 3) I didnt want to have to learn Groovy and ship a Groovy run-time
>> with my application.
>> 4) I think a build system should be declarative, i.e. I want to build
>> these things, NOT how to build these things. Maven allows you to
>> describe what things to build, Gradle allows complete flexibility a
>> bit like Ant but more so, I didnt want to end up in the situation
>> where we are with Ant now, i.e. maintaining thousands of lines
>> describing how to build something.
>>
>> I did actually put together a presentation for the eXist developers
>> meetup in Prague, but there was not actually enough time to give it
>> formally - you can find my slides for that here -
>> http://www.adamretter.org.uk/presentations.xml
>>
>
> --
> Dmitriy Shabanov
>

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

yeap, he was pessimistic during maven talks. And he wants to leave as it or
better build control then maven can provide as ant have. That what I did see
=)

On Mon, Oct 17, 2011 at 10:22 PM, Adam Retter <ad...@ex...> wrote:

> Did I miss something where Dannes said he wanted something?
>

-- 
Dmitriy Shabanov

> yeap, he was pessimistic during maven talks. And he wants to leave as it
or better build control then maven can provide as ant have. That what I did
see =)

Sure,  Dannes and I always had some concerns with respect to maven, but I
think we acknowledge that this may just be due to our lack of experience
with maven (and lack of interest to spend time with it). There's no basic
opposition against maven in any way.

So the general decision was to go ahead with maven and see how it works out.

Wolfgang

>> yeap, he was pessimistic during maven talks. And he wants to leave as it
>> or better build control then maven can provide as ant have. That what I did
>> see =)

Yes he was, because he had some concerns, which we discussed and I
think I addressed each of these to his satisfaction?

However the 'proof is in the pudding' as we say, so that is why I
started on a branch to create a Mavenised build of eXist-db, to prove
this is possible and hopefully to demonstrate the improvements. If at
the end of development, I cannot demonstrate improvemnets then it is
indeed a failure and we should not use Maven.

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

On Tue, Oct 18, 2011 at 6:12 PM, Adam Retter <ad...@ex...> wrote:

> However the 'proof is in the pudding' as we say, so that is why I
> started on a branch to create a Mavenised build of eXist-db, to prove
> this is possible and hopefully to demonstrate the improvements. If at
> the end of development, I cannot demonstrate improvemnets then it is
> indeed a failure and we should not use Maven.
>

Adam, can you summarize last mile problems that left?

>
-- 
Dmitriy Shabanov

Ow yeas,

I am on the maven side, I am convinced in the Prague days. I'll always be healthy critical though on all used tooling, maven in special because there are too many fanboys that think maven is the golden tool.

At the moment we switch to maven, we need to re-do lots of logic we have coded in ant right now. Maven does not provide all we need :) think of file processing, rewriting. And.... The current layout with conf.XML does not really map on the maven structure.....

Ps.
I think pessimistic is a bad choice of words

Ps2.
For tooling we should go mainstream. Mainstream at this moment is ant, maven or make...... :)

D.

On 18 okt. 2011, at 15:12, Adam Retter <ad...@ex...> wrote:

> Yes he was, because he had some concerns, which we discussed and I
> think I addressed each of these to his satisfaction?

On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...>wrote:

>
> I am on the maven side, I am convinced in the Prague days. I'll always be
> healthy critical though on all used tooling, maven in special because there
> are too many fanboys that think maven is the golden tool.
>
> At the moment we switch to maven, we need to re-do lots of logic we have
> coded in ant right now. Maven does not provide all we need :) think of file
> processing, rewriting. And.... The current layout with conf.XML does not
> really map on the maven structure.....
>

-1 : configuration is standardized staff

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

file processing, rewriting - pluggins???

>
-- 
Dmitriy Shabanov

On 20 okt. 2011, at 03:55, Dmitriy Shabanov <sha...@gm...> wrote:

> On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...> wrote:
> 
> I am on the maven side, I am convinced in the Prague days. I'll always be healthy critical though on all used tooling, maven in special because there are too many fanboys that think maven is the golden tool.
> 
> At the moment we switch to maven, we need to re-do lots of logic we have coded in ant right now. Maven does not provide all we need :) think of file processing, rewriting. And.... The current layout with conf.XML does not really map on the maven structure.....
> 
> -1 : configuration is standardized staff

I need to be convinced for this....

> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html  

hmmm rather unclear and ambiguous piece of text.

> file processing, rewriting - pluggins???  

Jups, this implies lots of work, unless proven differently. We can't underestimate this amount of work....

D.
On Thu, Oct 20, 2011 at 1:19 PM, Dannes Wessels <di...@ex...> wrote:

> On 20 okt. 2011, at 03:55, Dmitriy Shabanov <sha...@gm...> wrote:
>
> On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...>wrote:
>
>>
>> I am on the maven side, I am convinced in the Prague days. I'll always be
>> healthy critical though on all used tooling, maven in special because there
>> are too many fanboys that think maven is the golden tool.
>>
>> At the moment we switch to maven, we need to re-do lots of logic we have
>> coded in ant right now. Maven does not provide all we need :) think of file
>> processing, rewriting. And.... The current layout with conf.XML does not
>> really map on the maven structure.....
>>
>
> -1 : configuration is standardized staff
>
>
> I need to be convinced for this....
>

Well, several solution: I do like one - move conf.xml to parent folder of
data one.

> file processing, rewriting - pluggins???
>
>
> Jups, this implies lots of work, unless proven differently. We can't
> underestimate this amount of work....
>
>
agree...

-- 
Dmitriy Shabanov

Another solution is eXist as maven plugin (like jetty).

-- 
Dmitriy Shabanov

On 20 October 2011 02:55, Dmitriy Shabanov <sha...@gm...> wrote:
> On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...>
> wrote:
>>
>> I am on the maven side, I am convinced in the Prague days. I'll always be
>> healthy critical though on all used tooling, maven in special because there
>> are too many fanboys that think maven is the golden tool.
>>
>> At the moment we switch to maven, we need to re-do lots of logic we have
>> coded in ant right now. Maven does not provide all we need :) think of file
>> processing, rewriting. And.... The current layout with conf.XML does not
>> really map on the maven structure.....
>
> -1 : configuration is standardized staff
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

You dont have to use the standard directory layout, you can use any
layout you want. However I think it would be good to use the standard
directory layout as this adopted widely even in situations where the
projects are not maven based. In fact switching eXist to a standard
directory layout is very very easy, I have done it here.

>
> file processing, rewriting - pluggins???

Its hard or impossible to understand what you are talking about from
just those few words. Please elaborate?

> --
> Dmitriy Shabanov
>

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

see it in context....

On Thu, Oct 20, 2011 at 5:44 PM, Adam Retter <ad...@ex...> wrote:

> On 20 October 2011 02:55, Dmitriy Shabanov <sha...@gm...> wrote:
> > On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...>
> > wrote:
> >>
> >> I am on the maven side, I am convinced in the Prague days. I'll always
> be
> >> healthy critical though on all used tooling, maven in special because
> there
> >> are too many fanboys that think maven is the golden tool.
> >>
> >> At the moment we switch to maven, we need to re-do lots of logic we have
> >> coded in ant right now. Maven does not provide all we need :) *think of
> file
> >> processing, rewriting*. And.... The current layout with conf.XML does
> not
> >> really map on the maven structure.....
>   >
> > file processing, rewriting - pluggins???
>
> Its hard or impossible to understand what you are talking about from
> just those few words. Please elaborate?
>

-- 
Dmitriy Shabanov

Yes I have, but that doesnt help really!!! What are you saying? Most
of the file processing we do is XSLT based, Maven supports XSLT. The
other file processing is properties processing, Maven also supports
that. Then of course there is building a package of some sort
(WAR/IzPack etc), also Maven supports that.
So what doesnt it support that we need exactly?

On 20 October 2011 18:18, Dmitriy Shabanov <sha...@gm...> wrote:
> see it in context....
>
> On Thu, Oct 20, 2011 at 5:44 PM, Adam Retter <ad...@ex...> wrote:
>>
>> On 20 October 2011 02:55, Dmitriy Shabanov <sha...@gm...> wrote:
>> > On Thu, Oct 20, 2011 at 12:55 AM, Dannes Wessels <di...@ex...>
>> > wrote:
>> >>
>> >> I am on the maven side, I am convinced in the Prague days. I'll always
>> >> be
>> >> healthy critical though on all used tooling, maven in special because
>> >> there
>> >> are too many fanboys that think maven is the golden tool.
>> >>
>> >> At the moment we switch to maven, we need to re-do lots of logic we
>> >> have
>> >> coded in ant right now. Maven does not provide all we need :) think of
>> >> file
>> >> processing, rewriting. And.... The current layout with conf.XML does
>> >> not
>> >> really map on the maven structure.....
>>   >
>> > file processing, rewriting - pluggins???
>>
>> Its hard or impossible to understand what you are talking about from
>> just those few words. Please elaborate?
>
>
> --
> Dmitriy Shabanov
>

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

On Thu, Oct 20, 2011 at 11:46 PM, Adam Retter <ad...@ex...> wrote:

> Yes I have, but that doesnt help really!!! What are you saying? Most
> of the file processing we do is XSLT based, Maven supports XSLT. The
> other file processing is properties processing, Maven also supports
> that. Then of course there is building a package of some sort
> (WAR/IzPack etc), also Maven supports that.
>

Maven do support it through pluggins, that what I did say. Same as you did,
but looks like you can type faster or have more spare time =)

-- 
Dmitriy Shabanov

Hello,

I have just integrated TinyMCE in XSLTForms to allow rich text editing 
with a large range of possible parameters.

In XSLTForms SF repositories, I copied the latest version of TinyMCE in 
a sub-folder named "scripts/tinymce_3.4.6" and I wonder what to do 
within eXist repository.

In eXist SF repository, is it better to add, instead, a "tinymce" 
sub-folder in the "webapp/scripts" folder?

Thanks!

-Alain

Alain,

Jens just told me we didn't answer this email, so I'm doing it now:

> In XSLTForms SF repositories, I copied the latest version of TinyMCE in
> a sub-folder named "scripts/tinymce_3.4.6" and I wonder what to do
> within eXist repository.
>
> In eXist SF repository, is it better to add, instead, a "tinymce"
> sub-folder in the "webapp/scripts" folder?

For the time being, maybe yes. In the long run, I plan to move
everything except maybe documentation out of webapp and into optional,
installable packages using the package repository. It would be great
to have an xsltforms package which people could deploy into the db
when needed, along with some simple examples.

Wolfgang

Thread: [Exist-development] gradle vs maven

eXist-db is a feature rich Open Source native XML database

exist-development