Community
Participate
Working Groups
See bug 26070.
This includes removing all appearances of non-Eclipse terms (like Apache) in code and properties files.
About this extension point for non-JDK generators - I don't think it's reasonable to force user to create a new plug-in just to provide a few strings. My idea is this: add 'Custom builder' in toString() code style combo and put 'Configure...' button right next to it (it will be active only when 'Custom builder' is selected). The button will open a dialog where builder class, methods and labels can be defined. This solution makes it relatively easy to define a new custom builder. I'm not sure if it should be possible to store several configurations (in case user wants to quickly switch between them without need to replacing all the texts in the dialog). This would make the dialog more complicated so it might not be worth it (I assume it would be very rare to use more than one custom builder). What do you think? Shall I implement it? :)
> The button will open a dialog where builder class, >methods and labels can be defined. You mean you would enter the source code for the build into the UI?
(In reply to comment #3) > You mean you would enter the source code for the build into the UI? > The dialog I mentioned will not contain any source code. It will be a simple form with following fields (example values in parenthesis): - Builder class ("org.apache.commons.lang.builder.ToStringBuilder") - Builder label ("builder") - Append method ("append(String, Object)") - Result method ("toString()") - Chain invocations (checkbox) I wonder if it should be also possible to chose the builder constructor. If a constructor takes some parameters, its values would need to be defined, which complicates the whole thing. Apache and Spring libraries provide the same constructor type (taking an Object), so to keep it simple we may assume this type will always be used (or if it doesn't exist, the default constructor).
(In reply to comment #4) That's a very nice proposal. > Apache and Spring libraries provide the same > constructor type (taking an Object), so to keep it simple we may assume this > type will always be used (or if it doesn't exist, the default constructor). Yes, just assume that there's a constructor that takes a single Object as argument (the default constructor wouldn't work, since you couldn't tell the builder what object to use). (In reply to comment #2) > What do you think? Shall I implement it? :) Yes, that would be great. Please update to HEAD before you start working on this. I released some other changes today, but I don't have other major changes on the plan.
Mateusz, did you already make some progress here? We only have 1 week left till M7, and since I don't have time to implement this, I would have to take out all the code that refers to Apache/Spring for 3.5.
Created attachment 132244 [details] patch The code is actually finished, I've left myself some time to polish it and add user documentation. Since there's not much time left, here's the main code and tests so you can check it for any issues. I'll post the documentation separately (I think by the end of the weekend). The code is clean from Apache/Spring references. I think it would be worth to mention that custom creator was made with commons-lang and spring-framework libraries in mind. Won't it break the IP rules? Also, I'm not sure about copyright note in one file. I renamed ApacheBuilderStringCreatorGenerator.java to CustomBuilderGenerator.java so it's seen by cvs as completely new file. Should I leave the information about contribution to bug 26070 (I've left it for now)? The patch is pretty big, so I have to make a statement: I confirm that all the code that I have submitted and will submit to this bug (the Code) is written exclusively by me. I am the owner of the Code and have the right to contribute it to Eclipe. I want to contribute the Code under Eclipse Public License.
(In reply to comment #7) > The code is clean from Apache/Spring references. I think it would be worth to > mention that custom creator was made with commons-lang and spring-framework > libraries in mind. Won't it break the IP rules? To clarify, I mean mentioning it in user documentation.
> > The code is clean from Apache/Spring references. I think it would be worth to > > mention that custom creator was made with commons-lang and spring-framework > > libraries in mind. Won't it break the IP rules? > To clarify, I mean mentioning it in user documentation. That's OK, as long as the doc stays general and only mentions those as examples.
Created attachment 132525 [details] patch2 Added user doc and improved checking argument types and return types for append methods in CustomBuilderGenerator.
Thanks for the patch! I released it with a few changes, e.g.: - catching NPEs from your own code like in GenerateToStringDialog.CustomBuilderConfigurationDialog.updateCombos() is just always wrong - replaced the term "label" in the configure dialog by "variable name" - fixed some typos in Javadoc and doc
