Honza,
Nice solution. My old solution using shell scripts and ant was a lot simpler.
-- A java class object with just static variables, BUILD_DATE, BUILD_NUMBER….
-- In shell scrips I would pull the date and last revision number from
subversion. Then using a simple echo command I would build a new java class
file.
-- I have yet to take the time and see how I can integrate the ability to pull
the information from subversion into Maven. I even had shell scripts to
generate release changes, store the RPM in a repository…. At some point I think
I will have to spend a few weeks converting all my shell scripts, ant build
scripts to Maven.
Tim
On Jun 13, 2013, at 10:21 AM, Honza Rames <rame...@gmail.com> wrote:
> Hi Frank,
>
> I have a XML (version.xml) document in my war directory:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE version [<!ATTLIST build id ID #IMPLIED>]>
> <version>
> <build id="build">76</build>
> <!-- Another data if you need it -->
> </version>
>
> A linker that increments the build number after the link process has been
> completed:
>
> package my.pkg;
>
> import com.google.gwt.core.ext.LinkerContext;
> import com.google.gwt.core.ext.TreeLogger;
> import com.google.gwt.core.ext.UnableToCompleteException;
> import com.google.gwt.core.ext.linker.AbstractLinker;
> import com.google.gwt.core.ext.linker.ArtifactSet;
> import com.google.gwt.core.ext.linker.LinkerOrder;
> import com.google.gwt.core.ext.linker.LinkerOrder.Order;
> import com.google.gwt.core.ext.linker.Shardable;
>
> /**
> * Just a linker that will increment build after compilation is done
> * @author SHadoW
> *
> */
> @LinkerOrder(Order.POST)
> @Shardable
> public class IncBuildLinker extends AbstractLinker
> {
> private static boolean incremented = false;
>
> @Override
> public String getDescription()
> {
> return "IncBuildLinker";
> }
>
> @Override
> public ArtifactSet link(TreeLogger logger, LinkerContext context,
> ArtifactSet artifacts, boolean onePermutation) throws
> UnableToCompleteException
> {
> //Do this only once after the entire link process has completed
> if (onePermutation && (! incremented))
> {
> BuildHelper.incBuildAndSave(logger); //Do this only after all
> permutations has been compiled
> incremented = true;
> }
> return super.link(logger, context, artifacts);
> }
> }
>
> the BuildHelper class accesses the version.xml and I don't want to post it
> here because it is pretty straight forward but still a lot of code ;-). And
> the generator (it uses some of my classes that ease the code generation)
> which creates an implementation for BuildInfo interface that you instantiate
> with GWT.create(BuildInfo.class) which looks as follows:
>
> package my.pkg;
>
> import java.util.Date;
>
> import com.google.gwt.dev.About;
> import my.pkg.generators.BaseGenerator;
> import my.pkg.generators.BaseGeneratorClient;
>
> public class BuildGenerator extends BaseGenerator
> {
> /* I'm using some helpers in generation process that's why I have the
> Client class here, it defines some functions that make it easier to generate
> java code in hand*/
> @Override
> protected BaseGeneratorClient getClient()
> {
> return new Client();
> }
>
> class Client extends BaseGeneratorClient
> {
> /* This gets called by the generator once the class imports and
> declaration is written by the generator */
> @Override
> protected void doGenerate()
> {
> writeBlockIntro("public String getBuildDate()");
> writeReturn(STR, (new Date()).toString());
> writeBlockOutro();
>
> writeBlockIntro("public int getBuildNumber()");
> writeReturn(BuildHelper.getBuildNumber());
> writeBlockOutro();
>
> writeBlockIntro("public String getGwtSvnRev()");
> writeReturn(STR, About.getGwtSvnRev()); //This is saved during GWT
> build process and can only be accessed in plain java
> writeBlockOutro();
> }
> }
> }
>
> and of course appropriately set module.gwt.xml that includes:
>
> <define-linker name="incbuild" class="my.pkg.IncBuildLinker" />
> <add-linker name="incbuild" />
>
> <generate-with class="my.pkg.BuildGenerator">
> <when-type-is class="my.pkg.client.BuildInfo"/>
> </generate-with>
>
> it is useful to have multiple modules that only one of them includes the
> linker so you only increment the build number after you compile for
> production so that development builds don't increment the build number.
>
> Everybody else not interested in my solution sorry for the longish post, I
> din't see any other way how to do this.
> If anybody else need more explanation I could provide full source codes
> directly if needed, feel free to ask any questions ;-)
>
> Honza
>
> On Thursday, June 13, 2013 9:46:22 AM UTC+2, Frank Hossfeld wrote:
> Hi Honza,
>
> your implementation sounds intresting.
> Can you provide more informations about your solution?
>
> Thanks Frank
>
> Am Mittwoch, 12. Juni 2013 09:50:41 UTC+2 schrieb Honza Rames:
> I have a XML file that stores various information about my build and is
> updated by a Linker which increments build number each build I make. And I
> have a generator that returns an interface that I can use in GWT app which
> includes the build number, revision, build date etc.
>
> Regards
>
> Honza
>
> On Tuesday, June 11, 2013 7:17:42 PM UTC+2, Joseph Lust wrote:
> For various reasons you need to know the revision of the GWT app code. For
> example to verify that the server API is not newer than the JS code (i.e. if
> you deploy GWT JS to a CDN).
>
> Some common approaches which I find to be rather hackish:
> Use Maven replacer to replace a sequence in a source file at the validation
> stage and have that inlined into your GWT file at compile (hackish)
> Use Maven replacer or Maven war plugin filters to add the build number to the
> index.html page, or a backend service (JS code still not independently
> versioned, more API calls)
> Hardcode it (don't hardcode things)
> After two years, the best method I've see is to create a code generator to
> allow deferred binding of the build number. This however has always stuck me
> as massively overkill to add a number to a build artifact.
>
>
> So, I was curious how others here have dealt with this common issue.
> Hopefully there is a simpler way.
>
>
> Sincerely,
> Joseph
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
