Jim & Andrii,
The p2 update site (plus all projects in the org.eclipse.lyo.tools repository) are pure Eclipse plugin projects. Under the org.eclipse.lyo.core repository,
there are the 2 projects adaptormodel & codegenerator, which are also eclipse plugins. But these we agreed should also move to the tools repository.
So, once we move stuff to tools (as we have planned), we can try to clean up and maintain as much/little as necessary of the eclipse settings files. It is most
likely sufficient with only maintaining the .project file. But I can test and get back with an answer.
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx,
www.kth.se
From: lyo-dev-bounces@xxxxxxxxxxx [mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Amsden
Sent: 14 February 2017 23:18
To: Lyo project developer discussions
Subject: Re: [lyo-dev] UPDATE: Storing eclipse IDE specific files in eclipse/Lyo repositories
Andrii,
Thanks for the code formatting guidelines. Ultimately its the Gerrit review process and the committer's responsibility to ensure sufficient code consistency.
For existing projects like eclipse/Lyo, applying new coding guidelines can result in a lot white space changes in files that are difficult to review. If this is important (and that is something
that should be explored), then it should be done as a separate commit effort in order to simplify the review process.
I'm not familiar with the p2 update site build issues. But in theory doing a m2e Maven > Update Project... should set all the eclipse build information to be consistent with the Maven pom.xml file
for the eclipse project. If that's not the case, then possibly something is missing in the pom.xml file. In any case. eclipse/Lyo is not part of the Eclipse project build process or stored in the p2 repositories. So this may be an unrelated issue.
Projects that has launch configurations that should be stored with the project should use the Run Configuration dialog option (Common tab) to save the .launch file as a shared file within the project.
That way it is visible and gets committed like any other file. In cases where the launch configuration is specific to the user's environment, there's not much reason to save the launch configurations as they have to be edited anyway, and could expose personal
information (URIs, IDs, passwords).
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Andrii Berezovskyi <andriib@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 02/14/2017 02:57 PM
Subject: Re: [lyo-dev] UPDATE: Storing eclipse IDE specific files in eclipse/Lyo repositories
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Hi Jim,
I think it is a sensible idea to keep .project file alone, but only as long as it works well for those who use Eclipse. For all Lyo projects except code generation and modelling tools, I use IntelliJ
and never had issues with its project import from maven. I do this once per repository cloning.
There are 2 places where keeping as many settings from Eclipse as possible may be useful (at least I would test them twice before removing extra files):
1) In the Eclipse p2 update site project that seems to have regular build issues if we don’t retain the project state.
2) Projects with launch configurations that we distribute with some maven projects (most of them in lyo.docs, usually under src/test/resources/launches, but I am not sure if Eclipse points to them
somehow in the project settings).
As you are raising this question, I will take a moment to suggest a set of common code formatting rules. I wrote some internal guidelines at KTH, we may use them as a starting point. Find them
and my Eclipse style settings file attached.
– Andrew
On 14. Feb. 2017, 20:16 +0100, Jim Amsden <jamsden@xxxxxxxxxx>, wrote:
UPDATE: On second thought, maybe there's a compromise. We can store the eclipse .project files in the Git repository, but ignore .classpath and .settings/ since these may not be in sync with Maven
pom.xml files and can be easily set using m2e Maven > Update Project if desired.
So my modified proposal is to only ignore eclipse .classpath and .settings/ resources, but not .project.
--- previous post ---
The question came up about a consistent policy with respect to ignoring or including eclipse IDE specific files in eclipse/Lyo repositories. The files are .project, .classpath and .settings.
The .project file contains the eclipse project definition and is useful for loading eclipse project directly from the eclipse.org Git repositories using Egit. The .classpath file contains the classpath entries used by the eclipse builder. The .settings folder
contains additional eclipse resource, jdk and m2e preferences.
Although OSLC4J is built using Maven (and m2e in eclipse), it is also convenient to have your eclipse environment in sync with the maven pom.xml file so that you can leave eclipse automatic project build on and see compilation errors and other problems directly
in the problems view without having to execut an m2e command. You can make sure your eclipse environment is in sync with Maven pom.xml by using m2e Maven > Update Project. This updates the eclipse project setting to correspond to the directives in the pom.xml
file.
If a user of OSLC4J is not developing using eclipse, then these files are of no use and could be seen as cluttering their working directories.
However, eclipse/Lyo is an eclipse.org Technolgoy project, eclipse is often used in OSLC development, and the various folders in the eclipse/Lyo Git repositories were and are eclipse projects. Since these eclipse environment files are small, and typically hidden
from view, I think the benefit of saving these files in the Git repositories to simplify OSLC development using eclipse outweighs the costs.
So unless anyone disagrees, we should not include .project, .classpath and/or .settings/ in the .gitignore files so that these files are available for reuse in eclipse.
Note that there may be no guarantee that these eclipse property files are in sync with any particular nightly or other build of eclipse/Lyo or OSLC4J. Eclipse developers are advised to ensure their environments and the pom.xml files for any eclipse/Lyo project
are in sync if they wish to leverage eclipse build.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
[attachment "codestyle.pdf" deleted by Jim Amsden/Raleigh/IBM] [attachment "formatter.xml" deleted by Jim Amsden/Raleigh/IBM]
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev
