Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] org.eclipse.jdt.core.prefs 1.5, 1.7 ? management by maven
Hi, Benoit,

See some replies in-line, below.

Cheers,

Christian



On Thursday, Mar 12, 2015 at 05:28, MAGGI Benoit <benoit.maggi@xxxxxx>, wrote:

Hi Christian,

 

I probably misunderstand you because there is no way (in my understanding) that oomph will make any automatic git commit.



Right.  I’m not suggesting that it does (or should).  That would be scary.

 

 

Here is what I understood/believe :

-        If someone installed its eclipse with oomph

-        If they used the new plugin wizard

-        Then preference files will be automatically populated by Oomph


Yes.

 

-        If preference files are included in the git commit

-        Then preference will be pushed/shared in git repository



Yes.

 

ð  Feel free to refute any of these points



Nothing to refute.

 

ð  Is there an easy way to manipulate all prefs files ?



Yes.  Configure Oomph to push preferences from the org.eclipse.papyrus.infra.core project to all other org.eclipse.papyrus.* projects, then load all of the Papyrus projects into the workspace.  Done.
 

 

I believe the main concern of François is about keeping a version consistency between papyrus plugins.

This is a legitimate concern since this feature [1] (which remove most the inconsistency between Hudson build and developer build)

 We moved the version inconsistency between plugins to the Hudson build.



No, what we did is to correct the Hudson build to build each project in accordance with its stated BREE.  If the BREE is not properly declared, that is a different problem.

 

I already shared my concern on the mailing list [2] but still think that patching the inconsistency between Dev and Hudson was more important.  

 

In short :

-        Do we want to inforce version consistency between papyrus plugins ?



Is it necessary?  If some plug-ins want to be deployable in a Java SE 6.0 environment and some require Java SE 7.0, that’s fine.

(admittedly in the case of a project like Papyrus that is primarily end-user tools, it’s a bit odd)

But the important thing IMO is to build the plug-ins to match their JRE requirement, and now we have that.


(Also with extra ?)

-        If so, how do we plan to do that ?



The way to do it would be to update the BREE of all plug-ins to what we think it should be, then run PDE’s classpath update action, and commit the changes.

 

Regards,

Benoit

 

[1]: https://git.eclipse.org/r/#/c/41536/

[2]: http://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02446.html

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : mercredi 11 mars 2015 13:23
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] org.eclipse.jdt.core.prefs 1.5, 1.7 ? management by maven

 

Hi,

 

There is something like this.  Oomph provides a project preferences management tool that maintains consistency of all our projects' settings.  The JDK level is determined by each plug-in's BREE and everything else is kept in sync with the settings in the org.eclipse.papyrus.infra.core plug-in, which serves as the master or template for our common project preferences.

 

You will notice how every time new plug-ins are added they are followed shortly after by a commit that brings their preferences up to standard.

 

The .prefs files for preferences don't support arbitrary variable substitution and never have. They predate any sort of integration of maven into Eclipse.  Using maven to substitute variables in these files would require an external maven execution to populate them before first use of a new workspace. Let's not do that.

 

Cheers,

 

Christian

 

 

On Wed, Mar 11, 2015 at 3:29 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi

I recall raising a Bugzilla a long time ago about a missing level of Eclipse project hierarchy between project (CM controlled) and workspace (personal and anarchic). There should be super-projects (CM controlled) so that e.g. all Papyrus projects inherit their CM controlled settings from a single super-project. JDT preferences are just one example of this. Without this, everything else seems like a fudge.

Perhaps Papyrus could motivate fixing this longstanding deficiency.

    Regards

        Ed Willink

On 11/03/2015 07:16, LE FEVRE FRANCOIS wrote:

Dear all,

I have some difficulties to understand how is managed the jre version between eclipse, tycho and maven.

I have found that projects/plugins hold a org.eclipse.jdt.core.prefs files with

 

org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7/1.5

org.eclipse.jdt.core.compiler.compliance=1.7/1.5

org.eclipse.jdt.core.compiler.source=1.7/1.5

 

my question is:

why these file do not have a project properties such as ${jre.compiler.target.version}, ${jre.compiler.compliance.version}, ${jre.compiler.source.version} defined somewhere else?

Or

Why we do not have a uniq org.eclipse.jdt.core.prefs that is hold by a configuration project and when maven/tycho is called the first build phase will consist to copy and filter this file?

 

Thanks for your comments.

 

Francois

 

 

 

 

François Le Fèvre

Institut CARNOT CEA LIST – Nano INNOV

CEA Tech/DILS/Laboratoire d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),

Point Courrier n°174

91191 Gif sur Yvette CEDEX

T :0169084986

@ :francois.le-fevre@xxxxxx

 

-

LISE: http://www-list.cea.fr/fr/ingenierie-logiciel-et-systeme

Papyrus: https://www.eclipse.org/papyrus/

Blog: http://biocamp.blogspot.fr/

 

 

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5751 / Virus Database: 4299/9270 - Release Date: 03/10/15

 

 

Back to the top