Re: [tycho-user] Special Use Case to Discuss :: Building Custom Target P

["Oberlies, Tobias" <tobias.oberlies@xxxxxxx>]

Are you building stage_2 with Tycho? If yes, you can put stage_1 to 3 in one reactor.

In stage_2 you are saying that you are merging three libraries into one OSGi library. This can lead to problems if your wrapper then meets other wrappers (e.g. from the springsource EBR) of one of these libraries in the same OSGi runtime. This tends to produce problems which require very advanced OSGi knowledge to resolve. 
Try to avoid creating own wrappers, and if you have to, you should wrap the libraries one by one.

Regards
Tobias


> -----Original Message-----
> From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-
> bounces@xxxxxxxxxxx] On Behalf Of Timo Rohrberg
> Sent: Dienstag, 18. Oktober 2011 10:18
> To: tycho-user@xxxxxxxxxxx
> Subject: [tycho-user] Special Use Case to Discuss :: Building Custom
> Target Platform
> 
> Hello everybody,
> 
> since one of my recent bugreports issued a serious discussion in the
> bugreport system, I would like to share the following use case
> description with you. Maybe you have additional comments, suggestions
> and hints for how to implement the solution in a more straightforward
> way.
> 
> The basic idea is to have an own Eclipse target platform including a
> selection of Eclipse plugins, as well as bundles wrapping plain Maven
> jar artifacts (and their corresponding sources) for organization
> internal use and external deployment on customer systems. The target
> platform should only contain what is really necessary and thus,
> pre-packaged Eclipse features cannot easily be used since they include
> additional stuff which we don't need for our particular setup.
> 
> During development time, we would of course like to use the same
> target platform as the one which is later shipped to the customer.
> Additionally, we do need sources attachments available for all plugins
> and the ability to easily navigate and debug into those sources from
> within the Eclipse IDE.
> 
> In addition to this, own bundles need to be built within a continuous
> integration process based on the Jenkins build server. We do have a
> running setup using Buckminster, but would like to replace this by a
> Tycho based system. The continuous integration process should also
> build towards the custom target platform mentioned above. Once certain
> bundles become stable, they will be integrated into an additional
> second target platform defining the set of own bundles shipped to the
> customer (of course together with the Eclipse and thirdparty bundles
> of the first target platform).
> 
> To simulate all of this, I set up the attached sample projects.
> Building them with Tycho works in the meantime, but maybe you have
> additional comments on how to solve the issue more straightforward.
> 
> "build_stage_1_eclipse" contains two feature projects which just
> rebundle a certain selection of Eclipse plugins and their sources for
> the custom target platform. The selection is still subject to change.
> 
> "build_stage_2_external" contains the sample project
> "com.example.logging" which rebundles three existing Maven jar
> artifacts in one bundle and exports the SLF4J API. The
> "com.example.feature" project then defines and builds a feature
> containing the binary version of the resulting bundle and
> "com.example.source.feature" its sources version.
> 
> "build_stage_3_repository" contains the sample project
> "com.example.repository" which builds the p2 repository to be deployed
> on an internal Apache webserver. From there, an Eclipse target
> platform can then be setup on the developer machines.
> 
> "usage_demo" contains a Hello RCP demo project depending on the
> general Eclipse plugins, plus the "com.example.logging" bundles. Once
> a target platform has been setup using the p2 repository just built,
> the Eclipse IDE should be able to build the demo project and allow
> navigation into the sources of the required plugins.
> 
> Proceed as follows to reproduce the use case (note: using separate
> workspaces simulates the desired separate steps in the continuous
> integration process which should only build artifacts that have been
> changed and reuse the others as they were built before):
> 
> 1. Extract the attached sample projects.
> 2. Move the contents of the "build_stage_*" folders into separate
> Eclipse Indigo Workspaces.
> 3. Move the "usage_demo" project into another separate Eclipse Indigo
> Workspace.
> 4. Subsequently run "mvn install" on the projects of the
> "build_stage_1_*" folders, except for the final one.
> 5. Run "mvn package" on the "com.example.repository" project to pack
> the resulting p2 repository.
> 6. Copy the results of the last step to a webserver.
> 7. In the workspace containing the "usage_demo" project setup a new
> target platform using the p2 repository just built. Make sure to
> select all features, including the source features.
> 8. Eclipse should now be able to build the "usage_demo" project and
> you should be able to navigate into the sources of the required
> bundles (Eclipse ones AND "com.example.logging").
> 
> I hope this explanation effectively describes my use case and I
> appreciate any hints and suggestions for implementing the solution in
> a more straightforward way.
> 
> Regards
> Timo
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tycho-user