SVN organization

[Suresh Marru <sm...@apache.org>]

The current svn structure was mainly a place holder for code imports. But since we are seeing some development activity, I am organizing svn hoping to get a lazy consensus. If you see any concerns please discuss on this thread or re-organize. If you re-organize please make sure you do so preserving commit history. 

donations/ - read-only place for all accepted donations.
etc/ - place for all eclipse, idea and any configurations
site/ - website content 
branches/ - as the name says
tags - as the name says
trunk/  - all modules directly checked into this parent  - (as we do the first release we can rethink)
trunk/schemas - all schema documents and generated beans

Cheers,
Suresh

Re: SVN organization

[Thilina Gunarathne <cs...@gmail.com>]

>I was debating on this. RIght now I put all them in a flat level, do you
suggest moving them into modules so we can >have proper maven profiles? -
https://svn.apache.org/repos/asf/incubator/airavata/trunk/
Actually what I meant is what you have done, moving them from
airavata-services to airavata/trunk.. I don't have much preference regarding
modules/ or flat list. Does maven still enforce it? In fact, I have been
lucky enough to not tinker maven scripts for some time :)..

thanks,
Thilina

> donations/ - read-only place for all accepted donations.
> >> etc/ - place for all eclipse, idea and any configurations
> >> site/ - website content
> >> branches/ - as the name says
> >> tags - as the name says
> >> trunk/  - all modules directly checked into this parent  - (as we do the
> >> first release we can rethink)
> >> trunk/schemas - all schema documents and generated beans
> >>
> > Do we really need to commit the generated beans? I personally think it's
> > much cleaner to generate them at the build time. That will ensure they'll
> > get upgraded with the new releases of the respective code-generators and
> > they won't be broken over time..
> + 1 good idea. I will only keep the schemas then, we can add xmlbeans maven
> tasks to generate the beans.
>
> Thanks,
> Suresh




-- 
https://www.cs.indiana.edu/~tgunarat/
http://www.linkedin.com/in/thilina
http://thilina.gunarathne.org

Re: SVN organization

[Suresh Marru <sm...@cs.indiana.edu>]

On Jul 9, 2011, at 3:29 PM, Thilina Gunarathne wrote:

> Hi Suresh,
> +1 for re-organizing the SVN. IMHO it'll be much easier to get it done now,
> before many people start jumping to the development.  Hope you are also
> getting rid of the airavata-services and making them modules inside the
> trunk..
I was debating on this. RIght now I put all them in a flat level, do you suggest moving them into modules so we can have proper maven profiles? - https://svn.apache.org/repos/asf/incubator/airavata/trunk/
> donations/ - read-only place for all accepted donations.
>> etc/ - place for all eclipse, idea and any configurations
>> site/ - website content
>> branches/ - as the name says
>> tags - as the name says
>> trunk/  - all modules directly checked into this parent  - (as we do the
>> first release we can rethink)
>> trunk/schemas - all schema documents and generated beans
>> 
> Do we really need to commit the generated beans? I personally think it's
> much cleaner to generate them at the build time. That will ensure they'll
> get upgraded with the new releases of the respective code-generators and
> they won't be broken over time..
+ 1 good idea. I will only keep the schemas then, we can add xmlbeans maven tasks to generate the beans. 

Thanks,
Suresh

Re: SVN organization

[Thilina Gunarathne <cs...@gmail.com>]

Hi Suresh,
+1 for re-organizing the SVN. IMHO it'll be much easier to get it done now,
before many people start jumping to the development.  Hope you are also
getting rid of the airavata-services and making them modules inside the
trunk..

donations/ - read-only place for all accepted donations.
> etc/ - place for all eclipse, idea and any configurations
> site/ - website content
> branches/ - as the name says
> tags - as the name says
> trunk/  - all modules directly checked into this parent  - (as we do the
> first release we can rethink)
> trunk/schemas - all schema documents and generated beans
>
Do we really need to commit the generated beans? I personally think it's
much cleaner to generate them at the build time. That will ensure they'll
get upgraded with the new releases of the respective code-generators and
they won't be broken over time..

thanks,
Thilina



>
> Cheers,
> Suresh




-- 
https://www.cs.indiana.edu/~tgunarat/
http://www.linkedin.com/in/thilina
http://thilina.gunarathne.org