Re: [castor-dev] Mvn build and Eclipse
Dennis Butterstein <[email protected]> Wed, 5 May 2010 13:41:24 +0200
| Newsgroups | gmane.comp.java.castor.devel |
|---|---|
| Message-ID | <[email protected]> |
--0016364991a34727110485d74e3c
Content-Type: text/plain; charset=ISO-8859-1
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.
Additionally I think they won't show up in the workspace even if they
are checked out.
> I think it's very convenient for new folks to have these settings.
> 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).
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.
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.
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.
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.
Regards,
Dennis
--0016364991a34727110485d74e3c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<pre class=3D"message">Hi folks,<br><br>I'd like to share my thoughts a=
s well.<br><br>> Hello,<br> ><br> > Although I&#=
39;m not an official committer, but within the scope of a<br> >=
university course I'm involved in the development and am affected, too=
<br>
> I'd like to share my thoughts.<br> > I compl=
etely agree that IDE-specific files shouldn't be part of any<br> =
> project's source tree, but I also don't like, if one projec=
t's modules<br>
> fill half of my workspace.<br> Same here, but I lea=
rned to accept that I might have more than one <br> workspace. And=
indeed, I do have in average three to four workspaces, <br> depen=
ding on the number of projects I am working on in parallel.<br>
<br>I think this problem can be circumnavigated as well by defining working=
sets if you don't want multiple workspaces.<br><br><br>> How .class=
path/.project eclipse files at parent level is a "pain" or<br>
> "pollutant"?<br>> I think these files won't even chec=
kout if you just download a specific module.<br><br>Additionally I think th=
ey won't show up in the workspace even if they are checked out.<br>
<br>> I think it's very convenient for new folks to have these setti=
ngs.<br>> These settings give a quick start as most of the people will s=
tart<br>> from downloading the whole trunk (unless specified in checkout=
<br>
> instructions).<br>> I can imagine how "not having" these =
files could be a pain for new folks.<br>> A newbie(with Castor) will go =
and read the instructions for "svn co"<br>> and after getting =
that code in eclipse it will be a mess for him/her<br>
> as he/she is not familiar with castor's directory structure (or at=
all<br>> with open source development).<br></pre>As I'm new to cast=
or I completely agree. Without having .classpath & .project files it wo=
uld have been harder<br>
to set up a castor workspace. It was not even obvious to me how to do it no=
w. I've never used maven before so for me setting up my workspace was d=
one by having checked out svn trunk. <br><br>I think I'm not the only o=
ne 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 preconditi=
on for opensource projects living on people's voluntary work.<br>
<br>For developers that have been contributing for a while to castor and wh=
ich are using a one project set up, removing the files would result in supe=
rfluous 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 t=
he files. So personally I think the time consumed by adapting .classpath &a=
mp; .project files can be used in a more sensible way.<br>
<br>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.<br><br>As a conclusion in my opinion the files sh=
ould be kept to make it easy for interested developers to get involved as w=
ell as enable everybody to work as he is used to without imposing superfluo=
us work on anybody. <br>
<br>Regards,<br><br>Dennis<br>
--0016364991a34727110485d74e3c--