Re: [castor-dev] Mvn build and Eclipse

Werner Guttmann <[email protected]> Wed, 05 May 2010 17:44:16 +0200
Newsgroups gmane.comp.java.castor.devel
Message-ID <[email protected]>

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