The .classpath files are not included as part of the binary, :). The
consistency I'm referring to and concerned about is with the Eclipse
development model, and that we're refraining too far from it. From an
eclipse developers standpoint, I think Eclipse itself will still be the
primary build tool, not Maven. By Mavenizing the eclipse plugins, we're
provding the build infrastructure to provide binary distributions, just
like if we had chosen the Ant based PDE builder. Neither of these are
meant to use for day to day development. (speaking only from a eclipse
standpoint). I think its very important that we provide developers the
recommended path that is known to them, and that is to be able to (1)
checkout the plugins from the repo, and (2) import those plugins into
directly Eclipse without any external tools.
If this was a regular java project or another component within Gerino,
I'm in 100% total agreement here with you. However its not, we're more
specific here. Rather then adapting a java project for use in a
particular IDE. We already know the project itself is an Eclipse
project, and so we're saying lets be kind :) and help out here and go
ahead and include the eclipse specific resources, rather then take them
away.
I'm not sure if I'm getting any closer to convincing you, but I'm gonna
keep trying :).
If any of the Mavenide folks are reading this thread, could you provide
your reasoning for including the .classpath? Was your concern the same
as mine?
Sachin.
Jeff Genender wrote:
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
