Survey result of choosing a building system

[green]

So far the survey result is:

[Grzegorz Słowikowski]

Hi

Where is this survey? I missed it.

In case it's to late to vote I would like to propose Maven, just pushed
my mavenized versions of Play! 1.2.x and 1.3.x branches:
https://github.com/gslowikowski/play/tree/1.2.x
https://github.com/gslowikowski/play/tree/1.3.x
You can remove all "lib" directories (I haven't done it yet), and Maven
will pull them from the central repository.

Greetings
Grzegorz Slowikowski

On 25 luty 2013 10:30:25, green wrote:
> So far the survey result is:
>

> Inline image 1
>
> --
> You received this message because you are subscribed to the Google
> Groups "playone" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to playone+u...@googlegroups.com.
> To post to this group, send email to pla...@googlegroups.com.
> Visit this group at http://groups.google.com/group/playone?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Dominik Dorn]

missed it too... +1 for gradle.

--
Dominik Dorn
http://dominikdorn.com
http://twitter.com/domdorn

Skripten, Mitschriften, Lernunterlagen, etc. findest Du auf
http://www.studyguru.eu !

[green]

Here is the survey: http://www.surveymonkey.com/s/K2YWM9J

@Grzegorz, So it is clear that we want to  pull jars from central repository. Besides maven I think other build system like Gradle also does it. The benefit of choose Gradle is it should be more concise than maven, but problem of it is it has a big distribution package (37MB on windows).

[i.pals...@jdi.nl]

Hi,

While I like Gradle / Maven / something else at first sight, I've got some reservations : 

- You in many cases need to install Gradle / Maven just to *use* Yalp.

- Gradle for example is 35 megs : The zip contains a large amounts of third-party libs

The blows away our "just unpack it, shove it into you path" and it works. Developers like that. If we ever want to decide that we want to package this, using Gradle etc. won't help either.

I get the feeling we want to drink coffee at our neighbour, and take the Boeing 747 to get there.

Since changing the build system has a *log* of implications we need to think about this carefully. To be honest : I find this one hard. Very hard.

Igmar

[green]

The same issue with play, they packaged a whole python distribution in play binary. We don't have any choice to install at least one build tool, python + custom library, maven, gradle, ant whatever it is.

[green]

I guess one solution is to provide a bootstrap script (on both linux and windows) to check if user platform has the build system installed. If not then it will try download the build system and install it

[Grzegorz Słowikowski]

Hi

We can provide two distribution packages: without and with build tool included.
Moreover, many Java software released comes with two packages: without and with Java JRE included.
(example: http://www.syntevo.com/smartgithg/download.html)
We can have:
1. Yalp
2. Yalp + build tool
3. Yalp + build tool + JRE
distribution packages.

Greetings
Grzegorz Slowikowski

[i.pals...@jdi.nl]

On Tuesday, February 26, 2013 11:03:16 PM UTC+1, greenlaw110 wrote:

The same issue with play, they packaged a whole python distribution in play binary. We don't have any choice to install at least one build tool, python + custom library, maven, gradle, ant whatever it is.

One most distribs, Python is at least installed by default. The the case on all distro's that package using RPM. We indeed need to bootstrap this : Packaging 30 megs isn't really an option.

We might want to look into Lua as the bootstrap language : It's small and powerful.

Other options might be bash on *NIX, and something else on windows. You can't initiate a download from a windows bat file, so we might end up using Python / Lua / whatever on Windows. In bash

we need to assume / test that curl or wget is installed. 

Igmar 

 

[R. Rajesh Jeba Anbiah]

On Wednesday, 27 February 2013 12:20:31 UTC+5:30, i.pals...@jdi.nl wrote:

 <snip>

You can't initiate a download from a windows bat file, so we might end up using Python / Lua / whatever on Windows.

   WScript or VBScript can do that, AFAIK 

[Rakesh Waghela]

The most practical suhhestion by green. I believe Maven already has support from Play community. ( See many modules and play project itself is mavenized by people ). My first hand experience says downloading a build tool separately doesn't do any harm. Writing scripts to automate the downloads of such tool is the sane alternative. Scripts should be optionally user interactive in nature.

[green]

Why don't we just use Java to code those bootstrap task and console command? No need for curl/wget/lua or any other non-java dependencies and we get it run on all platforms.

Igmar 

 

--

[Rakesh Waghela]

Yes !!! http://www.scooterframework.com Already does something similar to bootstrap the Java Project.

[Rakesh Waghela]

http://stackoverflow.com/a/13108828/861454

http://www.jcabi.com/jcabi-aether/

http://www.eclipse.org/aether/support/

[Tom Carchrae]

If you guys are thinking of throwing out python and the current default build tool, then I don't really get it - you're just as bad as people who forced SBT on me! :)   Add another build tool, sure.   Grzegorz has already done that for maven - which is awesome  - but why do you need to break backward compatibility?  

In my mind a great framework should let you use whatever build tool you want.  Build tools are like religion.

Tom

[green]

Hi Tom,

The main problem with current python based build system is it has a 7000+ lines of python code and we don't want to maintain it.

In terms of backward compatibility, I think yalp will break it anyway, the question is break it once and early or break it multiple times and later. Read the discussions on https://github.com/yalpframework/yalp/issues?state=open.

Regards,

Green

[Robert Bakker]

I agree with Tom; I'd prefer not to throw out the build system and use the original one..

I guess it comes down to the goal of the Ion fork: is it extending/enhancing play 1.x as it is - or is it building a new framework based on play 1.x

It seems to me that it is the latter; which is fine - although I still have to see if I'd like to migrate to it.

regards,

Robert

[R. Rajesh Jeba Anbiah]

On Thursday, 28 February 2013 11:54:07 UTC+5:30, Robert Bakker wrote:

I agree with Tom; I'd prefer not to throw out the build system and use the original one..

I guess it comes down to the goal of the Ion fork: is it extending/enhancing play 1.x as it is - or is it building a new framework based on play 1.x

It seems to me that it is the latter; which is fine - although I still have to see if I'd like to migrate to it.

FWIW... IM*H*O,  I think, it's better for the core devs to come up with a manifesto. Green has already provided the link https://github.com/yalpframework/yalp/issues?state=open but it's not easy to understand core devs' plan. Everyone may have some reservations about the "ideal" framework; but overall goal of the project may keep everyone united.

[green]

True. This is exactly why I have submitted this issue: https://github.com/yalpframework/yalp/issues/14

--

[i.pals...@jdi.nl]

Green and I will  make it a formal thing by mid next week.

Regards,

Igmar

[R. Rajesh Jeba Anbiah]

On Thursday, 28 February 2013 18:57:35 UTC+5:30, i.pals...@jdi.nl wrote:

Green and I will  make it a formal thing by mid next week.

Thanks, much appreciated. 

[green]

Here is the new status:

[Grzegorz Słowikowski]

Hi

I would like to ask you what exactly is this survey about:
a) framework build system (in Play! 1 it is Ant)
b) modules build system (in Play! 1 it is Ant too)
c) applications build system (in Play! 1 it is Python based)

a)
If we talk about about framework's build system, here is my working proposal using Maven: https://github.com/gslowikowski/yalp
Some hints:
- all jars removed from git, they are pulled from Maven repository
- if you want to build distribution archive, call "mvn install -Pdist" and go to "distribution/target" directory

b)
Changing modules build from Ant to Maven is easy as well. I'm using mavenized modules in my job.

c)
Changing applications build system is not easy task. There are many functionalities. I use Maven plugin
when developing Play! 1 applications, but did not rewrite all functionalities, so must use original
Python commands from time to time.

I'm curious if someone has working build in Gradle. I would like to compare it with mine.

Greetings
Grzegorz Slowikowski

On 2013-02-25 10:30, green wrote:

So far the survey result is:

[Stéphane Cl]

Hi,

Are you going to take your final decision based on the survey results only or are you just asking for opinions?

I'd suggest comparing the two preferred solutions (since you're not going to maintain original python code, it seems to be gradle or maven) and making a final choice with ease of use and maintenance in mind.

It would be interesting to see prototypes of both solutions side by side, maven is well-established but many people say that gradle groovy-based code is way nicer to read and maintain. And you'll probably need a fair amount of custom code in the build system. 

Best

[Grzegorz Słowikowski]

Hi

I'm only asking for opinions. I don't know who will make the decision, I hope there will be a vote.
I have my Maven build for Play! 1 so it was easy to prepare similar for Yalp.
I agree with you, it would be best to have Gradle build prototype to compare with.

I don't know, who decided, that nobody is going to maintain original Python code.
If we talk about it, we talk about application build system, not framework or modules.
IMO it's easy to say "we don't want Python code", but it would not be easy to port it to Gradle or whatever.
Again, someone should try to do it before we switch.

Grzegorz

[Stéphane Cl]

Ok, I see your point,
To be honest, I have just learned that some people were starting a fork of play 1.x. I dug a bit into the google group list, trying to avoid posts with users stating that yalp should be Ruby on rails, like this or like that. It is still unclear to me whether the next step would be releasing a 1.3 clone or directly developing what a non-scala "play20" might have been.

Perhaps project owners may create a sticky post to inform newscomers about the team and their objectives?
Kind regards

[green]

I think we can leave the Python issue to later phase but the framework and module building needs to be finalized now coz it impact the project layout.  Probably we start with Maven as we have you Grzegorz the expert here, also this comply to the latest survey result as shown below. I suppose Gradle support the maven project layout, if that is the case we are safe to move to Gradle if needed.

[R. Rajesh Jeba Anbiah]

On Tuesday, 12 March 2013 00:54:12 UTC+5:30, Stéphane Cl wrote:

Ok, I see your point,
To be honest, I have just learned that some people were starting a fork of play 1.x. I dug a bit into the google group list, trying to avoid posts with users stating that yalp should be Ruby on rails, like this or like that. It is still unclear to me whether the next step would be releasing a 1.3 clone or directly developing what a non-scala "play20" might have been.

So, how you wanted the framework to be? What will make you interested in this framework? Maven & 1.3 maintenance? (Just curious) 

[Stéphane Cl]

Hello,

I guess there are two separate kinds of expectations about Yalp :

1) It's pretty clear by now that 1.3 isn't getting much attention from the play team, so people that have invested in play 1.x would like to see it being actively developed. They would like a solution with little to no migration.

2) On the other hand, there are people that are not really tied to play1 or ready to put some efforts into migrating, they are mostly looking for an alternative because they are unhappy with play2 scala nature, they find it slow to compile (a single change in a template file followed by a refresh in browser takes easily 8-15 seconds).

I belong in group #2.

Choosing to be 1.3 compatible could be interesting for you because it may attract some play1 adopters that didn't make the move. However, if you're planning to work on a v2 with a lot of breaking changes, you can be sure that you will deal with a lot of unhappy people saying that you're doing exactly the same as play team did before. 

So I'd say : if you want to continue developing play1 it's fine but if your goal in the short-term is to to release you own major version of the framework, it's better to take that road directly as I don't think it is a good idea to do it step by step. You would be stuck with a lot of legacy code and a lot of unhappy users asking for backward compatibility.  

If it was only about me, I'd avoid being stuck in supporting an 1.35 branch and move ahead. Where exactly? It's simple, see play2. People were angry about the incompatibility with play2, other than that it's a very elegant web framework. Keep the routes file, remove the scala nature, use a solid, compiled template engine like japid (or perhaps rythm) that offers error checking and fast compilation time and you'd have an excellent java framework. I wouldn't even try to be "full stack", support for Spring, guice, Ebean or hibernate can be provided by dedicated modules, a simple connection pool would be enough as a start and people could use their own favorite persistence framework as a separate module/library that they can independently upgrade to newest versions. It means less maintenance on the core and more liberty for future changes.

What I like about play is the MVC stuff, compiled views templates and the "hit-refresh-button" deployment. Other than that, nothing has to be part of the core, people should be free to use whatever they prefer for persistence, dependency injection and such.

That's my opinion (you asked for it after all ;-) ), I am in no position to tell what is right or wrong but in any case, you should really decide asap whether you're maintaining and improving play 1.x or rather developing something different while preserving play1 philosophy. 

Best

[Andy Lewis]

I'm pretty much in agreement with Stéphane - except that I'm in group 1)

I was initially excited about the idea that Play 1 would continue to see development, but I have absolutely no interest in such a development that doesn't have any real backward compatibility goals. If I'm going to make a major shift, I'd be more likely to go with Play2, with all that entails. 

[green]

Checkout https://github.com/yalpframework/yalp/issues/14, which is the place to discuss the vision of Yalp. In terms of 1.x compatibility I think it is pretty already decided that it's not going to be a requirement of Yalp.

On Mon, Mar 18, 2013 at 5:59 AM, Andy Lewis <an...@straycat.me.uk> wrote:

I'm pretty much in agreement with Stéphane - except that I'm in group 1)

I was initially excited about the idea that Play 1 would continue to see development, but I have absolutely no interest in such a development that doesn't have any real backward compatibility goals. If I'm going to make a major shift, I'd be more likely to go with Play2, with all that entails. 

--

You received this message because you are subscribed to the Google Groups "playone" group.

[R. Rajesh Jeba Anbiah]

On Monday, 18 March 2013 06:01:11 UTC+5:30, greenlaw110 wrote:

Checkout https://github.com/yalpframework/yalp/issues/14, which is the place to discuss the vision of Yalp. In terms of 1.x compatibility I think it is pretty already decided that it's not going to be a requirement of Yalp.

Thanks for the github link. But, I think, github may be more suitable for core devs and GG is suitable for users. Also, if we have decided to break the compatibility, please try to retain this group for play1 users; we may have a separate group for Yalp.

[R. Rajesh Jeba Anbiah]

On Monday, 18 March 2013 00:29:50 UTC+5:30, Andy Lewis wrote:

I'm pretty much in agreement with Stéphane - except that I'm in group 1)

I was initially excited about the idea that Play 1 would continue to see development, but I have absolutely no interest in such a development that doesn't have any real backward compatibility goals. If I'm going to make a major shift, I'd be more likely to go with Play2, with all that entails. 

 If I understand right, Play2 is more Sinatraish & Scalaish. So, Vertx might be better alternative. Play1 is half RoRish. I think, core developers are interested in building a complete stack but in "better" architecture. For example, Green previously mentioned some drawbacks of current plugin architecture. But, let's wait till they draft the manifesto; perhaps they may add backward compatibility option!