Thanks for the info - looking forward to updated plugin ;)
Did an experiment in eclipse: created a project with 2 src folders
containing com.acme.Foo and com.acme.Bar respectively. Then switched
to the Java Browser perspective and clicked on MyApp and sure enough
I saw the package hierarchy, ie com.acme and then both Foo and Bar
classes directly under it. BUT when you click from Foo to Bar the
highlight moves to the corresponding src folder thus enabling you to
identify the 'parent artifact'. Hope that makes sense...
I would definitely miss this. That said, if everyone is working to
the same standard, the pros perhaps outweigh the cons. It could
actually be seen as a shortcoming of the IDE that you lose this ability.
On 15 Sep 2005, at 09:27, Kenney Westerhof wrote:
On Wed, 14 Sep 2005, Ashley Williams wrote:
Hi,
Just been playing around with eclipse projects. I see that
eclipse:eclipse makes a separate project for each pom, whilst
retaining the option to add project references if you want to.
Wouldn't it make more sense though, for eclipse:eclipse to add a new
source folder under an existing eclipse project? As a graphical
illustration:
Currently it will retain the project structure for eclipse that has
been
established for m2. Since there probably was a good reason to split up
the project sources into multiple maven projects, why shouldn't the
same
go for eclipse?
Current eclipse:eclipse result:
MyUtilProj [classpath REPO/junit]
MyModelProj [ref MyUtilProj] [classpath: REPO/jaxen, REPO/junit,
REPO/myutil.jar]
MyGUIProj [ref MyModelProj] [classpath: REPO/servlets, REPO/
httpunit, REPO/mymodel.jar]
Suggestion:
MyKillerApp [classpath: REPO/jaxen, REPO/servlets, REPO/junit etc,
REPO/httpunit]
- utilsrc
- modelsrc
- guisrc
We've had this request before. It's possible, but it would
complicate the
plugin a lot - we need to merge the dependencies, for instance.
which would seem more in keeping with how you would manage a project
before you had heard of Maven (maybe not in the experience of
others).
The risk of doing this is that when you manage your eclipse
project, it's
easy to use the wrong classes. For instance, when you have an api
project
and an impl project (SPI framework), it's tempting to use the
implementation directly, or to use other classes that you're not
supposed
to touch. Keeping the projects separate, with either jars on the
classpath
or references to other projects, will enforce the dependency rules
specified in the pom for that project.
Also there is a practical advantage that when you press F3
to navigate to a type, you go straight to the source file. With the
current arrangement (maybe its my ide settings, but I don't think so)
you get the unwanted choice of going the the class in the jar file
artifact (and "would you like to attach source" etc).
That's been solved a while back: you need to run m2 eclipse:eclipse
in the root of the project hierarchy (optionally using -r if not all
projects are referenced from the modules section).
It will:
o use available reactor projects to make project references instead of
classpath entries to the jars in the local repository.
and if you specify -Declipse.workspace=/path/to/workspace:
o generate a subdirectory there for each project encountered in the
reactor;
o create eclipse folder links to the (generated) source/resource
directories;
o create a file link to the pom;
This will help in creating a flattened project tree (a list,
actually),
to circumvent eclipse's limitation of nesting projects. It will
also add
pom projects (or will, when I commit :)).
Additionally, my personal favourite, is that when you go to the Java
Browsing perspective, you can see all the code under one package
source tree - just make sure MyKillerApp is highlighted on the left!
Yup, that's an advantage. It's also a disadvantage because you
can't see
which package belongs to which project. But class hierarchies etc.
will
work as expected.
I believe to get this to work, you would need to configure the
eclipse plugin with the location of an existing eclipse project for
it to append a source folder to (it would create the project if it
doesn't exist). Although this is extra info to tell the plugin you
would get to remove the info about project dependency.
In fact because all the artifact poms have a parent pom in common,
you wouldn't even have to specify an eclipse project, it would create
one based on the name of the parent.
Not necessarily true - they don't have to share a parent pom to have
dependencies on each other. But generally it's true.
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
