Don't use Retroweaver in debug builds [Was: Some Sugestions]

[GoogleCodeExporter]

Hi, i like allot Pulp Core, but i think the build system needs to be
redesigned.

Don´t know if you ever used Netbeans, Netbeans use ant also for build and
run java applications. I make a project and run, it wont build up a jar but
run from the /build directory, and when i change one file, only that file
is compiled and it quick run the application again

In Pulp Core every time i change something, i have to compile everything,
remake all res, rebuild jar, retroweaver it and then run on Pulp Player.

That slows down development.

I think with some work you could do this.

When we call ant (run) it automatic build ( res ( svg, fonts, etc... ),
sources ) into the build/ folder and Pulp Player would run from the
classes, without jar them. So when we change anything on res or source, ant
would check for file date and if its newer then compile/copy it to build/
folder then Pulp Player can run it again.

Now when we do a "ant build" it will do the compile check ( same as for run
) and then make the jar\zip and all other needed files, and also retroweave
and proguard the files.

This might be hard to implement, but will result in a lot faster deployment
of the games

Another suggestion ( that might not be so good ) is:
Separate the code into 2 jars, one with just basic applet stuff that would
load very fast on browser, other other with extra code plus game code, and
maybe the res also, and then after load the first jar, use ClassLoader to
load the other jar, don't know if it works on applets but might work.
This would just give a faster loading on applet on browser, but then take
more time on downloading extra classes
The only advantage, is that applet will be created on page lots faster, i think

Original issue reported on code.google.com by porfirio...@gmail.com on 14 Mar 2008 at 7:58

[GoogleCodeExporter]

This is not a defect, its a suggestion but Google code issue tracker is very 
simplist

Original comment by porfirio...@gmail.com on 14 Mar 2008 at 7:59

[GoogleCodeExporter]

Hi, and thanks for the input and thought you've put into this! I understand the 
need to make sure build scripts are fast.

Eric Berry is in charge of the NetBeans plugin, which might address the speed 
of compilation. In Ant, all of the classes 
are recompiled because it is actually faster than only compiling classes that 
have changed (Ant has to do dependency 
analysis to do this correctly, which is quite slow)

The goal of the build script is to make building in 'debug' mode is fast. 

The two slowest steps are using ProGuard and re-creating all the assets. The 
build file only re-creates assets that have 
changed since the last build. By default, ProGuard is only used on 'release' 
mode. If either of these features aren't 
working correctly for you, please let me know, and it will be tracked in this 
Issue.

Building in 'debug' mode should only take a second or so. (Milpa is built in 
debug mode and started in PulpCore Player 
in less than a second.) 

The 2 jar idea is noted, but not possible with the applet security permissions.

Original comment by brack...@gmail.com on 14 Mar 2008 at 8:28

[GoogleCodeExporter]

I see. What about only do retroweave on release mode?

If the programmer is compiling on java 5 or 6 don't need java 1.4 compatibility 
to
quick run, so retroweave should only be done on release

also i am having some exceptions with proguard, later i will post them here

Original comment by porfirio...@gmail.com on 14 Mar 2008 at 8:35

[GoogleCodeExporter]

Sounds like a good idea, I'll change the script so that Retroweaver is only 
used in release mode.

For a separate ProGuard problem, please post to the group or start a new Issue!

Original comment by brack...@gmail.com on 14 Mar 2008 at 8:40

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

porfirioribeiro,
   I'm working on getting a different project ready for the Netbeans Module. This
project will have a structure similar to these guidelines.
http://java.sun.com/blueprints/code/projectconventions.html

It'll look close to this (still a work in progress)
[project root]
   main
      ###"production" code, assets and dependencies.
      /lib
         ### if applet, the jars will be decompressed and included in the applet jar.
         ### if application, the jars will be included in the JNLP (for a later
implementation)
      /src
          /java
          /assets
          /web
              /html
              /css
              /js
              /WEB-INF
                  web.xml ### Incase anyone wants to put this into tomcat or another
jsp container.
          ### other sources could go here like beanshell or javascript scripts (if
you have scripting in your games/animations).
   /test
      /lib
      /java
build.properties
build.xml ### This will be created by Netbeans, and will probably have 2 
additional
targets - deploy-applet and deploy-application.

I don't know when I'll be able to finish this all, but for the first release I 
hope
to have at least the project running with David's PulpCorePlayer in Netbeans 
outside
of running it from Ant.
If you want to try the NBM here's the project url:
http://code.google.com/p/pulpcorenb/

Original comment by elbe...@gmail.com on 15 Mar 2008 at 12:42

[GoogleCodeExporter]

On second thought I'm going to leave in Retroweaver on by default for all 
builds because 1) It's not much of a 
bottleneck (less than a second or so) and 2) Many developers publish 'debug' 
applets, it's better for PulpCore if 
those applets can be viewed by people with Java 1.4.

Savvy developers can still disable Retroweaver by changing the condition in the 
"init" target to this code:
<condition property="do.retroweaver">
            <and>
                <equals arg1="${pulpcore.build}" arg2="release" />
                <equals arg1="${pulpcore.java.language}" arg2="1.5" />
            </and>
        </condition>

Original comment by brack...@gmail.com on 15 Mar 2008 at 1:23

• Changed title: Don't use Retroweaver in debug builds [Was: Some Sugestions]
• Changed state: WontFix

[GoogleCodeExporter]

elberry:
You should make it like a Java Project, one thing i really miss is JavaDoc, and 
ant
project is not easy to add javadocs

I am already using your module still lots need to be done, maybe some properties
panel were we can change some basic settings like pulpcore path, version etc, i 
would
love to help, but i am not very good with nb modules.

brackeen:
I understand, and yes, easy for end developer to change :p, and thanks for the 
snippet

Original comment by porfirio...@gmail.com on 15 Mar 2008 at 10:02