search

santoshko / codenameone

Automatically exported from code.google.com/p/codenameone
0 stars 0 forks source link

Allow manual inclusion of port files in builds #494

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This is a feature request that would make my life easier, and, if documented, 
would make it easier for the community to contribute bug fixes and features.

If there was a way to include modified files from the Ports along with a 
CodenameOne application build in such a way that it could override the server's 
versions, it would make it much easier to contribute new features and bug 
fixes.  This can almost be achieved already by placing port files in the native 
directory, but it doesn't work in all platforms.  E.g. Blackberry doesn't 
perform retroweaving on these files as it does with the server's port files so 
builds will fail.

The benefit of being able to test changes to the core directly on the build 
server is that it gives an extra level of assurance that the changes will work. 
 If developers use their own offline build, they can't be 100% sure that the 
environment is the same - and the likelihood of patches causing other problems 
increases.

At this point, I don't know how many people are trying to contribute to the 
core (probably a very small number).   But with the right documentation (which 
I intend to write, once I have worked out a solid development process that is 
easy for others to replicate) I would expect the community to grow, and others 
to start contributing too.

Just a "wish" of mine.

-Steve

Original issue reported on code.google.com by st...@weblite.ca on 19 Jan 2013 at 10:11

GoogleCodeExporter commented 9 years ago 
While this will be useful for some cases I'm not sure its something we would 
want to spend our time doing. With all the other HUGE tasks we need to complete 
(libraries, Windows Phone/RT support etc.) this is just really low in our stack.
Patches will cause problems that's inevitable, the solution is to have point 
releases which are stable/tested and a trunk where patches might sometimes 
disrupt. Ideally we should also have a QA trunk which is even more up to date 
than the main trunk.

Original comment by shai.almog on 20 Jan 2013 at 6:55