Skip to content
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

Projects in Standalone and Eclipse #20

Open
mbakeranalecta opened this issue Aug 4, 2014 · 7 comments
Open

Projects in Standalone and Eclipse #20

mbakeranalecta opened this issue Aug 4, 2014 · 7 comments
Labels

Comments

@mbakeranalecta
Copy link
Contributor

Is there a way to open a project created in the standalone editor using the eclipse editor? I was hoping to do some of the docs work in the Eclipse editor (specifically when writing about it) but I cannot find a way to open the project file. (Open Project is grayed out.)

If there is no compatibility between eclipse and standalone projects, then the manual should say so. (I could not find anything on this.) Otherwise people like me will waste time trying to make it work. :-(

@raducoravu
Copy link
Contributor

A standalone editor project is fully incompatible with an Eclipse one.
We probably do not have this written in the user manual, probably because we considered that one user will mostly use one distribution and thus read one user manual profiled for it.
If you see a good place where this information could be inserted, please do.

@mbakeranalecta
Copy link
Contributor Author

Okay. Thanks.

The interesting question here is, do we consider a project file to be something that is unique to each author/developer, or are they a shared resource? That is, do we consider it normal practice that the project file would be included in the repository and shared by all members of the team?

That seems to be what we have done with the docs project, and it makes sense because so many project specific options are stored in there that you don't want each author/developer setting up for themselves.

But if they are a shared resource, then the fact that the two project types are incompatible means that the choice between standalone and eclipse should be a team decision, not an individual decision. This probably does make sense in most environments -- either they will be using an eclipse based tool set or not. But it does raise some questions about sharing projects between developers and documentation people, where the developers might be on eclipse and the docs people on standalone. In any case, it may be something we want to point out in the installation chapter -- if you are planning on sharing project files among a team, make sure they are all on standalone or all on eclipse.

Also, I am assuming that the standalone project files are compatible across platforms, so that people across different OSs could use the same project files stored in a repo?

Should the docs discuss the user of project files as shared resources in a repo?

And is there any practical way to work on the docs in eclipse, or is there to much dependence on the project file to make it worthwhile?

@raducoravu
Copy link
Contributor

  That is, do we consider it normal practice that the project file would be included in the repository and shared by all members of the team? 

Yes, it would be a good practice. As you saw we also use this practice for our user manual.

     But if they are a shared resource, then the fact that the two project types are incompatible means that the choice between standalone and eclipse should be a team decision, not an individual decision.

If they would like to share common preferences via the project, the team would need to use the standalone editor. In the Eclipse Oxygen user manual the project should probably not be discussed too much because on Eclipse we are just a plugin and the project is the usual Eclipse project which is described in the Eclipse documentation.

 Also, I am assuming that the standalone project files are compatible across platforms, so that people across different OSs could use the same project files stored in a repo?

Yes.

      Should the docs discuss the use of project files as shared resources in a repo?

So a separate topic which would discuss sharing a project with the members of a larger team? Probably.

   And is there any practical way to work on the docs in eclipse, or is there to much dependence on the project file to make it worthwhile?

You could probably create your own Eclipse project for the DITA files comprising our user manual. Then open in the DITA Maps Manager view the main DITA Map and work as usual. Indeed there are some formatting settings which are saved in the standalone project + already created transformation scenarios to publish more easily but I don't think they are essential.

@mbakeranalecta
Copy link
Contributor Author

If they would like to share common preferences via the project, the team would need to use the
standalone editor. In the Eclipse Oxygen user manual the project should probably not be discussed
too much because on Eclipse we are just a plugin and the project is the usual Eclipse project which is > described in the Eclipse documentation.

So the project facility in the Eclipse plugin is less capable than in standalone? Are there other ways in which the standalone version is more capable than the eclipse version. We might want to note this in the install chapter so the people are aware when they are making the choice between installing standalone or on eclipse.

@raducoravu
Copy link
Contributor

There are quite many small differences between the standalone and the eclipse plugin.
Our feature matrix table:

http://www.oxygenxml.com/xml_editor/feature_matrix.html#full_feature_matrix

has some features marked with a gray dot, these are the features which are only available in the standalone product. I'm not sure if we have this covered in the user manual.

@mbakeranalecta
Copy link
Contributor Author

I think it is worth adding a line in the Installation Options topic that says not all features of standalone are supported in Eclipse and points to the feature matrix for details. Could save the user from surprises later on.

@raducoravu
Copy link
Contributor

Yes, probably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants