[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tycho-user] Optional included features
|
Dear Tobias,
Thank you for your reply.
The idea you suggest is clear to me, but I it differs from what I really want. Bellow I describe the limitations of yor idea(but it might be the most applicable).
I wiil try to explain what I want. Maybe, I want too much.
Consider the following project structure:
native-nar // are built on different platforms for different environments
parent-pom // tycho-based
main-product
main-feature
env1-pom
env1-feature
env1-plugin
env1-fragment-os-arch // for each supported os/arch . they depend on NAR artifacts (platform dependent)
env2-feature
env2-feature
env2-plugin
env2-fragment-os-arch // for each supported os/arch
Features env1 and env2 are optional because users would need only one of them (in my case this means support for exact Octave version).
Now I can do the full build of native projects and deploy all native artifacts in my Nexus repo. Then I can do the full build with Tycho and it will make a release version that is ready to work with different Octave versions. But what if I make a small change in native code?
I must increment the version of the native project and update the reference to it in tycho-based project. And now there are no such artifacts in local repo and Nexus. I need to recompile the new version of the native project for ALL environments just to test if my small change was OK.
So, I came to thought that in development mode I can avoid building native code for all environments, avoid building projects "env1" or "env2" depending on the current environment. But then I have to define, that the product would be still valid, if it misses one of these "env1" or "env2" features. In other words, yes, I want to build the part of the project.
Of course, there is a workaround(similar to the idea you suggest): I can update version of dependency to the native project only for fragment, that corresponds my current environment(and all other fragments will be taken from the local repo / Nexus). But this doesn't look like a good solution. With manual dependency tracking it is easy to forget something. I'd preffer to be sure that all native project versions are synchronized.
Is my explanation clear now? Isn't there more elegant way to solving such issue?
Best regards,
Vladimir.
2012/10/31 Oberlies, Tobias
<tobias.oberlies@xxxxxxx>
I heard that some people use optional dependencies in features for some valid use case. Apparently, these features are not considered optional
at build time. This has apparently not been a problem for other users.
I’m not sure I follow your use case. You want to build parts of your project? This should be easy: first build everything with mvn clean install,
and then you can build any subset of your project, and all other parts will simply be taken from the local Maven repository.
Doesn’t this work for you?
Regards
Tobias
Hello
I didn't reveive any responses to my question, so I downloaded Tycho source code and made small change to let missing included features marked as optional="true" be ignored.
It works for me, now I can build the product even if only one of the optional features is available.
My question: is this solution acceptable? I don't imagine any cases in which it will cause issues (the behavior changes only in case of missing optional feature). But as far as I understood from the source code, Tycho did not process this
attribute at all and it is not clear for me why. Maybe, the 'optional' attribute in Eclipse has different meaning and is not processed by Tycho for some logical reason.
If my change request is not acceptable, I would still need answer to the question from my first email: how can I make features optional depending on the Maven profile. If if is acceptable, I will prepare a patch.
2012/10/28 Владимир Большуткин <enargit@xxxxxxxxx>
Hello,
I use Tycho in my open-source project Octclipse. I encountered a situation that I cannot process with Tycho.
The project needs some native code built for the specific OS/arch and for the specific Octave version. I decided to have separate features for each Octave version and separate fragments for each supported OS/arch combination. Each fragment
requires specific native libraries (built by Maven NAR plugin on separate virtual machines). This approach works well when I have ALL native libraries built and stored in some Maven repository and want to build the whole release package with everything inside.
But if I change something in native code and want to test this change, I cannot build the product with only one feature (for the current development environment: current Octave version and OS/arch).
For instance, I have compiled native code for Octave 3.6.0 and want to build a product with the corresponding to test if it works. I tried exclude unnecesary modules using Maven profiles
<module>net.sf.octclipse.octave_3_6_0</module>
<module>net.sf.octclipse.octave_3_4_3</module>
and setting features optional in the parent feature
net.sf.octclipse.platform.feature/feature.xml:
<includes id="net.sf.octclipse.octave_3_6_0.feature" optional="true" version="0.0.0"/>
<includes id="net.sf.octclipse.octave_3_4_3.feature" optional="true" version="0.0.0"/>
In this case build process passes first dependency resolution but fails on module net.sf.octclipse.platform.feature with message:
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.17.0-SNAPSHOT:package-feature (default-package-feature) on project net.sf.octclipse.platform.feature: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:0.17.0-SNAPSHOT:package-feature
failed: Could not resolve feature net.sf.octclipse.octave_3_4_3.feature_0.0.0; Path to dependency: -> [Help 1]
Is this an expected behavior or a bug?
If it is correct, is there a way to perform build-time selection of features to be included in a product?
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user