this might be a duplicate question (see Xtext Project: Add Jar Libraries with the Project Wizard Manager into the Classpath/Referenced Libaries of the clients Project), but I'm not able to comment on the original one due to low reputation.
Therefore my question regarding a similar topic:
I created a custom DSL which is working nice so far. The next step for us is to support newly created projects in this language with a custom library that will come as a dependency for created projects. This library was also created using our DSL so it's fully compatible with other projects.
This library will contain basic datatypes and other types as well as the generated code that will be used by the generator of the "surrounding" project.
I would need a hint on how to include this jar-file into the process of new-project-instantiation. Adding it manually to the created project works like a charm, but I'd like to have some automatism in this.
I'm on to creating a custom project wizard for the DSL, but I'm kind of stuck there due to the not-so-availability of in-depth documentation on this topic.
Thanks
noff
Related
I have been working with Eclipse RCP for over a week now, and I've now been given an Eclipse plugin written in 3.x, which I need to migrate to 4.x. I'm using a book called Eclipse 4 RCP by Lars Vogel which has a small section on this, but I can't for the life of me figure out what I'm to do.
I'm trying to do this throught the use of the compatiblity layer. It mentions to add a couple of features for this (org.eclipse.rcp, org.eclipse.emf.ecore, org.eclipse.emf.common) and your ready to go, but I don't exactly know what I'm to do here. Like do I add these to the existing product file of the 3.x plugin I've been given, or do I create a separate e4 project and point to that. Many of the tutorials I read are a bit vague with the details and its a shame there's no proper step by step guide for beginners with this. Any help would be great.
Probably, you should be creating a separate e4 plug-in project for this. And where you have to configure your extensions/extension points in e4 ways.
Basically, like creating a new project.
If you want to migrate your Eclipse 3.x RCP application to the Eclipse 4 programming model, you can't directly reuse existing plugin.xml based user interface components, e.g. Views or Editors based on the definition in plugin.xml .
Components based on the plugin.xml file must be adjusted to avoid inheritance of Eclipse classes and to use the programming model based on #Inject . They also must be contributed to the application model.
Components which are not directly based on the plugin.xml file must be adjusted if they use Eclipse 3.x singletons, as for example Platform or PlatformUI , to access Eclipse API
you may want to take a look at this page: https://www.eclipse.org/community/eclipse_newsletter/2013/february/article3.php
I would like to know if there is a way to organize multiple DSLs inside a single Eclipse project. More specifically, I would like to organize all five Xtext projects of a DSL in some top-level "project folder".
The background is that we manage complexity and enable reuse by making smaller reusable DSLs, e.g. one reusable for expressions and other one for more domain-specific or application-specific aspects. However, each Xtext DSL results in 5 projects, causing a lot of clutter in the Package Explorer when multiple DSLs are involved. A strongly related question has been asked before:
Xtext: define 2 DSL's in one project
The answer there is that multiple DSLs are not needed inside the project for that specific use-case. My use-case is different because I want to be able to easily view the different DSLs and potentially co-develop them.
We are using Xtext in an environment managed by Gradle. We are using the Gradle Eclipse plugin, which creates a lot of Eclipse project files everywhere. As a result, when choosing to "Open Project from File System" in Eclipse, I not only get the option to import the five projects related to the DSL, but also the option of opening the parent folder as a project. This means I can have each DSL (all its five projects) organized neatly in a "project folder". This is exactly what I want! ...
BUT ...
it does not actually work. The figure below shows my package explorer with the five projects of my ExperimentDSL included in the bottom. This DSL works. On top, it shows the folder structure I get when including the project file generated by Gradle, resulting in a "project folder" that can potentially contain multiple DSLs.
As you can see, GenerateExperimentDSL is flagged red and refuses to run. It seems Eclipse somehow treats it as a Java project, but I do not know how to change this or and if this would help solve my problem. Secondly, I would not know how to set up such a project by hand, since the project file in this failing case was generated by Gradle.
Long story short, does anyone know how to get this kind of folder structure to work so that I can keep all my DSLs in the workspace without clutter?
What you try to do is currently not possible. Have a look at the concept of WorkingSets in Eclipse that let you achieve something similar
First of all, I have seen many links on stackoverflow of integrating XText with GMF.
The most consistent tutorial I've seen so far was: http://www.eclipse.org/forums/index.php/mv/msg/472225/1036564/#msg_1036564
..But not even generate a textual editor in the final step (only GMF editor).
I also saw the documentation, but I can not understand what they suggest in this link: http://www.eclipse.org/Xtext/documentation.html#gmf_integration
So I wonder if anyone knows how to integrate effectively the GMF with Xtext with an existing ecore! Use the XText 2.0.4.
Thank you!
Depending on how fixed you are on using GMF, you may want to look at Graphiti (built on GEF).
Graphiti is an Eclipse-based graphics framework that enables rapid development of state-of-the-art diagram editors for domain models. Graphiti can use EMF-based domain models very easily but can deal with any Java-based objects on the domain side as well.
There is an Eclipse Labs project for creation of Graphiti editors using an XText DSL, called Spray.
This project aims to provide one or more Domain Specific Languages (DSL) to describe Visual DSL Editors against the Graphiti runtime, and provide code generation to create the boilerplate code for realizing the implementation against the Graphiti framework. Potentially the Spray DSL can be used to generate code for other frameworks as well.
You can import your DSL ecore model into Spray, and using references to your DSL's types create a graphical editor with relatively little boilerplate. The presentation at CodeGen 2012 (SprayCodeGeneration2012.pdf on the Google Code link above) highlights some of Spray's features.
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.