search

codenameone / CodenameOne

Cross-platform framework for building truly native mobile apps with Java or Kotlin. Write Once Run Anywhere support for iOS, Android, Desktop & Web.
https://www.codenameone.com/
Other
1.71k stars 409 forks source link

RFE: Include Source on failed builds #1500

Closed DigNZ closed 7 years ago

DigNZ commented 9 years ago

There have been many times when a build will fail and the error log doesn't provide enough information without the source. It should be possible to request the sources for a failed build and get the build folder sent.

As a one example: /home/ec2-user/android-sdk/tools/ant/build.xml:875: Expecting java type before ';' in line 66 of file '/tmp/build3473113682613998566xxx/Aurecon/proguard.cfg', included from line 2 of embedded configuration

Clearly something I've added in android.proguardKeep is incorrect, but as its copied exactly from another project that does work, its hard to diagnose without seeing what is on line 66 of proguard.cfg. If I had the file I'd fix it in no time and save the additional server load of a lot of speculative builds getting to the bottom of what is going on...

codenameone commented 9 years ago

There are some difficulties here, its actually something we want for our testing purposes too but its very problematic with our current architecture.

gardner commented 8 years ago

This is my number one issue with using the hosted build service. When something goes wrong you get the what but not the how. I need to be able to inspect a file that is generating an error, otherwise I am reduced to guessing which does not feel good especially when the full feedback loop takes ~10min.

codenameone commented 7 years ago

I've given this more thought and came to the conclusion that this is something that we are opposed to philosophically which is why we didn't have it in the first place.

The goal is to never need this thing. If we add it we'll never be able to remove it and this will hinder our goal...

The problem is that once something like this exists I can see a lot of developers just building the source and ignoring the fact that something fails. Just chucking it up as "Codename One bug" and never bothering to report or communicate on that. If you think this won't become the norm for some users then you worked with a different set of developers than I did and were lucky!

In the enterprise tier we have the offline build which should work pretty much like that and answer this issue, no it's not available for everyone and it doesn't make working with native code easier.

I understand the problem this issue demonstrates and it's always inconvenient to say that we "don't want to fix" a problem but I hope you understand the logic behind this.

PiotrZub commented 5 years ago

Sorry but I totally do not agree with the way you thinking. In my case, despite buying a Basic plan, I can not download sources, not because they do not generate but because you do not want to share them. This is unfair. I pay for some service and you just state we do not provide it.

codenameone commented 5 years ago

If the claim is one of payment we have a money back guarantee, you don't have to pay. The equivalent for this claim would be me walking into a restaurant and demanding they sell me the ingredients that make up the meal unprepared for me to make at home.

If this was enabled people wouldn't bother reporting issues or trying to fix their code. You have a problem with your project and are looking for a workaround instead of fixing it. That isn't the right approach.

gardner commented 5 years ago

The equivalent for this claim would be asking to see the ingredients after the food came out bad. Your fear is that people could make the meal at home after seeing the ingredients. The IP that you are protecting is increasingly less valuable as open source competitors encroach on your market with products that have more support, larger developer bases, and more free licensing. The desire to keep your trade secrets, secret, creates a problem for your developers. Your existing customers trust you to provide the build service that you do. There is very little threat of someone stealing your code to compete with you. Now is the time to open your code and keep providing the same value that you always have.

Eventually, I did ask for my money back and I left the platform. This is not the outcome that you desire. I do find CN1 to be novel and I commend you on a job well done. It is amazing software. Keep thinking about ways to make the software better and ways to evolve the business model.

Kind regards

codenameone commented 5 years ago

I mentioned no fear of IP. If there was there wouldn't be an include source feature to begin with. Our code is open source and available in this repo. There is no IP concern. You clearly didn't bother reading anything I wrote here. This has nothing to do with "trade secretes".

gardner commented 5 years ago

It does seem like a huge misunderstanding. I had the understanding that a developer cannot setup the entire build chain themselves on their own machine. I understood that to build binaries a developer must pay to use the hosted build service. Did that change in the past 18 months? Have I had the wrong idea this whole time? Thanks

codenameone commented 5 years ago

You were wrong the whole time. We just don't provide much support for building manually as the toolchain is designed for the cloud build but we don't have any restrictive licensing (never did) and we don't have a problem with people doing that. It's even mentioned in our help article and FAQ https://help.codenameone.com/en-us/article/is-codename-one-free-slkwhu/ It's been that way since we launched in 2012.

gardner commented 5 years ago

I joined at an unfortunate time when the build servers were upgrading their version of gradle. This meant that I pushed a commit one day and it built successfully. When I tried pushing the same commit again on the next day it failed. This is what I mean by non-deterministic. If things outside of my control are changing the outcome then how can I own the troubleshooting process? It was during this time that I learned that the chatbox on the website is not the support chatbox (it is called that now though...) After helping me for a while, I was directed to post to stack overflow. I was asked to tag the project name in my question. This made it seem like I was being asked somehow to promote the product on a global stage instead of getting an answer to my question. I understand the ideas behind building a KB and sharing information but something about this left a bad taste in my mouth.

In my effort to solve the build problems by bringing everything in-house I found shannah's amazing work that came with the caveat:

PLEASE USE THE Codename One Build Server for all of your production builds, and for anything you wish to distribute for use by other users.

So while it may have been possible it wasn't obvious that there was any supported way, or even a way that I could DIY it successfully with blood sweat and tears. It did seem to me like your business hinged on the hosted build service and you were protecting your business by keeping your build system secret. This is what lead me to leave the platform:

  1. non-deterministic builds
  2. weird support model
  3. perceived conflicting business interests

@shannah archived his project with a message saying:

NOTE: This project is no longer maintained. I recommend using the supported build workflow for Codename One as described on the Codename One website.

I couldn't find any documentation on the website.

Thank you for accepting my feedback. I can't continue this message thread any longer. I wish you the best of luck.

p.s. You may want to run some SEO on that page. It looks like Google can only find 4 links to it.

PiotrZub commented 5 years ago

If this was enabled people wouldn't bother reporting issues or trying to fix their code. You have a problem with your project and are looking for a workaround instead of fixing it. That isn't the right approach.

You are mistaken, thanks to the possibility of downloading the source code, users will be able to submit proposals for solving the problem to CN1, not problems to be solved. Is this not the idea of ​​open software? In my case, because currently, I do not pay the Apple Developer Program, your system can not compile the code due to lack of certificate. Thanks to access to the code, I could do it locally and report possible errors. I have not noticed anywhere that using the CN1 requires paying for the Apple Developer Program. I have been paying for the use of CN1 for many years, I have reported many mistakes and corrections to the project at this time, in this situation, I am sad that the only thing you can offer is to give up CN1 :(

DigNZ commented 5 years ago

This is probably the main defining issue of why we no longer use CN1. More times than not an issue that has been reported needs to go back and forth with support while everyone speculates on the cause. We are capable enough developers to get the source of a failing build, fix it and then let you know what the issue is but we are totally prevented from doing so as we do not have source for failed builds.

As we've tracked resolutions when we request support we've noticed that more than half the time the fix is something on the build server that we have no control over and cannot contribute a solution to. In all cases CN1 support has pushed back several times before acknowledging or finding the cause of the problem - making a simple fix take several days to get resolved. Its not good for us or our customers.

A fairly hidden, unsupported and significantly more complex build process is not a solution. Having more eyes on any given issue is a benefit of open source and protecting or hiding elements of that can only be for a commercial reason despite what you are saying.

For the past year or so all of our new development has been on a different platform where we have complete control of a reproducible build process and the difference is night and day in terms of transparency, control and problem solving.

We still have a subscription for some legacy projects but will be cancelling once they are migrated.

codenameone commented 5 years ago

No. I see the build errors and you are incorrect.

The compilation stage is the one stage where we're the only ones qualified at fixing bugs. If we needed the generated source for that we would have added it. We usually don't need it and when we do need it we have the ability to run on a local server and pause it or similar hacks.

Once you can get a compiling build, getting it working and getting source code to resolve a compilation issue is key.

The reason for this specific hiding has no commercial purpose. Otherwise we wouldn't have had the include source working for passing builds... This has only a philosophical purpose where pretty much every one of the failing demographics don't need the source to solve their problem.

saeder commented 5 years ago

I quit my subscription years ago.

And it still drives me crazy that there is not much missing to make Codename One the perfect tool.

My situation was that I could not spend a lot of time to work with other tools except those with which I make my living. On average, I spent only about four hours a week working with code name One. On the other hand, Codename One would have been the right tool for that very reason.

However, I always despaired at the point when I found errors with which I could not live and which I could not correct. Although I was able to correct the errors locally I had no way to get my fixes on the build server. I could not get the fixes because the codename One Team was not willing to correct the bugs. And I have not been able provide any general corrections, such as pull requests, because I could not possibly judge whether my corrections would have worked well for the general public. Overshadowing would have been a way to live with codename One - but that was denied me for flimsy reasons. The consequence was that I could not work with codename One and that still drives me crazy, which is why I still follow the development and still try to help with my modest means.

The codename One Team just sets strange priorities when basic things like a switch component do not work reasonably well for years. And if things like the IOS specific rubberband effect do not or only faintly remind of the original then the quality impression of the apps that are made with it is simply too low.

Codename One could be good. It is almost good but one cannot work with that, crazy as it is.

Am Mi., 5. Juni 2019 um 05:37 Uhr schrieb Codename One < notifications@github.com>:

No. I see the build errors and you are incorrect.

-

1 percent is bugs on our end - this happens and we're the only ones who can fix it

2 percent means a library or something is out of date - which means you need to fix that or fix the library

1 percent is bugs in native code - you need to fix that and you get the error code. This is super easy to workaround with xcode

The HUGE majority including the one from the guy who started this chain is signing issues. Those are a pain but their a pain in the IDE too.

The compilation stage is the one stage where we're the only ones qualified at fixing bugs. If we needed the generated source for that we would have added it. We usually don't need it and when we do need it we have the ability to run on a local server and pause it or similar hacks.

Once you can get a compiling build, getting it working and getting source code to resolve a compilation issue is key.

The reason for this specific hiding has no commercial purpose. Otherwise we wouldn't have had the include source working for passing builds... This has only a philosophical purpose where pretty much every one of the failing demographics don't need the source to solve their problem.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/codenameone/CodenameOne/issues/1500?email_source=notifications&email_token=ACL4AK3ISQRW6UIWHXRAOK3PY4YHNA5CNFSM4BD6AYJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW6QIMI#issuecomment-498926641, or mute the thread https://github.com/notifications/unsubscribe-auth/ACL4AK64ELCYBOPF4UDR333PY4YHNANCNFSM4BD6AYJA .

-- Stefan Eder Korbinian-Aigner-Weg 1 84405 Dorfen

Handy +49 (0) 152 3954 1147

DigNZ commented 5 years ago

Ignoring your statistics which have nothing to do with my experience or what my comment was about.

The reason for this specific hiding has no commercial purpose. Otherwise we wouldn't have had the include source working for passing builds... This has only a philosophical purpose where pretty much every one of the failing demographics don't need the source to solve their problem.

But if its useful to anyone and they can help resolve problems with the build process then that helps CN1 get better via the community. Most users of any open source project can't or don't contribute to the project itself but that doesn't mean that everything is locked away from everyone. The benefits of open source are from eyes on it and not hiding things away from anyone. If source of failing builds is a distraction then improve your documentation or build process in general.

Arrogant support, strange decision making and temperamental builds have put me off CN1. I agree with other people here - this product has a lot of potential but this issue and the reaction from codenameone in response to this issue is symptomatic of why it doesn't reach this potential. I picked it as the best tool for the job many years ago. Better tools have come along now.

codenameone commented 5 years ago

You three are having three different discussions on three different subjects at once in a single issue so when I respond to something you're trying to take a personal grievance you have with something and make it generic. It isn't. I'm deeply familiar with all three of you and your issues. They have absolutely nothing in common and only @DigNZ has some applicability to this issue.

There are problems in our product. This isn't one of them.

But if its useful to anyone and they can help resolve problems with the build process then that helps CN1 get better via the community

Sure but that's a red herring. The code is there and very few people contribute regardless. If we provide the code on a build failure then 99 out of a 100 people would do the exact opposite of contributing. They would download the code and hack something or assume our product doesn't work. People would build their entire workflow around this and hardcode bugs/misbehavior into their product. That's how engineers work... If you don't think that's the case I'd like to smoke some of whatever it is you're smoking.

Nothing is hidden. All the code is here. Getting the source to a build error serves no legitimate purpose in the current state of the servers. There was a time where build errors were more common but now their distribution makes sense.

Arrogant support

I take that personally. I work very hard giving free support and the whole idea of rejecting this bug is that you make use of our support whether you're an enterprise user or a free user. When it comes to a compilation error we take this very seriously and everyone gets equal treatment.

gardner commented 5 years ago

The people on reddit ask vprise why this project hasn't gained more traction. We are trying to tell you why. Please take a step back and try to hear it again.

The reason why we are taking time to write is to help you. Please re-read the thread with the understanding that these aren't personal attacks. This is a post-mortem with valuable information on how to improve. It doesn't make sense to be defensive or argue the points. These are opinions of people who have left the platform. The only "winning" here is kaizen.

codenameone commented 5 years ago

I fully understand that this is what you "think" you're doing. I did read what you said here and I'm deeply familiar with each and every one of you're grievances since I've known your accounts for years.

Take a step back and think about you. Do you know the other two who commented here and what they actually complained about? Do you see the statistics and signup/cancellation results?

People assume that the problem their having is the common problem everyone is complaining about. That's bullshit. Everyone has a different problem and we discussed this multiple times in the appropriate place (which is the discussion forum and not a completely unrelated issue).

This issue has absolutely nothing to do with our traction glass ceiling. It's pretty easy for an a*hole on reddit to throw out nonsense that isn't backed up by evidence. We listen to everything but unlike you guys we know the facts. The facts are that we compete in a market where the other players are Facebook, Google and Microsoft. Getting any bit of press is nearly impossible. 99.9% of our target market didn't hear about us and we don't have the revenue/funding for the level of promotion these guys get for free. Community members in reddit serve as corporate shills (aka advocates) for these big companies. To make matters worse there fragmentation within the Java/Kotlin communities makes it so that we don't get backing/support from those communities either.

We are by far the largest solution for Java/Kotlin developers but because of the nature of these communities and their currently shrinking status it's not enough. Again, not a single one of your grievances has anything to do with these facts.

There is a claim that if we focus more on open source instead of a commercial offering we'd pick up traction. The problem is we can't do it. Our branding is already perceived as SaaS and we don't have the resources to setup a completely separate entity to handle that. However, if you actually wanted to do something proactive to handle your grievances you could actually do that. But most "open source" fans don't even bother. E.g. this guy: https://sourceforge.net/projects/cn1offandrnb/ Did some work on creating a fork of that type. If "open source" had any merit his project would have enjoyed huge traction and contributions. It didn't. We let him post about it to the discussion forum and we even mentioned it a few times. Even within our community it didn't pick up steam.

If you guys think you can do better why don't you take that up?

gardner commented 5 years ago

I concede; your logic is unassailable. You have won this most important argument.

Congratulations! You win! You are the winner of the argument! It's over!

Ciao!

codenameone commented 5 years ago

I don't think forking our product will put us out of business. On the contrary, it can help. We can't satisfy everyone as you three are a clear example of that. Good luck with forking and we'd help you with that if you need it.