When I build my product .eclipseproduct is generated. Is this file still relevant for Eclipse 3.6+? Is there a way to modify this file to reflect my product? I know I can alter this file myself, but was wondering if there is a plugin that can do this?
In the installation profile (p2/org.eclipse.equinox.p2.engine/profileRegistry/<ProfileName>.profile/<highest number>.profile.gz) of your product installation, you can find out where the .eclipseproduct file comes from: It is extracted from the artifact org.eclipse.rcp_root. That artifact will always be installed when the org.eclipse.rcp feature (p2 id org.eclipse.rcp.feature.group) is installed.
So this file is not generated by the build, but it comes with artifacts referenced in your build. If you want to learn about it's purpose or want it to be changed, you should contact the providers of the org.eclipse.rcp feature.
Related
I have NopCommerce source code and I cannot see any payment methods which used to come default with nopcommerce. It says download from Marketplace but I cant find PayPal Standard plugin on the marketplace
In the root plugin folder I can see the plugin Nop.Plugin.Payments.PayPalStandard which has some files. I believe this is a source code of the plugin. Then I can also see an empty folder of Payments.PayPalStandard
I can see the plugin in action on the demo nopcommerce site so I believe it is still relevant and available.
Am I missing something? Where can I find the plugin and how can I install it on my application
Please download no source code from github.
Refer this link for download deployed code.
It's not possible that any payment plugin not there into plugin folder.
So please dowload from given link and check there are many payment plugins inbuilt.
Currently I have downoad nopCommerce_4.20_NoSource_SelfContained.rar and checked Payments.PayPalStandard is there.
Docs:
\Plugins is a Visual Studio solution folder that contains plugin projects. Physically it's located in the root of your solution. But plugins DLLs are automatically copied in \Presentation\Nop.Web\Plugins\ directory which is used for already deployed plugins because the build output paths of all plugins are set to ..\..\Presentation\Nop.Web\Plugins\{Group}.{Name}\. This allows plugins to contain some external files, such as static content (CSS or JS files) without having to copy files between projects to be able to run the project.
You need to build the project Nop.Plugin.Payments.PayPalStandard, to publish the binary files in the output directory of \Presentation\Nop.Web project. Then run the project and complete the installation process of the plug-in in the administrative panel.
I have used eclipse Features And Bundles Publisher to create a p2 metadata folder. But failed add the same folder as local site as eclipse keep on complaining Unable to find the site.
I could find content.xml and artifacts.xml but site.xml NOT generated through publisher command. I doubt if I have to create a site.xml manually.
FYI I am using eclipse KeplerSR2.
The p2 publisher should create a structure like this. Depending on pack attributed the content and artifact repository files [content and artifact] might be jared.
<repo-root-dir>
features
featureA.jar
...
plugins
pluginA.jar
...
content[.xml|.jar]
artifacts[.xml|.jar]
You won't get and won't require an update site file.
Make sure to clean the location you use from the Eclipse -> Preferences -> Available Softwares Sites. Eclipse is caching the repo metadata.
Yes you must have site.xml for update site from update_site
To create an update site you must develop a site.xml file and build the site. PDE provides an editor and project for creating sites. A site will contain one or more features organized into categories.
See how to create site.xml
I'm wondering: What is the best way of adding a bundle to a p2 based target platform?
I don't want to use local directories, I want to have a target platform that works 'out of
the box' for all our team members.
Right now I manage, but I have a feeling I'm missing a more straightforward way of
doing this.
My situation is as follows:
My target platform has a bunch of p2 locations, hosted at our on-site server.
Most are mirrored repositories, but I have one I use for 'miscellaneous' bundles.
This is how I add a bundle to the target platform.
I switch to another workspace, which does use a bundle directory with jars.
I add the bundle jar to that directory.
I add the bundle to my 'third party' feature
I export the feature, and upload it to our server, deleting the old one
I switch back to my normal workspace, and reload the target platform link.
Sometimes eclipse gets a bit confused and keeps using a cached version, but in
general this approach works.
My question:
Is there a easier way?
Is there a more 'incremental' way? I rebuild the p2 repository, instead of adding
a feature with a new version.
You should have a look at p2's publisher and mirror tools. The publisher creates p2 metadata, and with the mirroring, you can copy artifacts into an existing p2 repository (given you have file system access).
There is also a Maven front-end to these tools provided by the Tycho project.
I'm about the setup an automatic (command-line) build for my Eclipse RCP Application.
I have found out the following ways to do it:
Buckminster
Using Maven with the pde-maven-plugin
Headless PDE Build
The problem with all these options is that they require me to create essentially a new representation of the information already contained in my target platform definition. For example in Buckminster, this would be the .rmap file.
In my thinking all the information to build the product should be already there when I have the following:
Plugin project with product configuration file (foo.product)
Target platform definition file (foo.target)
Therefore I would expect there to be a command like the following:
build-rcp-product foo.product foo.target win32
Is there anything like that which I may have missed?
With Buckminster you don't need to replicate the information in your target definition file. You can simply import the target file using the importtargetdefinition command. If all your dependencies defined in the target definition file, then in the rmap you define only from where to materialize your plugins (svn, git, maven, file system etc).
With PDE build, there is a filed request (Bug 266311) and it seems it is still not possible to utilize the target file directly but there are some workarounds suggested in there (which I didn't try, I am using Buckminster).
I use the PDE build and it's pretty simple. It essentially gets what it needs from the MANIFEST.MF file and the build.properties file.
The command to run it is more complicated, as you have to start Eclipse and point it to a few things, but it's very well integrated with the IDE. It does everything by making Ant scripts.
you can try tycho
here's a good start:
Tycho tutorial
Reference card
with tycho, all you need is a POM and you usually will not change this information, which is generated via maven
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product