What is the use of TargetNameSpace attribute in ant?
Does this have something to do with web services? I think I have used a similar attribute when working with axis web services.
<axis-java2wsdl classpathref="classpath" output="${wsdl.dir}/abc.wsdl" location="${service.url}" namespace="myns" classname="${serviceInterface}">
<mapping namespace="http://impl.app" package="${serviceInterface}" />
</axis-java2wsdl>
Not sure if this is even useful, still posting it in case it helps.
Related
We are using spring security and have it working well. I am trying to figure out one thing that has not being obvious - how do I configure ldap-server attribute to use different url based on deployed environment?
This is what I have that is working:
<ldap-server url="ldap://testserver:port/o=blah" manager-dn="cn=bind,ou=Users,o=blah" manager-password="password"/>
<authentication-manager id="authenticationManager" alias="authenticationManager">
<ldap-authentication-provider
user-search-filter="(cn={0})"
user-search-base="ou=Users"
group-search-filter="(uniqueMember={0})"
group-search-base="ou=groups"
group-role-attribute="cn"
role-prefix="none">
</ldap-authentication-provider>
Now, how do I configure it to use a different url based on deployed environment?
thanks in advance,
Sharath
I've done that with Spring profiles:
In your spring.*.xml config file use this at the end of your file:
<beans profile="production">
...
</beans>
<beans profile="local">
...
</beans>
As VM Arguments the used profile must be provided:
-Dspring.profiles.active=production
Regards
You can use the url as variables and set them in a properties file.
To change the properties file should be easier. I know you can do that with Maven - with jar or war plugin depending on packaging, including generating two (or more) packages with one execution - but I suppose you can with Ant or other managers too.
Of course, you could use that solution to change the whole xml, but it's easier to do that with a properties file because that way, when changing the configuration, the markup will not be in the way, only variables and values.
In an Ant target I get a property, containing the list of directories to be included in further action (copying, filtering, etc.). It looks like this:
directories=dir1, dir2, dir3
I need a way to convert this list to a fileset or patternset that selects all the files in these directories.
I know I can use a script to generate pattern strings and then use it in the "include" or "exclude", but is there are a way to avoid scripts?
Note that as of Ant 1.9.4, there is a new construct <multirootfileset> that provides that functionality, even if the dirs are not siblings:
<multirootfileset basedirs="${directories}" includes="**/*">
How about using the antcontrib propertyregex task to convert the comma-separated list into wildcards suitable for a fileset?
<property name="directories" value="dir1, dir2, dir3" />
<property name="wildcard" value="${file.separator}**${file.separator}*" />
<propertyregex property="my_pattern"
input="${directories}"
regexp=", "
replace="${wildcard}," />
At this point we now have:
my_pattern=dir1/**/*,dir2/**/*,dir3
That can be used with a further suffixed wildcard to get the full fileset:
<fileset dir="." id="my_fileset" includes="${my_pattern}${wildcard}" />
(The fiddly ${wildcard} is to ensure portability between unix and windows filesystems, you could use /**/* if you're pure unix.)
Something like this should work:
<dirset includes="${directories}"/>
Yes, dirset isn't fileset. However, it may be enough, or else you can probably use a for or foreach from ant-contrib to iterate over the directories in your target. You might also be able to define a ResourceCollection based around the dirset. It might help to know what the "further action" is expected to be.
However, this feels like too much work ...
I'd like to set some properties in my ant build file, the names of which, are based on ant's build in properties. In particular, I'd like to set a property like:
<property name="${ant.project.name}.compiled" value="true" />
However, when I tried this the ${ant.project.home} portion was not expanded.
Is it possible to use the value of properties as the names of other properties, and if so, how?
<property name="name.holder" value="iamholder" />
<property name="${name.holder}.flag" value="true" />
<echoproperties></echoproperties>
result:
[echoproperties] iamholder.flag=true
this is definitely valid ant code and the property iamholder.flag gets the value of true.
If ${name.holder} does not get expanded, it means it has not been set yet (like if the first line in my sample was missing).
Anyways, this still does not quite solve your problem, as you have pretty much no means of getting the value of this property as you don't know it's name and you can't do a nested resolve in pure ant. Depending on what you are trying to do it could still be useful to you though. This one would work (keep in mind, that until 1.8 the value is irrelevant as long as the property is set):
<target name="compile_stuff" unless="${name.holder}.flag">
<echo>compiling...</echo>
</target>
To really get the value of such a property you have to use ant-contrib's propertycopy as suggested in one of the answers. That way you can get the value in a property whose name you know. Just make sure to do the trick just before use and set the override parameter to true (your post implies that you would be setting more properties like these, but without override your final property could not be changed). Another option for working with such properties is to use ant macros.
I think the only way is to echo your values to a .properties file and then load them back.
However, you should ask yourself if you really need it; when I last used ant I tried to do the same thing but concluded I didn't really need to.
Is
$ant.project.home.compiled
not just as useful?
It can be done, a bit ugly, though. You need the < propertycopy > task from ant-contrib for this. The following shows an example
<property name="projectNameCompiled" value="${ant.project.name}.compiled" />
<property name="${projectNameCompiled}" value="true" />
<propertycopy property="final" from="${ant.project.name}.compiled" />
The property final contains the value true.
There are several ways to achieve that, see Ant FAQ
One possible solution via macrodef simulates the antcontrib / propertycopy task but doesn't need any external library.
I'm trying to build an app for both J2ME and J2SE. The presentation code will obviously be different, but I'm hoping to keep the logic common, as much as possible.
My plan is to use Ant or Antenna's preprocessor to select either the J2ME or J2SE Graphics object, with that class being the only intersection between my logic and display code. All I need is to swap a line or two of imports in a few files during my Ant/Antenna build task.
I'd like some advice on how to get this set up.
I've currently got two Eclipse projects, one J2ME and one J2SE. I have a couple ideas for how I could set up the preprocessor:
Have the J2SE code be the default, and only preprocess the J2SE code to swap in the J2SE specific imports
Use the Antenna preprocessor for both the J2ME and J2SE projects
Use Ant text substitution to make the necessary source modifications
i. looks hard to get set up right
ii. feels a bit kludgy
iii. seems least bad, because I don't see myself ever needing to use much more than a few conditional imports.
Has anyone had experience with this sort of thing? Some advice would be much appreciated.
Both app versions have different ways to startup, right? One time it's a MIDlet and the other time a Java class with a static main method. In that case I don't see the requirement to use preprocessing. Both startup implementations could access the common code base and hand over either the J2ME or J2SE "graphics" object which implements an interface known to the common code base. This way the common code base does not need to know implementation details, it just needs the interface for the representation part.
BTW .. I had a similar situation some time ago and I felt more comfortable with setting up 3 Eclipse projects, a J2ME, a J2SE and a common logic project (technically also a J2ME project). This helps to prevent class name conflicts between the J2ME-/J2SE-only parts.
Antenna should do for most cases. The advantage of using a single source for both J2SE and J2ME is that you are saved from the maintenance of source code and you also eliminate the possibility of bugs creeping in. I too had similar problems, but I had to write a custom preprocessor that suited my need. But for most purposes antenna does the job beautifully
Edited: Sample build file
<project name="SomeProject" default="buildJ2ME" basedir="..">
...
...
...
<taskdef name="jadUpdater" classname="net.jxta.j2me.tools.Jad" classpath="${lib.dir}/jxta-tools.jar"/>
<taskdef resource="proguard/ant/task.properties" classpath="${lib.dir}/proguard.jar" />
<taskdef resource="antenna.properties" classpath="${lib.dir}/antenna-bin-1.0.2.jar" />
<macrodef name="preprocess">
<attribute name="source"/>
<attribute name="dest"/>
<attribute name="symbols"/>
<sequential>
<wtkpreprocess
version="2"
srcdir="#{source}"
destdir="#{dest}"
symbols="#{symbols}"
printsymbols="true">
</wtkpreprocess>
</sequential>
</macrodef>
<target name="compile" depends="init">
<copy todir="${temp.dir}/src" >
<fileset dir="${src.dir}"/>
</copy>
<preprocess source="${temp.dir}/src" dest="${temp.dir}/preprocessed" symbols="${symbols}"/>
<javac srcdir="${temp.dir}/preprocessed"
destdir="${temp.dir}/classes"
bootclasspath="${bootclasspath}"
classpath="${lib.dir}"
debug="off"
source="1.3"
target="1.1" />
<antcall target="jarForObfuscate"/>
</target>
<target name="buildJ2ME" depends="clean">
<property name="symbols" value="J2ME1,J2ME2"/>
<antcall target="compile"/>
</target>
<target name="buildJ2SE">
<property name="symbols" value="J2SE1,J2SE2"/>
<antcall target="compile"/>
</target>
...
...
...
</project>
Hope this helps!
I've done it once with all j2me libraries replaced by my own fakes. These fakes would call all the needed j2se lib calls.
Sounds like a lot of work, but actually a lot of calls are similar, and you are probably not using everything so you only need to create a small subset of the available j2me classes
Endresult: source code which nearly doesn't need any #ifdef stuff
I'm currently working with some developers who like to set up Ant tasks that define environment specific variables rather than using properties files. It seems they prefer to do this because it's easier to type:
ant <environment task> dist
Than it is to type:
ant -propertyfile <environment property file> dist
So for example:
<project name="whatever" default="dist">
<target name="local">
<property name="webXml" value="WebContent/WEB-INF/web-local.xml"/>
</target>
<target name="remote">
<property name="webXml" value="WebContent/WEB-INF/web-remote.xml"/>
</target>
<target name="build">
<!-- build tasks here --->
</target>
<target name="dist" depends="build">
<war destfile="/dist/foo.war" webxml="${webXml}">
<!-- rest of war tasks here -->
</war>
</target>
I am finding it hard to convince them that properties files are they right way to go. I believe properties files are better because:
They provides more flexibility - if you need a new environment just add a new properties file
It's clearer what's going on - You have to know about this little "trick" to realize what they're accomplishing
Doesn't provide default values and the ability to use overrides - if they used property files they could provide defaults at the top of the project but have the ability to override them with a file
Script won't break if an environment task isn't supplied on command line
Of course all they hear is that they need to change their Ant script and have to type more on the command line.
Can you provide any additional arguments in favor of properties files over "property tasks"?
Properties tasks tightly couple the build file to environments. If your fellow developers are arguing that they "have to change their ant script" with your suggestions, why aren't they arguing about changing it every time they have to deploy to a new environment? :)
Perhaps you can convince them to allow both properties file and command-line configuration. I set up my Ant builds so that if a build.properties exists in the same directory as the build.xml, it reads it in. Otherwise it uses a set of default properties hard-coded into the build. This is very flexible.
<project name="example">
<property file="build.properties"/>
<property name="foo.property" value="foo"/>
<property name="bar.property" value="bar"/>
...
</project>
I don't provide a build.properties with the project (i.e. build.properties is not versioned in SCM). This way developers aren't forced to use the property file. I do provide a build.properties.example file that developers can reference.
Since Ant properties, once set, are immutable, the build file will use properties defined in this order:
Properties provided with -D or -propertyfile via the command line
Properties loaded from build.properties
Default properties within build.xml
Advantages of this approach:
The build file is smaller and therefore more maintainable, less bug-prone
Developers that just can't get away from setting properties at the command line can still use them.
Properties files can be used, but aren't required
The arguments you have are already pretty compelling. If those arguments haven't worked, then arguing isn't going to solve the problem. In fact, nothing is going to solve the problem. Don't assume that people are rational and will do the most practical thing. Their egos are involved.
Stop arguing. Even if you win, the resentment and irritation you create will not be worth it. Winning an argument can be worse than losing.
Make your case, then let it go. It's possible that after a while they will decide to switch to your way (because it actually is better). If that happens, they will act like it was their own idea. There will be no mention of your having proposed it.
On the other hand, they may never switch.
The only solution is to work towards a position of authority, where you can say how things are to be done.
The problem with the first solution (using ant property) is basically hardcoding.
It can be convenient when you start a project for yourself but quickly you have to remove that bad habit.
I'm using a property file close to what said robhruska except that I have committed the build.properties file directly. This way you have a default one.
In other hand, I understand I could add those default values in the build.xml. (I will probably try that in the next hours/days ;-) ).
Anyway, I really don't like the first approach and I would force those guys to follow the second one ...