The problem we have are as follows:
We are using ANT to build our application. However, the application is built multiple times, once for each client (they have different skins / cms / i18n etc). Up to now, we had no need to compile them all at once (usually just work on one client at a time). Now, we want our build server to build all permutations for all clients in all languages. In other words, we need to create a war file for each client, each containing their own compilation.
At the moment, the client name is read in from the application's .properties file.
My question is this. Is there any way that the client.name property (from the application's .properties) be overridden in the build.xml used by ant? Or is the only way to create a different target for each client and hard-coding the name?
Thanks.
If you use Hudson to do your build, and have more than one parameter to change, you should be able to do a Matrix Build. There is more detail in this answer.
If it is just one parameter, you should be able to do a properties file and use Ant to read this properties file and iterate through it - I'm not sure precisely how, but you won't be the first person to have this problem, and if you are it wouldn't be difficult to create your own task. Or if not use Macros.
Related
Our project files have an absolute path and I am trying to replace instances of these with Linked Resources in order to make the dev environment portable between different workstations.
Our Windows workstations already have a number of useful environment variables set to determine the location of various resources needed to build parts of the project.
Now I'm finding that from Flex Builder (i.e. Eclipse) it is not possible to use these environment variables, but that each user will have to go into the Workspace>General settings and set up "Linked Resources", which are for all intents and purposes exactly the same thing as environment variables, but for Eclipse. This is an extra, repetitive step consider this information is already available on the workstations. Is there no way to tell Eclipse to use an environment variable instead of a Linked Resource, or to make a Linked Resources which references an environment variable?
I am thinking the only convenient solution may be a batch file to create the Linked Resource automatically, but this seems kludgy and error-prone to me.
Yes! You can use the ${ENV-name} token in the Eclipse Linked Resources sheet in the project properties dialog. For instance, if you specify ${ENV-TEMP} it will resolve to the value of the environment variable TEMP.
(Oddly, I could not find an explanation of the ${ENV} syntax anywhere on the web, but I just guessed that it might use ${ENV-name} syntax, similar to how ${project_loc}/.. is converted to PARENT-1-project_loc...)
I am working on a project using GWT and Maven that I am including internationalization in. It seems to me that it takes longer to build and run the i18n generated files than it does to add new strings into my Constants interface manually.
My question is: Is it required that I include the i18n goal in the POM? Or is it just a tool intended to make it easier to create a Constants interface from a pre-existing properties file? I am new to Maven and believe the goal is just a tool, but am unable to confirm based on my research that it is not needed. Thanks for any help you can give.
Nope, not required - as you say, it is just there to make it easier. The same is true of the gwt:generateAsync goal, which builds the Async RPC interfaces for you, based on the RemoteService subtypes you've already defined.
I don't use either one - I prefer to build my own, and document where needed (or not). My poms include just a gwt:test for any unit tests I've devised, and a gwt:compile to actually compile to JavaScript.
Keep in mind that a significant percentage of GWT developers do not use Maven, and Constants/Messages and RPC still works just fine for them without these goals.
If you ask me, you should not use the i18n goal in your POM. It should only be used once in a while to synchronize your code (interface) with a properties file. On a day-to-day basis, you should rather work with your interfaces for the canonical locale and manually update the properties files for the translations.
There are way too much things you can do with a Constants or Messages interface that cannot be inferred from a properties file: non-string constants, plurals in messages, etc.
I wrote a an aspect called [NLogMethods] that logs method boundry to nlog, based on the example from Postsharp website.
I'd like to apply it to multiple DLLs in my infrastructure, for use in some of my applications.
in order to do this - I need to check out the project file of each DLL, add references to PostSharp, nlog and my aspects DLL, and add an attribute to AssemblyInfo.cs.
I rather not do it, but rather do it centrally in the application, or in an external tool.
Is there a way to apply the aspects (to entire assemblies) without editing those assemblies?
You can setup a batch script to apply the aspect on build.
http://programmersunlimited.wordpress.com/2011/08/16/exposing-internal-methods-in-3rd-party-assemblies-for-external-use/
http://programmersunlimited.wordpress.com/2011/07/27/applying-aspects-to-3rd-party-assemblies-using-postsharp/
You can also build a custom targets file, but I can't seem to find the reference for that.
I was wondering whether it was possible for projects in Eclipse to have multiple languages associated with them, specifically PHP and Java. The purpose of this is that I'd like a common 'properties' file for the two projects.
If instead there's a way to hold a relative reference to a file so that both projects can reference the properties file, that will work too.
Part one of the question
whether it was possible for projects
in Eclipse to have multiple languages
associated with them, specifically PHP
and Java
No, a project in eclipse is language dependent. You could technically write some source in another language and then use another build method to compile from the secondary language - Not recommended !!!
For the second part of the question ...
Common Property files
Create another project and in that project put a java properties file.
Have both projects (Java and PHP) read the property file from here (In Java just add where you put the file as part of the classpath)
In PHP use this Java properties reader
If you are careful on how you write the Java properties file you could also use parse_ini_file
You could just place the properties you want the two languages to share into a plain text file. Then code a PHP file to read the plain text file, and code a Java file to read the plain text file. Be careful if you plan on having your two projects edit said-file though. If there's any chance that both of them could be editing the file at the same time, you're in trouble.
What is the difference between Java Build Path - Add External JARs Button and Add Variable Button Functionality,
Why its required. Please explain in detail.
Both can be used to achieve the same thing: add a JAR to your build path.
Suppose you have a project P1 that wants to use a JAR installed by supplier S1, which happens to be located at C:\S1\aproject\jars\Useful.jar
Client Add External JARs, navigate, select, and we're done.
But, consider these cases.
1). Suppose you have several projects that all want to use that same JAR? You end up repeating that for projects P1-PN. Gets dull. What's worse, suppose you install a new version of S1's stack, now you need to update all those project's build paths to reference
C:\S1\aproject-**v2**\jars\Useful.jar
And what's worse, if you miss one then you are running two versions of the JAR that may be really bad!
2). You share a project with a colleage who happens to have S1 product installed in a different location. They now need to amend the project to point to
E:\MyFavouriteThings\S1\aproject\jars\Useful.jar
And if you are using an SCM you may tread on each others toes.
So:
Instead Add Variable allows you to define a Workspace variable (ie. specific to your environment) which can then be used to reference that JAR
$(S1_JARS)\\Useful.jar
Now you a single place to update to a new version of S1, and each developer can set his own value for S1_JARs.
I would recommend using Variables for non-trivial development scenarios.