It's possible to create automatic an ANT build file to compile, create EAR, WAR, JAR and deploy our project ?
Example:
MyEclipse could easily deploy our project, I think that would be too dificult to generate a ant build file to do the same and with a compile, create jar, ear, war tasks...

If you are asking about MyEclipse generating a build file for you to do these things, this has been discussed in previous threads. We originally looked at making ALL project functionalities based on Ant so it would be very cross-IDE compatible, but quickly as we started down this path we realized how limiting Ant is. Ant wouldn't allow us to do the hot deploys, or the deployment of linked resources, or depedant projects, etc... so we have settled on proprietary project management solutions.

Subsequently, there is no way to automatically generate a build script from MyEclipse to mirror its functionality. HOWEVER, you can certainly write your own Ant script to do these things, as many people like to have both.

We realize that Ant is a huge part of many people's development and will not rule out supporting it. After the 2.8 release we may get some extra cycles and come back and revisit the Ant-project-management issue and see what we can pull off.

I believe the underlying issue here is about having command line tools for building projects that developers use IDE's to write.

Using MyEclipse during development is fine. However whensystem builds or overnight builds or the like are wanted than a interactive GUI tool is no longer an appropriate tool to build with. A well run project should have some automated build process that runs on a nightly basis (or more frequently). Look at Maven or CruiseControl for the kinds of things that people want to do.

So a command line tool that can build an eclipse project from scratch, run the unit tests and package the result is want is needed. It's just generally that most people use ANT for this task.

Personally I don't have a problem maintaining seperate ANT scripts, however what I do want to be able to easily extract things like jar dependancies and the like. So if a developer plays with configuration necessary to do a build in eclipse then the results are easily accessible to my ant scripts. This is so my build team don't to maintain a seperate configuration which gets out of date in comparision to how developers are configuring Eclipse.

Perhaps an ant extension to access Eclipse configuration information would be enough.

FoxyCoder wrote:

Perhaps an ant extension to access Eclipse configuration information would be enough.

Probably not. Actually there must not be any info that would influence the build that is obtainable only from Eclipse, since building the full application should not depend on Eclipse being installed.

If there are, they must be reproduced for ant as files, otherwise the build process itself would depend on Eclipse, which is clearly not allowable, since maintaining information stored in Eclipse needs frequently opening Eclipse to refresh its changes. On a separate (possibly unmanned) build machine this is not usually acceptable.


There are a couple of problems to this actually:

- the location of other referenced projects are resolved by Eclipse. An other way of supplying information about the location of a specific Eclipse project must be introduced to make it possible to do many-Eclipse-project application builds (some standardized way of mapping Eclipse projects to paths in property files, which also has to be maintained by MyEclipse on an Eclipse machine and the build manager on a non-Eclipse machine).

- the information about application servers are definitely stored by Eclipse. This definitely should be acquirable from property files by the build process, and should be maintained the same way as it is described in the previous section

- I am not sure, where the deployment information of a project is stored, but the obvious place would be in metadata files in the project directory

All other necessary information is actually stored in MyEclipse-specific metadata files, like .myeclipse, and such.

An other solution may be that, implemented by Weblogic Workshop as well, that it generates Ant build.xml files for the actual state of a project and an application, which use custom tasks that read the Workshop specific metadata info. (Actually Workshop itself uses ant to build, so it may not be the best example after all.).

In the MyEclipse case, it can extend this with also writing out all the necessary information that was stored in Eclipse configuration store into property files for the tasks to be able to read it without accessing Eclipse at all, thereby making the ant tasks become independent from Eclipse.

For example, if an application project is selected, for generating ant-stuff from, then:

1. one or more property files should be generated containing
- all data about the application servers used by the application,
- all data about the deployment of the application and its module projects,
- all data about the root directory of the module projects should be stored.

2. a build.xml should be generated with the appropriate targets which is capable of carrying out application-level operations (clean, build, deploy, undeploy, ear an entire application, etc)

3. one or more property files for each module project should be generated containing
- all project-specific data which is not stored in MyEclipse-specific metadata files in the project

4. a build.xml should be generated with the appropriate targets for carrying out module-level operations (rebuild, clean, build, jar, war, optionally redeploy the module individually, if possible, etc.)

When the projects are copied to an other machine, the property files are the only things needed to be adjusted, to ensure the full operation capabilities of the build.xml files.



There may be additional problems, as Riyad outlined it, because of the version of ant they looked at lacked the control-flow capabilities or lacked some tasks or lacked the means of passing necessary information back to Eclipse they would require to be able to make all their operations ant-based.

The first two may be coded around by writing additional tasks. The third ones probably cannot without making changes to ant itself. However there may not be problems of this third type.

Just my 2 cents,

Regards,

Robert