Tool LGenerator - Library Generator

thedesolatesoul

Expert
Licensed User
LGenerator is another python script wrapped in pyInstaller.

What it does?
It generates an xml/jar file for a wrapped library.
It is similar to SLC (SLC never worked for me).
It is the same as Ecplise's 2 step (Generate Javadoc + Export JAR).

What it doesnt do?
Automatically create libraries without writing Java code

Why?
To be able to create proper build scripts.
As I improve on this it will be possible to make a code change to a library, and a one-click:
- deployment on a device
- jar/xml saving
- commiting source / git
- uploading/updating javadocs

Other reasons:
- Want to change the method names or documentation in a text editor? Recompile with LGenerator!

Improvements:
- Testing
- Cleanup after generation


Download

 
Last edited:

thedesolatesoul

Expert
Licensed User
Tips
Package Naming

When naming packages in your library, create a separate package component for the classes you want to externalize. This way its easy to describe for the Doclet which classes you want the user to see (in the xml file).

Examples
Example batch file #1 - Instant Deployment and Eclipse Integration

This example generates the library, then copies it to AdditionalLibs, then compiles the apk, and then deploys it on a genymotion virtualbox. All in one click.
Essentially this means, you can make a code change in your library, and be ready to test it immediately.
It does require the B4A project/sample/testbed to be set up in advance obviously.

B4X:
REM BuildFile for MSMaterialDrawer
H:\MyProjects\Scripts\LGenerator.exe -p H:\MyProjects\Eclipse_workspace\workspace\MSMaterialDrawer -o H:\MyProjects\B4A\MyLibraries -d H:\MyProjects\BADoclet -i com.maximussoft.msmaterialdrawer
copy H:\MyProjects\B4A\MyLibraries\MSMaterialDrawer.jar H:\MyProjects\AdditionalLibs\.
copy H:\MyProjects\B4A\MyLibraries\MSMaterialDrawer.xml H:\MyProjects\AdditionalLibs\.
C:\Programs\Basic4android\B4ABuilder.exe -BaseFolder=H:\MyProjects\B4A\MSMaterialDrawer -Output=MSMaterialDrawer.apk
C:\Android\adt-bundle-windows-x86_64\sdk\platform-tools\adb.exe -s 192.168.56.101:5555 install -r H:\MyProjects\B4A\MSMaterialDrawer\Objects\MSMaterialDrawer.apk
C:\Android\adt-bundle-windows-x86_64\sdk\platform-tools\adb.exe -s 192.168.56.101:5555 shell am start -a android.intent.action.MAIN -n b4a.example/.main -f 0x10000000 -c android.intent.category.LAUNCHER
But wait, lets go one step further and integrate this INTO Eclipse!
Goto Run > External Tools > External Tools Configuration
Create a New Program configuration. (by selecting Program and clicking on the white icon on the top left)
In the Main tab, in Location, set the path to the batch script above.
Press Apply and Close.



(It is actually possible to pass more arguments to the script this way for e.g. project path, to create a much more generic build script).

Now pressing the Green play button with the briefcase on it, will execute the build script. You can even see the output in the Console window of Eclipse.


Further more, you can integrate it into eclipse by just dragging/dropping the build.bat file into the project. Now you can edit it in eclipse, and also run it from eclipse!

 
Last edited:

thedesolatesoul

Expert
Licensed User
Which error did you get with SLC? It is used by many developers (1000+).
Hmm...this isnt the correct thread to discuss the issues with SLC (but we can move it later). I know that it doesnt work for many other developers as well. Maybe they can post their experiences as well.

As an example:
Issues with Java7 (which is now mandatory I believe since Android5)
B4X:
Starting step: Compiling Java code.
javac 1.8.0_25
H:\MyProjects\Eclipse_workspace\workspace\MSMaterialDrawer\src\com\mikepenz\materialdrawer\Drawer.java:595: error: diamond operator is not supported in -source 1.5
            this.mDrawerItems = new ArrayList<>();
                                              ^
  (use -source 7 or higher to enable diamond operator)
1 error


Error.

Sometimes import errors when it cant find referenced jars (Eclipse is able to build these):
B4X:
Starting step: Compiling Java code.
javac 1.8.0_25
H:\MyProjects\Eclipse_workspace\workspace\MSStaggeredGridView\src\com\etsy\android\grid\ExtendableListView.java:26: error: package android.support.v4.util does not exist
import android.support.v4.util.SparseArrayCompat;
                              ^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error


Error.

I just tried the SLC after a long time, and it does seem to work at times, not at other times.
I have yet to test the LGenerator against most of my libs if it will work or not. I know it does ensure java compatibility by setting -source 1.7 -target 1.7.
 

keirS

Well-Known Member
Licensed User
Looks interesting. But aren't you reinventing the wheel somewhat? If you want to do proper build scripts why not use Gradle?
 

thedesolatesoul

Expert
Licensed User
Looks interesting. But aren't you reinventing the wheel somewhat? If you want to do proper build scripts why not use Gradle?
Gradle/Ant are not suited for what I want to do.
I think I have engineered my solution just to the right amount, (not over, not under).
I try to bend my tools to my whim, not bend myself to tools I dont like (like Gradle/Ant), especially when developing on a windows machine you are already so limited.
 

Erel

Administrator
Staff member
Licensed User

keirS

Well-Known Member
Licensed User
Gradle/Ant are not suited for what I want to do.
I think I have engineered my solution just to the right amount, (not over, not under).
I try to bend my tools to my whim, not bend myself to tools I dont like (like Gradle/Ant), especially when developing on a windows machine you are already so limited.
Fair enough. I have only really scratched the surface of Gradle. Building two different JAR's from the same source. One for B4A and one for B4J. But it does seem extremely powerful. I guess in many case it's a "using a sledge hammer to crack a nut" situation.
 

thedesolatesoul

Expert
Licensed User
Fair enough. I have only really scratched the surface of Gradle. Building two different JAR's from the same source. One for B4A and one for B4J. But it does seem extremely powerful. I guess in many case it's a "using a sledge hammer to crack a nut" situation.
Exactly, plus gradle is slow.
The other thing is that im not sure if gradle runs standalone without AS or Eclipse.
 

cimperia

Active Member
Licensed User
Exactly, plus gradle is slow.
The other thing is that im not sure if gradle runs standalone without AS or Eclipse.
I like your utililty and will have a play with it. Thank you for sharing your work.

A comment about Gradle, that I have been using for a few weeks now:

Gradle can run standalone and can be driven from the command prompt. It does not have to be installed as you can use its wrapper that does not need installing and can therefore be shipped with your software onto the machine where it requires to be built.

As far as being slow, I dont get that impression. It's slow to start-up (loading the jar, a one-time action), but then I found it pretty quick.
It's very versatile and its underlying language is Groovy which is really powerful and versatile.

Don't get me wrong, Python is a great language, but Google has officially embraced Android Studio and Gradle for Android development and it has or will become unavoidable. Many java projects I have been downloading are Gradle projects.

It took me a while to get to grip with Gradle, but it's actually quite nice and very rich. I had to manipulate Android archive files (aar) and in a very few lines of code, I could extract the jars, rename them and merge them. In fact, from Android Studio, I can start a "task" that will compile my project and deliver my wrapper library and xml file to my shared library directory.

One last point, Gradle is extensible, so if some functionality is missing, you can code it and add it yourself by writing your own plug-in.

It would be easy to create a GUI that would sit on top of Gradle for B4A developers...

Had I commented on this 3 weeks ago, my remarks would have been very different :)
 
Last edited:

thedesolatesoul

Expert
Licensed User
Thanks for your feedback, its nice to hear from someone who has actually used gradle.
This is very important information for me.

Just to explain why I went down the python route rather than gradle. I felt that learning python would help me in a lot more ways than gradle. Gradle would just be a one-purpose route for me. Besides, I dont have much confidence in Google's long term workflow stability. They did move to Gradle from Ant, and now there is Bazel on the horizon.

I havent used AndroidStudio to build libraries, but it would be helpful if there was a quick guide for that. aar is another thing i havent yet needed but who knows.

Anyway its seems that you have pretty much implemented the whole workflow using AS+Gradle, thats very cool. If I decide to re-evaluate my tools and workflow I might also go down that route. I have learnt a lot though about building jars and res files etc through the process.
 

cimperia

Active Member
Licensed User
No problem. We all have to make choices and pray that we have not chosen a dead end path and start again!

Groovy is easy to learn as it is syntactically very near to Java and is just another tool to add to your belt.

Here's a quick comparison chart between Python and Groovy and you'll see that they are pretty evenly matched on many points:
http://vschart.com/compare/groovy-programming-language/vs/python-programming-language

Regarding Bazel, I think it's still a long way off... and as long as Gradle is fully integrated with Android Studio I am not worried (famous last words).

In any case here what the Gradle team are saying about it: https://gradle.org/gradle-team-perspective-on-bazel/

I think it's time to get my crystal ball out...
 

PABLO2013

Active Member
Licensed User
Greetings, apologize the moment, I have been reviewing your project and it is very good for me, I wanted to know that it can cause this error, I use win 7 64, thanks
 

Attachments

Top