0

So let me describe the situation. I have a very big project. Now it is managed by ant. Now i'm working on making this project work with ivy and eclipse and i'm at a loss with a lot of questions.

Firstly, i haven't worked in eclipse and this "flat" workspace conception is rather weird for me. Project has a tree structure and in the root there are a lot of config files - like libraries.properties (just for describing library versions), ivysettings.xml and template build files for imports. And then there a lot of projects nested within the root directory.

For Eclipse i'm now using ivyDE.

First Question - How to create a tree structure in Eclipse with its flat stuff?? What i want is to make that subprojects can take files from the root. what is the right and standart way to do it??

Second - If subproject has its own library version for smth, then it has libraby.properties file within its directory. And this file is grabbed first, so the global root library. properties can't override specific for this subproject versions of libs. This works goodbecause it is in ant where i can load specific properties file before global. But IvyDE - i found only one point where i can specify properties file for it (may be i missed smthg). So how can i manage this??

Third - question specific to ivy. How can i publish only docs or only sources?? I think it's a concern of configurations. But i would be really gratefull - if u can give me an example of this - what is in ivy file and what should be in ant file?? Thanks in advance. )

borzoni
  • 82
  • 1
  • 6
  • I can't believe that no one has worked with eclipse and ivy. Does someone appear to know at least what is the best way to layout the project structure for ivy/ant usage in eclipse?? – borzoni Dec 06 '11 at 03:32

3 Answers3

1

Have you read the ivy tutorial on multi-module builds?

The following answer also gives some pointers.

Community
  • 1
  • 1
Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
0

About the First: You do not need to use a flat structure. A project path can changed at creation time. Or you can move it around the filesystem and reimport it. And with Working Sets you can group your projects for a nicer structured view.

Daniel Sperry
  • 4,381
  • 4
  • 31
  • 41
0

For the second question, I'd simply indicate that Mark O'Connor has my vote.

For the first question, yes there are ways to use a tree structure of projects in Eclipse, but you're working against the system here and will suffer penalties in the long run.

We have successfully used the following strategy: assuming your project is in SVN, you can leverage svn:externals to create an equivalent flat structure that works for Eclipse.

The idea is to define a root SVN folder (probably outside of your existing structure, such as a sibling folder). Then create the flat structure of eclipse project folders inside it, including the eclipse .project, .classpath and other .settings/.externalBuilders configuration files. Next, using svn:externals, bring in the source and configuration files from your original SVN location to compose the proper project folder structure. You should be done.

Interesting benefit: you can keep both structures as long as you want. You can have some early adopters working on the Eclipse structure, while the rest of the team work on the legacy Ant checkout. Both groups checkout and commit the same files. You can switch everyone over whenever you feel the Eclipse structure is stable, or scratch it if you run into too many problem. the legacy structure was there for you the whole time, you don't have a transition period where your ability to make a clean build is in jeopardy.

Patrice M.
  • 4,209
  • 2
  • 27
  • 36