Community
Participate
Working Groups
There are currently certain files which are not part of any eclipse project (i.e. there is no .project file for them). - all files located in the root folder - /features/pom.xml - /plugins/pom.xml These are all files related to the build. This setup has the negative side, that such files cannot be manipulated/submitted in the IDE (well, at lease not easily). They are also not included in the team project set, which makes it more difficult for people to get started. And may be the most crucial problem - if you directly import the projects from SVN, then the structure is lost - the features and plugins folders do not exist, but all projects get synched in the workspace. Then it is not possible to run the Tycho build locally. Therefore I would like to restructure the file layout, so that: - there are no files in the root - every file is in a project, so that it can be immediately imported in the IDE after maintaining the SVN connection data - change the team project set file (linked from the wiki) to contain all projects - there is no unused content. I think currently there are some files which aren't used at all - remove the nesting - move the features and plugins on the top level Such changes will have influence on the build and hudson job configuration. They will also affect any in-house builds. Let's track the necessary changes here. My first proposal is the following: - move all files from the root to /parent - these are the parent pom.xml and some build scripts - move all plugins from /plugins to / - move all features from /features to / - remove /features/pom.xml -> move the data directly in the parent pom.xml - remove /plugins/pom.xml -> move the data directly in the parent pom.xml - remove /org.eclipse.mat.releng - this one still contains mapping files for babel - remove /org.eclipse.mat.releng.athena Please comment.
This shows the current structure. http://dev.eclipse.org/viewcvs/viewvc.cgi/trunk/?root=TOOLS_MAT It is possible to maintain the plugins and features subfolders: http://stackoverflow.com/questions/2714665/create-a-project-in-eclipse-in-a-subfolder-of-the-workspace I've tried this and it works. I'm not sure how to set up the team project set to reflect this though. Moving the files in the root into a project would be useful though. Defining some working sets e.g. for Java projects, feature projects, build type projects might be useful. I haven't done much with them yet. Flattening the plugins and features directories might be required, but perhaps we can do this after moving files out of the root. What do other projects do?
Sure we can do the changes step-by-step. I can start with the root files. What I'd like to achieve at the end is: - download sources - either import from the SVN perspective or by using a team project set - set a target platform (also checked downloaded from SVN) - be able to develop in the IDE - be able to go to the file system and run the Tycho build - have all documented in the Wiki Having multiple team project sets is probably a good thing for contributors. I guess there are people who just need our sources in the IDE. They don't need to see all feature and other releng related projects.
I made a series of changes yesterday and now: - the files from the root folder are moved under /parent (I still need to add a .project file) - the /features/pom.xml and plugins/pom.xml are removed - all modules are specified directly in the parent pom - I changed all pom files of the modules to contain a relative path to the parent pom - adapted the path to the Macos icons in the product/mat.product file Unfortunately I faced some problems, which seem to be caused by inconsistent content in maven.eclipse.org hudson. And I made some commits trying to fix, before really finding the root cause... Now I changed also the parent pom to use this repo only if signing is activated, i.e. it may be turned by just reconfiguring the hudson job (see comment 23 in bug 210082). Next steps will be to see if I can find a way to checkout with the SVN in the IDE and build with tycho, while keeping the current structure. If I can't get this to work I'll move /plugins/* and /features/* to the root folder.
I've spent some time now playing with different options to get the projects easily opened in the IDE and at the same time buildable with mvn. I haven't found a way to directly import the projects (be it from the SVN team provider or using a project set) which keeps the file structure. The "best" procedure so far (if we want to keep the current structure) will be: 1) Add manually the SVN repository in the SVN Repository explorer perspective 2) Open a context menu on trunk (or whatever branch) and select just "Check Out" (NOT "Chech out as..."). Using "Check out" the whole branch will be checked out into the current workspace under org.eclipse.mat, a new .project file will be created there, and the project will be imported into the IDE as a general project 3) close the newly generated org.eclipse.mat project without deleting the contents on the file system 4) delete the <workspace>/org.eclipse.mat/.project file 5) Use File -> Import -> General -> Existing Projects into Workspace and point to the <workspace>/org.eclipse.mat directory 6) select all or just some projects and they will be automatically reconnected to the proper svn repository After this procedure one has the correct file layout so that the maven build works, and also the neccessary projects into the IDE. So right now I see two options: Option 1) - Keep the current structure (with features and plugins subfoldes) - Have a team project set file containing just the plugins - this should be enough for people looking at the code and trying out some changes/new development - Have the description above on the Contributors reference wiki page, so that people who would like to have everything and build with maven/trcho have a clearly defined procedure Option 2) - make a flat structure, i.e. all projects move directly under /trunk/. Then the root gets somewhat overpopulated, but... - we could offer a team project set which contains only the plugins (similar to option 1) - offer a team project set with all projects. Then one can just import all projects at once and be able to build with maven/tycho and also be able to change everything in the IDE I am still not fully convinced which the better option is, but would prefer at the moment Option 2). On the other hand, if we decide to move to Git at some moment, then we'll not have the problem. Git clone will anyway clone the whole repository (keeping the structure) and import is then a separate step. This could be one argument to keep the current (somewhat cleaner) structure for the moment. What do you think?
Another way to maintain the directory structure on SVN checkout is as in comment 1: Add Subversion repository at: https://dev.eclipse.org/svnroot/tools/org.eclipse.mat select 'trunk' select 'Find/Check Out As' select 'Find projects in the children of the selected resource' select 'recursively' Finish 'Following list contains projects that were automatically found on the repository. You can select project set you wish to be checked out into the workspace.' select 'Check out as a projects into workspace' select 'Respect projects hierarchy' 'Finish' Using working sets for plugins, features and other projects could be quite useful. I can export a team project set containing the working sets, or for one working set at a time. I can't import a team project set and maintain the directory structure of features and plugins subdirectories though. Another solution might be to maintain the SVN structure on the repository, but to have a flat structure for the local workspace and Maven builds. So in Hudson you would check out projects from: http://dev.eclipse.org/svnroot/tools/org.eclipse.mat/trunk/plugins http://dev.eclipse.org/svnroot/tools/org.eclipse.mat/trunk/features and the single projects http://dev.eclipse.org/svnroot/tools/org.eclipse.mat/trunk/parent http://dev.eclipse.org/svnroot/tools/org.eclipse.mat/trunk/org.eclipse.mat.product and fix up the pom.xml files to allow for this flat structure.
Thanks Andrew! I overlooked the proper answer on the page you send in comment 1. I think this is easy enough to describe and will go for it. The alternative to have the build expect a flat structure, and still have a nested structure in the repo is probably technically possible, but I think it may be confusing. I'll just put a couple of sentences that if people want to use the maven build locally, they need to respect the file structure, and then give the explanation how to do it. Sounds simple enough to me. And we'll definitely offer one project set for the plugins. I'm not sure the others really make sense, but we can put as many as we want, so just tell me (or upload yourself) what you find useful.
Another way of importing the projects is with m2eclipse do File > Import > Maven > Checkout Maven Project from SCM > Next SCM URL svn https://dev.eclipse.org/svnroot/tools/org.eclipse.mat/trunk/ Checkout Head Revision Checkout All Projects I don't know enough about Tycho/Maven to understand the errors in the pom.xml files Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-compiler-plugin:0.13.0:compile (execution: default-compile, phase: compile)
I can give it a try (so far I am not using m2eclipse). I think I got now the last proposal working (needed to add some .project files and rename a folder), and I am going to describe it. As an alternative, we can describe the approach with m2eclipse later.
One more thing - I executed the checkout steps again, this time with e4.2. After the checkout the org.eclipse.jdt.prefs files in all plugins got modified. There is currently a comment line with a timestamp on top of the file and import into 4.2 removes it. Not sure if this is because of newer version of jdt, or because of SVN import. I just wonder if I should commit the new version of the files (without the comment line) to avoid having changes just after import. And there is one project - o.e.m.ibmdumps which contains a lot more properties. They were some how reodreder ... Any suggestion waht to do?
I added two more target definitions (revision 1233) which can be used in the IDE - one for Helios and one for Indigo. Both are missing the DTFJ feature, as I don't know an external update site for it. Andrew, currently during the build we get dtfj as a zipped update site from an ftp location. This is fine for the build, but one needs some manual steps for the IDE. Is there an unzipped update site which could be directly used in the target files? Not sure what relations you have to the team providing the coding, but is it possible to request such an update site (if it doesn't exist)? :-)
I don't think there is an official update site for DTFJ - the Athena build used one but I don't think that is suitable for general use. Would something like this work? jar:ftp://ftp.software.ibm.com/software/java/support/tools/dtfj/dtfj-updatesite.zip!/
I've updated the mat-helios, mat-indigo, mat-juno target files to point to the dtfj zip. I haven't changed mat-site.target as this is used by the build and prepare_build/build.xml does the download including using the proxy for Eclipse.org Hudson builds. Changing the org.eclipse.jdt.prefs file makes sense - org.eclipse.mat.ibmdumps just has the recommended code formatter prefs - but we suggest doing a global setting, so it doesn't need to be in the project prefs.
I think we can close this one. I have no concrete improvement proposals at the moment.
