Eclipse p2 альтернатива для пользовательских обработчиков установки

Question

Перед p2 можно написать специальный обработчик установки с функцией, которая была выполнена для выполнения любой «пользовательской» задачи во время установки.

Я вижу, что с p2 пользовательский обработчик установки больше не поддерживается. Я продолжаю слышать о том, что «пользовательские контрольные точки» являются заменой для этого.

Однако я не могу найти для него конкретный пример/документацию.

Может ли кто-нибудь сказать мне, как получить функциональность пользовательских обработчиков установки с менеджером обновлений p2.

Edit: Описание того, что я хочу сделать -

мне нужно отредактировать файл eclipse.ini и установите -Xmx свойство значения на основе ли мы работаем внутри 64 бит или 32 бит.

Edit 2: Я попытался создать файл p2.inf в моей функции с помощью следующей строки -

instructions.install = \ 
addJvmArg(jvmArg:-Xmx900m); 

instructions.install.import= \ 
org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg, 

и она работает, однако он не делает различий между 32 и 64 бит.

Answer 1

p2.inf определенно является правильным местом для выполнения определенных пользователем действий. Хорошее место для добавления аргументов vm в .ini. Вы можете поместить p2.inf под вашу функцию/плагин.

Обновлено 20 декабря:

Я попробовал это на своей собственной среде, она хорошо работает, чтобы установить различные ут арг при установке той же самой функции на Linux 32bit и 64bit. Вы можете скачать example code, чтобы поиграть с ним.

#create a requirement on the IU fragment we are creating 
requires.2.namespace=org.eclipse.equinox.p2.iu 
requires.2.name=configure.com.example.yourfeature.linux.x86 
requires.2.range=[1.0.0,1.0.0] 
requires.2.greedy=true 
requires.2.filter=(&(osgi.os=linux)(osgi.arch=x86)) 

#create a IU frament named configure.com.example.yourfeature.linux.x86 for linux 32 bit 
units.0.id=configure.com.example.yourfeature.linux.x86 
units.0.version=1.0.0 
units.0.filter=(&(osgi.os=linux)(osgi.arch=x86)) 
units.0.provides.1.namespace=org.eclipse.equinox.p2.iu 
units.0.provides.1.name=configure.com.example.yourfeature.linux.x86 
units.0.provides.1.version=1.0.0 
units.0.instructions.configure=addJvmArg(jvmArg:-Xmx500m); 
units.0.instructions.configure.import=org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg, 

#create a requirement on the IU fragment we are creating 
requires.3.namespace=org.eclipse.equinox.p2.iu 
requires.3.name=configure.com.example.yourfeature.linux.x86_64 
requires.3.range=[1.0.0,1.0.0] 
requires.3.greedy=true 
requires.3.filter=(&(osgi.os=linux)(osgi.arch=x86_64)) 

#create a IU frament named configure.com.example.yourfeature.linux.x86_64 for linux 64 bit 
units.1.id=configure.com.example.yourfeature.linux.x86_64 
units.1.version=1.0.0 
units.1.filter=(&(osgi.os=linux)(osgi.arch=x86_64)) 
units.1.provides.1.namespace=org.eclipse.equinox.p2.iu 
units.1.provides.1.name=configure.com.example.yourfeature.linux.x86_64 
units.1.provides.1.version=1.0.0 
units.1.instructions.configure=org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg(jvmArg:-Xmx900m); 

Answer 2

Я думаю, что самые полные документы по этому вопросу - Eclipse wiki. Вы, вероятно, заинтересованы в «действиях на основе родной сенсорной точки», но также возможно реализовать собственное действие сенсорной точки, то есть класс Java, который вызывается как часть процесса установки.

EDIT: Customizing Metadata содержит информацию о том, что вы можете поместить в файл p2.inf. Пример, приведенный там:

instructions.install = \ 
    ln(targetDir:@artifact,linkTarget:foo/lib.1.so,linkName:lib.so);\ 
    chmod(targetDir:@artifact,targetFile:lib/lib.so,permissions:755); 
instructions.install.import= \ 
    org.eclipse.equinox.p2.touchpoint.natives.ln,\ 
    org.eclipse.equinox.p2.touchpoint.natives.chmod 

Answer 3

Есть две статьи, которые объясняют, как достичь этого:

• How to Add Custom Install Actions to Your Next Eclipse IDE Plug-in
• Custom touchpoints in P2

Сначала один охватывает немного больше вариантов, второй только о P2 точек соприкосновения.

ВНИМАНИЕ: Когда мы добавили пользовательские контрольные точки в наш плагин, он начал запирать (нередко, но не всегда) во время установки (мы не хотели риска и удалили их). Может быть, мы сделали что-то не так, но это то, о чем нужно знать.

Built-in touchpoints, похоже, работает нормально.