Sachin Patel wrote:
One last statement before everyone else throws there two cents in :)...
I strongly believe that including this is a necessity. Unlike geronimo,
these aren't regular java projects that can be adapted to invoke within
a users context and IDE choice and that can be launched different ways.
These projects contain eclipse specific content and can only be launched
within an eclipse environment and thus the files are critical to the
projects configuration. By not including these files we put a
requirement on Eclipse users to have Maven and this breaks the
consistency.
I probably need to be educated here. Are you saying the eclipse
.classpath files are included as part of the binary, or required for the
build? If its required for the binary, then I understand the need for
inclusion. If its for the build, then I disagree with you. You need a
build tool, yes? You choose either ant or maven. This is no different
than any other project. What is the consistency you are referring to?
Without the files, you essentially are making the
statement saying that these projects are eclipse plugins, that will only
run on top of eclipse, but FIRST you need to launch maven for Eclipse to
be able to consume them. I don't think that is reasonable. Eclipse
plugin projects extracted out of the repo AS IS should be ready to be
consumed by Eclipse without the requirement for Maven.
Ok...so then you are talking about the .classpath included as part of
the binary?
Your clarification here will help me immensely ;-)
Jeff
Sachin.
Jeff Genender wrote:
Sachin Patel wrote:
Could we just prevent that by overriding the maven:eclipse goal in
the projects' maven.xml and echo out a message stating a message that
no .classpath generation is necessary since these are already eclipse
projects?
Lets get others' input on this. If the .classpath inclusion is just
for convenience, then I am against this since, again, we are
detracting from the way geronimo does things. Throughout geronimo, we
let maven build the project ide files. It makes sense due to the many
ways these files can get changed due to people's preferences. I
really want to have consistency in all of our projects, unless its
absolutely necessary. Once we break consistency, we are headed down a
slippery slope.
FYI. The mevenide plugin is also including the .classpath in their repo.
They also use cvs, so then should we drop svn and use cvs too? IMHO,
this is comparing apples to oranges. Mevenide is not part of a very
large application server and is not affected by a much bigger overall
build. Also, just because another project does it, does not mean its
the best way for this project. Thats a facet of all of open
source...each project has their own way of doing things.
Sachin.
Jeff Genender wrote:
Hmmm now that I think about this...
Sachin, these files will likely get overwritten when someone does a
"maven eclipse". Be prepared for these to get overwritten fairly
often, and will likely get rechecked in.
Jeff
Jeff Genender wrote:
Sachin Patel wrote:
Yes, I think this is needed. Since these are eclipse plugins to
begin with I consider these to be part of the project
configuration. Eclipse users should be able to directly import
these projects into Eclipse without having to generate the
.classpath.
As long as these have no machine specific info in it then it may be
ok. ..ie same configuration that will work on Windows, Linux, and
Mac. But normally, I am against this. We usually use maven to
generate these files for us.
Jeff
Jeff Genender wrote:
I noticed these files going into the eclipse plugin:
UU sandbox/eclipse-plugin/org.apache.geronimo.ui/.classpath
UU
sandbox/eclipse-plugin/org.apache.geronimo.deployment.model/.classpath
UU sandbox/eclipse-plugin/org.apache.geronimo.core/.classpath
Are these ok? IIRC, these are user/computer specific to the
user's setup. Are these supposed to be checked in (.classpath)??
Jeff
