Questions about project structure and distribution best practices

118 views
Skip to first unread message

Pierre-David Bélanger

unread,
Jan 5, 2017, 1:32:11 PM1/5/17
to Haxe
Hi!

I am new to Haxe. But I know enough to understand the syntax, write some code, compile and run some little toy projects.

Now, I want to apply my knowledge to one of my open source project (https://github.com/pierredavidbelanger/chatter-bot-api).
This is a fairly simple project that provide an unified high level API (a library) for some other web services.
The code is manually ported (each time I make a fix) to Java, .NET, PHP and Python (this is why I am looking at Haxe :))
Anyways, the code is really simple, I almost finished coding the POC in Haxe.

I guess my problem now is that I do not know what are the best practices regarding the project structure (folders layout) and the distribution of the resulting ports.

I do not have a particular question, I just know that some pieces are missing in my head, but here are some questions I have in mind, in no particular order:

1) How should I structure my project to have one source folder for the Haxe code, and many test source folders for the tests/demo code written in Java, .NET, PHP or Python ?

2) should I have a Makefile or something to help me build and test all ports in one operation ?

3) how do I distribute the resulting ports (for example: with maven for the Java port, or pip for Python or composer for PHP) ? 

4) should I commit the "generated" code (given the way pip or composer works, I guess the answer should be yes) ?

5) How can I tel the Haxe compiler to output java code in a maven supported way ?

6) should I write tests in Haxe or in the resulting ports language ?

7) what if I do not like having the clients of my library seeing all the Haxe stuff in the classpath (for example: all the haxe.lang.* stuff in the resulting Java port) ?

8) Am I in the right direction with this use case (wanting to use Haxe to maintain one source code and generate/distribute ports out of it)?

I guess you get the picture, I really do not know what I am doing ;)
Your help will be much appreciated.

Thank you!

Pierre-David Bélanger

unread,
Jan 6, 2017, 9:42:44 AM1/6/17
to Haxe
I am sorry, I guess the question was too broad ;)

I will start with only one question:

Given that the project is already published on Maven Central: https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22chatter-bot-api%22
Given that I know how to re-write the current project into Haxe source code.

How do I refactor my project to be able to compile this Haxe sources into Java and then publish the resulting artifact to Maven ?

David Elahee

unread,
Jan 6, 2017, 9:48:07 AM1/6/17
to haxe...@googlegroups.com
Ola pal!
This is really narrow industrial questions, not much of us mays use a combination of all those...I suggest you just lurk on major haxe player's github. You should find most of your answers. You can also go to IRC but I guess maven things is a bit alien ^^.

Cheers,

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.



--
David Elahee


JLM

unread,
Jan 6, 2017, 9:55:55 AM1/6/17
to Haxe
Maybe have a look at the github for projects that do this already.
http://mirror.vsibiri.info/libraries.io/search-languages=Haxe&licenses=MIT.htm
http://mirror.vsibiri.info/libraries.io/search-languages=Haxe&licenses=Apache-2.0.htm

For users that might find Haxe confusing you could have a haxelib github with the output and then use that as a submodule for a github for each platform specific repositories, so they could github --recursive ....myLibJava  to get the source, then you can deal with any packaging approaches in the external resources.

It should be feasible to run the main tests just in Haxe and even hook up to Travis it should be feasible for travis to deal with getting code from another github, I do not see any reason why you can't also export some of the tests to each platform, but might have to think that through!
https://docs.travis-ci.com/user/languages/haxe

There are a few unit testing libraries ( massive perhaps ) but perhaps look at the basic built in one first.
https://haxe.org/manual/std-unit-testing.html

There is no current best practice as not many people are actually submitting outputs to target distributions beyond npm, I think.

Pierre-David Bélanger

unread,
Jan 6, 2017, 5:39:52 PM1/6/17
to Haxe
Thank you for your reply!

For the Maven part, I will have a look at this one https://github.com/qifun/json-stream

"For users that might find Haxe confusing", I do not talk about the original Haxe source code, but the generated symbols into the resulting ports.
For example, when I compile Haxe to Java, in the resulting jar, I have a packages called "haxe.lang" or "haxe.root" etc.. 
The content of those package (essentially runtime implementation related stuff) will be accessible to the client of my lib.
Also, this pose the problem: what if a project depends on my Java generated Haxe lib and also an other 3rd party Java generated Haxe lib, the final project will have clashing "haxe.*" package in the classpath.

wighawag

unread,
Jan 8, 2017, 8:15:08 AM1/8/17
to haxe...@googlegroups.com
That's a good point regarding multiple haxe generated java lib. This is similar in the JavaScript world except here there is no clashing but wasted resources though that's not always wasted

The main problem in solving it often involve losing some of the haxe feature such as dead code elimination and in lining but I think there should be an easy option to generate a std lib for each target.


--
Reply all
Reply to author
Forward
0 new messages