Ant-contrib usage in ivy-beans

[Laurent Forêt]

Hello , the list

In the ivy extension of the ant build script, I have to modify the javac.classpath. To achieve this I have two possibilities, and I would like to know your opinion.
This is the two :
The first (It is that I have already done in the trunk), change dynamically the build.properties file before the compilation task.
The second is to use the variable ant-contrib task [1] in order to reassign dynamically the javac.classpath with appending the computed ivy classpath to the JSEProject classpath.

The first is simple, but can let unwanted information in the build.properties file. Then this file has to be cleaned up at the end of the build script. Otherwise, we have an horrible behaviour :

Then, if we have to write a variable in a file, use it, and remove it. What the file is good for. This is the second solution, but to do this I should use the ant contrib.
But it looks like "écraser la mouche avec un marteau" (to crush the fly with a hammer;), that means not very appropriate) .

What do you think ?


Laurent.

[1]http://ant-contrib.sourceforge.net/tasks/tasks/variable_task.html :

    <property name="x" value="6"/>
    <echo>${x}</echo>   <!-- will print 6 -->
    <var name="x" unset="true"/>
    <property name="x" value="12"/>

    <echo>${x}</echo> 

[Laurent Forêt]

In attachment the not pretty behaviour

[Xavier Hanin]

I don't know netbeans generated builds very well yet, but maybe you can enlight me: is javac.classpath a property or a path? I ask because there's an interesting (but undocumented) ant task provided by Ivy which let you append or prepend path to an existing path. So it may a good solution if javac.classpath is a path.

Xavier

On Sun, Jun 22, 2008 at 9:30 AM, Laurent Forêt <lauren...@gmail.com> wrote:

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Milos Kleint]

can't you modify the property in the nbproject/project.properties file?

eg.
javac.test.classpath=\
${javac.classpath}:\
${ivy.test.classpath}:\
${build.classes.dir}:\
${libs.junit.classpath}:\
${libs.junit_4.classpath}

where ivy.test.classpath property would be resolved by your ivy task
before the compilation?

I'm not sure how that would influence the IDE's classpath resolution
(but I think it ignores unresolved items, and you add the ivy
classpath yourself)

the ant contrib stuff could be a bit tricky in the sense that the ant
tasks have to be found by the ant building process.

Milos

[Laurent Forêt]

Unfortunately it is a property otherwise it would be very interested :(.

I do not think that build tasks are working so well. Indeed, I still have not found a good target to depend with for -ivy-retrieve and -ivy-clean:.

the -do-init is to early : the "clean and build" try to resolve twice ivy libs and crash
the -pre-pre-compile is too late : I have to the build action twice to resolve and compile correctly.

Laurent.

[Laurent Forêt]

It is that I do (in the trunk) for the javac.classpath :

...
        <propertyfile file="nbproject/project.properties">
            <entry key="javac.classpath" operation="+" value="$${ivy.classpath}"/>
        </propertyfile>   
...
        <propertyfile file="nbproject/project.properties">
            <entry operation="=" key="ivy.classpath" value="${ivy.classpath.computed}"/>
        </propertyfile>

What is the difference with javac.test.classpath ? Further more it should not work, classpath for compile sources is resolved in "-init-macrodef-javac".

It is not the same problem but I have a close question. Do you know why -init-macrodef-javac is called so early ?  It is a dependency of the "init" target. I would rather the "compile" one.

Nevertheless, the ant contrib variable answer the question very well. I do not care that the javac.classpath property is already set, Ican change it at the best moment.

[Laurent Forêt]

I still thinking about this issue, and I do not see a better solution than the ant contrib variable.

I have posted a question and a will in the openide dev mailing list. According to  answers I will implement this solution or not.

regards,
Laurent

[Milos Kleint]

On 6/23/08, Laurent Forêt <lauren...@gmail.com> wrote:
> It is that I do (in the trunk) for the javac.classpath :
>
> ...
> <propertyfile file="nbproject/project.properties">
> <entry key="javac.classpath" operation="+"
> value="$${ivy.classpath}"/>
> </propertyfile>
> ...
> <propertyfile file="nbproject/project.properties">
> <entry operation="=" key="ivy.classpath"
> value="${ivy.classpath.computed}"/>
> </propertyfile>

I see. I've been after a simpler (maybe too simple) solution of
writing the ivy.classpath property into the
nbproject/project.properties file.

>
> What is the difference with javac.test.classpath ? Further more it should
> not work, classpath for compile sources is resolved in
> "-init-macrodef-javac".

AFAIK there's 4 different properties like this one for sources
compilation, one for sources runtime, one for test compilation and for
test runtime.

>
> It is not the same problem but I have a close question. Do you know why
> -init-macrodef-javac is called so early ? It is a dependency of the "init"
> target. I would rather the "compile" one.

No idea. I suppose some 3rd party plugin might need it before the
compile target. But not really sure. The netbeans generated scripts
are a mystery to me mostly.

>
> Nevertheless, the ant contrib variable answer the question very well. I do
> not care that the javac.classpath property is already set, Ican change it at
> the best moment.

Ok. if it works, then fine. I'm a bit worried of the project setup and
headless builds. does thecontrib jar need to be placed on ant
classpath somehow? how will it work with sharable projects?

Milos

[Laurent Forêt]

On Thu, Jun 26, 2008 at 9:46 AM, Milos Kleint <mkl...@gmail.com> wrote:

On 6/23/08, Laurent Forêt <lauren...@gmail.com> wrote:
> It is that I do (in the trunk) for the javac.classpath :
>
> ...
>         <propertyfile file="nbproject/project.properties">
>             <entry key="javac.classpath" operation="+"
> value="$${ivy.classpath}"/>
>          </propertyfile>
> ...
>         <propertyfile file="nbproject/project.properties">
>             <entry operation="=" key="ivy.classpath"
> value="${ivy.classpath.computed}"/>
>          </propertyfile>

I see. I've been after a simpler (maybe too simple) solution of
writing the ivy.classpath property into the
nbproject/project.properties file.

 

this solution work but ...

 

>
> What is the difference with javac.test.classpath ? Further more it should
> not work, classpath for compile sources is resolved in
> "-init-macrodef-javac".

AFAIK there's 4 different properties like this one for sources
compilation, one for sources runtime, one for test compilation and for
test runtime.

It is linked with the issue of mapping ivy configuration with Netbeans Scope.

>
> It is not the same problem but I have a close question. Do you know why
> -init-macrodef-javac is called so early ?  It is a dependency of the "init"
> target. I would rather the "compile" one.

No idea. I suppose some 3rd party plugin might need it before the
compile target. But not really sure. The netbeans generated scripts
are a mystery to me mostly.

I had an answer from Jesse Glick, I have to submit a patch.
 

>
> Nevertheless, the ant contrib variable answer the question very well. I do
> not care that the javac.classpath property is already set, Ican change it at
> the best moment.

Ok. if it works, then fine. I'm a bit worried of the project setup and
headless builds. does thecontrib jar need to be placed on ant
classpath somehow?

It is quite similar to ivy tasks I have to define a task :

<taskdef resource="net/sf/antcontrib/antcontrib.properties">
  <classpath>
    <pathelement location="/usr/share/java/lib/ant-contrib-0.3.jar"/>

  </classpath>
</taskdef>

in ivybeans i deal with a system property  

In ivybeans I deal with a system property "ivy.home" :
        File file = InstalledFileLocator.getDefault().locate("modules/ext/ivy-2.0.0-beta2.jar", "fr.jayasoft.ivy.ant", false);
        ivyHome = file.getParentFile();
        System.setProperty("ivy.home", ivyHome.getAbsolutePath());

 I can easily add the antcontrib lib in he same manner.
 

how will it work with sharable projects?

That is a big question !  I will test it and see how it works.

However, I am going to create an issue and try to provide a patch that can delay the classpath resolutions in the ant build system of jseproject .

Laurent.

[Laurent Forêt]

Hi , I have just commited a solution based on the ant-contrib usage solution. I also assumed that the posted issue 138661 (http://www.netbeans.org/issues/show_bug.cgi?id=138661)  will be solved.

I find it simple, elegant and quite similar as what has been done in the ClasspathProviderImpl.
The key point is in this ant code called before the compilation macro :

        <property name="old.javac.classpath" value="${javac.classpath}"/>
        <var name="javac.classpath" unset="true"/>
        <if>
            <equals arg1="${old.javac.classpath}" arg2=""/>
            <then>
                <property name="javac.classpath" value="${ivy.classpath.computed}"/>
            </then>
            <else>
                <property name="javac.classpath" value="${old.javac.classpath}${path.separator}${ivy.classpath.computed}"/>
            </else>
        </if>
       
It is not intrusive and makes all the other resolution mecanisms work as before.  I just append to the end the ivy resolved classpath. We could exactly the same thing for all other classpaths, when we will introduce configuration.

Laurent.