-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add project configurator for tycho packagings #967
Add project configurator for tycho packagings #967
Conversation
@@ -13,5 +13,7 @@ Require-Bundle: org.eclipse.m2e.core;bundle-version="[2.0.0,3.0.0)", | |||
org.eclipse.core.resources;bundle-version="3.16.0", | |||
org.eclipse.m2e.maven.runtime;bundle-version="[3.8.6,4.0.0)", | |||
org.eclipse.pde.core, | |||
org.eclipse.jdt.core | |||
org.eclipse.jdt.core, | |||
org.eclipse.pde.ds.annotations;bundle-version="1.2.500", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't know which version range to take here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you are using mainly internal classes any version range that does allow a future version has the potential to break.
IIRC in that case it is recommended to just specify a lower bound as you already did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact I only use constant which are interned at build time, so this is not a real run time requirement, but I haven't found a way to tell PDE to only load a package in the build classpath....
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR.
Additionally this should also help for #929.
I applied a few comments below, but in general I think this is on a good way.
@@ -13,5 +13,7 @@ Require-Bundle: org.eclipse.m2e.core;bundle-version="[2.0.0,3.0.0)", | |||
org.eclipse.core.resources;bundle-version="3.16.0", | |||
org.eclipse.m2e.maven.runtime;bundle-version="[3.8.6,4.0.0)", | |||
org.eclipse.pde.core, | |||
org.eclipse.jdt.core | |||
org.eclipse.jdt.core, | |||
org.eclipse.pde.ds.annotations;bundle-version="1.2.500", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you are using mainly internal classes any version range that does allow a future version has the potential to break.
IIRC in that case it is recommended to just specify a lower bound as you already did.
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
fix configuration
clean up plugin.xml
@HannesWell any more comments? For me it looks like a good first addition, we might improve/enhance this later on ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few more remarks below.
Furthermore please format the class with the standard Eclipse built-in formatter to align it with the other classes in this plugin. Mainly to use tabs instead of spaces for indentation. If you use the M2E-setup in a clean workspace, that should be set up by default.
In general it would be good to have tests (for all configurations in this Plug-in).
If you want to create some that would be great, otherwise I can do that in the next days.
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
...eclipse.m2e.pde.connector/src/org/eclipse/m2e/pde/connector/TychoPackagingsConfigurator.java
Outdated
Show resolved
Hide resolved
get rid of SLF4J dependency some simplifications in code
MavenProject mavenProject = request.mavenProject(); | ||
IProject project = request.mavenProjectFacade().getProject(); | ||
String packaging = mavenProject.getPackaging(); | ||
if ("eclipse-plugin".equals(packaging) || "eclipse-test-plugin".equals(packaging)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably there should also test class folders be added to the Java Build Path (compare with eclipse-tycho/tycho#1491). Is there any recommended code layout for unit tests inside eclipse-plugin
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any recommended code layout for unit tests inside
eclipse-plugin
?
You mean in general or for testing this connector?
At the moment I don't think there is a general recommendation since Plug-in projects cannot (yet) specify test-dependencies and the usual pattern is to separate tests into fragments.
However I would make it similar to the maven structure and have a separate src-test
or test-src
folder where the sources are placed.
probably there should also test class folders be added to the Java Build Path (compare with eclipse-tycho/tycho#1491).
For a eclipse-test-plugin
that would be reasonable, yes.
Do you want to include that into this PR or create a follow-up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eclipse-plugin-test
is nothing we should specifically support as it is actually nothing special and has only a meaning when executing Tycho. Even there I always would recommend to use eclipse-test
instead.
Whether or not a folder is meant as a test-folder can not be derived from the Tycho configuration, you can guess it from the standard maven layout, but m2e already does that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eclipse-plugin-test
is nothing we should specifically support as it is actually nothing special and has only a meaning when executing Tycho. Even there I always would recommend to useeclipse-test
instead.
Is eclipse-test
a new packaging type? I don't know about that.
However since that topic seems not yet settled, lets merge this PR now and improve/enhance in with follow up PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is eclipse-test a new packaging type? I don't know about that.
Should be eclipse-plugin
with test
folder ;-)
Signed-off-by: Hannes Wellmann <wellmann.hannes1@gmx.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now, thank you.
I just applied a few minor adjustments and clean-ups myself.
The most relevant are probably that the warning about multiple executions is added to the first and chosen one (which is then more clear for the user) and wrapping the Version creation into a try-catch block to handle invalid version strings.
This closes #605