On 05.05.2010 13:41, Dennis Butterstein wrote:
Hi folks,
I'd like to share my thoughts as well.
Hello,
>
> Although I'm not an official committer, but within the scope of a
> university course I'm involved in the development and am
affected, too
> I'd like to share my thoughts.
> I completely agree that IDE-specific files shouldn't be part of
any
> project's source tree, but I also don't like, if one
project's modules
> fill half of my workspace.
Same here, but I learned to accept that I might have more than one
workspace. And indeed, I do have in average three to four workspaces,
depending on the number of projects I am working on in parallel.
I think this problem can be circumnavigated as well by defining
working sets if you don't want multiple workspaces.
How .classpath/.project eclipse files at parent level is a "pain" or
"pollutant"?
I think these files won't even checkout if you just download a specific module.
You should never check out just one module. In other words, you always
need to checkout SVN trunk at the project root.
Additionally I think they won't show up in the workspace even if they
are checked out.
Yes, they will, but in your package explorer, resources with a starting
dot are not visible by default.
I think it's very convenient for new folks to have these settings.
Yes, agreed. But I am not asking for them to be removed completely.
These settings give a quick start as most of the people will start
from downloading the whole trunk (unless specified in checkout
instructions).
I can imagine how "not having" these files could be a pain for new folks.
A newbie(with Castor) will go and read the instructions for "svn co"
and after getting that code in eclipse it will be a mess for him/her
as he/she is not familiar with castor's directory structure (or at all
with open source development).
I do not see the problem here, to be honest. Right now, when you want to
dig into Castor's sources, you have to
> svn co
> cd <root dir>
> mvn clean compile
to have the various classes generated from the XML schemas before you
can run a single test case in Eclipse. In that sense, you have to run
Maven once before you can do anything meaningful with Castor within
Eclipse, anyhow.
Having said that, I cannnot see what#s so bad about asking users to execute
> mvn eclipse:eclipse
once as well.
The startup sequence (and yes, I agree that docs should be improved)
would change to ...
> mkdir <somedir>
> cd somedir
> scn co https://... .
> mvn clean compile
> mvn eclipse:eclipse
Then, start Eclipse, create a new workspace optionally, and import
existing projects into your workspace, set <root dir> as source .. et
voila, Castor completely imported into your workspace.
That's one more step (tiny), and does not remove any inconvenience.
As I'm new to castor I completely agree. Without having .classpath&
.project files it would have been harder
to set up a castor workspace. It was not even obvious to me how to do it
now. I've never used maven before so for me setting up my workspace was done
by having checked out svn trunk.
As I have already said, we ar enot removing this convenient feature. We
just would like to have those files generated.
How about if everybody tried this once, and then provide feedback. Just
delete .classpath, .project and .settings directory before you rnu the
Maven commands.
I think I'm not the only one facing this problems, as I've not found a
description about setting up the complete workspace yet. So by deleting
.classpath and .project files I think the hurdle to take before being able
to contribute to castor will get harder. So some attracted people willing to
look at castors' source possibly will be discouraged and in my opinion
that's a bad precondition for opensource projects living on people's
voluntary work.
For developers that have been contributing for a while to castor and which
are using a one project set up, removing the files would result in
superfluous work like having to adapt the files everytime changes to the
build path or similar are done. So every single one of them would have to
adapt the files. So personally I think the time consumed by adapting
.classpath& .project files can be used in a more sensible way.
Gosh, Andras and I spent - each - quote some time to sort this out
manually. And we need to do this every time we upgrade a dependency,
e.g.. move from JUnit 4.4 to 4.8.1 or something similar. Every time we
do this, we risk that soe transitive dependencies change. Why should
anybody have to manually do what Maven gives to you for free ?
I mean, when you want to upgrade a dependency (e.g. increase Spring from
3.0.1 to 3.0.2), simply change the dependency in the POM(s), run
> mvn eclipse:eclipse
agina, and in an open Eclipse, refresh all the projects. Done. All the
'Referenced JARs' in the Castor modules will be changed within a few
seconds, a workspace build started ... et voila.
I agree that these files should not be part of the source tree, but as long
as removing them does more harm than good (correct me if I'm wrong), keeping
the files is a low price to pay I think.
I do not think the price is low to pay. It is the same (heavy) price we
used to pay before we removed any generated classes from the SVN repo.
Before, we had to manually copy genrated files into the SVN repo after
making changes to one of the source XML schemas (e.g. mapping.xsd).
Nowadays it's simply change the XML schema, run
> mvn clean compile
and refresh your workspace. I am sure you and everybody else enjoyed the
simplicity of this. I would just like to have the same convenience for
Castor when I work on it.
As a conclusion in my opinion the files should be kept to make it easy for
interested developers to get involved as well as enable everybody to work as
he is used to without imposing superfluous work on anybody.
Can I kindly ask you to have a look into my above recipe, and provide me
with fedback ?
Werner
Regards,
Dennis
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
