Re: [smila-dev] improved svn project structure

[<daniel.stucky@xxxxxxxxxxxxx>]

Hi Tom,

personally I don't see any major improvements using a different project structure but lots of work for you to change all of this and also additional work for users that already use SMILA in their own projects and have to adapt their build process.
I like the flat structure as I can "see" everything that's there and I can still exclude projects for example by using working sets in eclipse IDE. For fresh starters another structure may be helpful, though.

As I'm pretty dispassionate on this issue my vote is 0.

Bye,
Daniel

-----Ursprüngliche Nachricht-----
Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel
Gesendet: Mittwoch, 9. Februar 2011 16:53
An: Smila project developer mailing list
Betreff: [smila-dev] improved svn project structure

hi folks,

I want to make the following improvements to the SVN structure, which I had long in mind and which are also partially inspired from what I have seen in other projects.

I post them so I can get a +1, 0, or -1 from those involved along with some feedback and suggestions.

the changes will come over time as my time permits and not in one go.

top 1 releng project and folder
--------------------------------
this is not an PDE/Java Project but a simple one to have the files accessible in the IDE.

in there I would place:
-  .psf file
- .target files 

for easier devenv setup.

the .target should reference new dependencies via p2repos. for now, since we have the bundles already in the SVN anyhow, I would do just do project relative path locations.

I'm not sure yet if I just merge the SMILA.extensions, .Launch and .Builder projects here as well but have subfolders in the releng project for each; I think this would makes sense.


top 2 pull out 3rd party bundles from workspace
-----------------------------------------------
I mean bundles like com.novel.ldap
 
they really should be put into orbit. until then I would move them into their own folder called 3rdParty.

In that context I would adapt the build to be a 2-step process, namely one to build these 3rd party bundles and the 2nd to build the main smila bundles.
Ideally we would publish these bundles separately in a p2repo and then ref' them thru the .target as well, so we don't have to pre build them when we setup the workspace; I see this as a 2nd step.

top 3 put features and product bundles/project
-----------------------------------------------

I have seen in the gyrex tech project that they have their feature and product bundles also under /releng. I'm not quite sure how well that works, so I put it up for discussion.
I certainly feel though that we could have less bundles in the workspace and the features are only relevant in the context of the build.
having said this an alterntive where to separate the bundles into bundles (plugins) and feature folders, just like in the installation.

top 4 move the BPEL designer bundles to a /tooling folder
---------------------------------------------------------
these bundles have nothing todo with smila itself but are for extending the eclipse IDE to be able to edit BPEL files. hence they should not be located alongside the core bundles.

this suggestion is minimalistic. if one would want to do this really proper then this would need to become an own subproject of smila having its own trunk with its own releng, build, .psf and .target. but this is overkill ATM - at least I feel so now.


top 5 proposed new top level structure
--------------------------------------
/trunk/
	3rdParty 	# see top 2
	core		# here go all the core bundles
	releng	# see top 1, 3
	tooling	# see top 4


feedback is welcome.

so long,

Thomas Menzel @ brox IT-Solutions GmbH


http://www.Taglocity.com Tags: smila, devenv
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev