I recently brought an existing maven project into Eclipse 2020-03. The project contains a jetty folder which itself contains a file:
modules/somefile.mod
The *.mod file pattern seems to be associated with the DTD content type, and this association is "locked". Because my file is not a DTD, it fails the validation.
Eclipse's Bugzilla lists a 7-year old bug, Bug 420688, which describes this problem, but the workarounds there don't seem to work for me.
The validation error I get is
The markup declarations contained or pointed to by the document type declaration must be well-formed.
Is there a way to
Disable the validation of this particular file, or preferably
Disassociate it from the DTD content type?
Thanks for any advice or direction.
Related
I'm in the early stages of creating a new Eclipse plug-in in Eclipse 2019-06. I created the plug-in using the "Hello World" wizard option and created a debug configuration that successfully launches a secondary workbench for testing. I can click on my new menu option and step into my new code.
I want to use a modified version of org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne, so I added the package to my project and edited NewTestCaseWizardPageOne. However, when I try to debug, the debugger asks for a source location. It seems to want to load the file from the local repository (.p2/pool/plugins/org.eclipse.jdt.junit_3.11.400.v20190510-0840.jar), rather than my edited version. Why is that?
There must be some kind of classpath problem, but don't versions of files in the project have precedence over those in the dependent plugins? I've looked at a number of similar questions (1, 2) and other sources, but I haven't yet found the answer. Please help.
Following Alexander Federov's suggestion, I converted my plugin into a fragment. This was fairly easy to do following the advice from this StackOverflow page. The main changes were:
Renamed plugin.xml to fragment.xml and changed the top level xml
element from plugin to fragment.
Added a Fragment-Host entry to MANIFEST.MF
The key advantage that this provided is discussed in an Eclipse Wiki
page:
... a fragment appears much the
same as a normal plug-in. A fragment can specify libraries,
extensions, and other files. When it is loaded by the platform loader,
a fragment is logically, but not physically, merged into the host
plug-in. The end result is exactly the same as if the fragment's
manifest were copied into the plug-in manifest, and all the files in
the fragment directory appear as if they were located in the plug-in's
install directory. Thus, a runtime library supplied by a fragment
appears on the classpath of its host plug-in. In fact, a Java class in
a fragment can be in the same package as a class in the host and will
even have access to package-visible methods on the host's classes.
The last part having to do with access to package-visible methods was what I needed. Thanks, Alexander!
my team created a project in Frame Maker and we want to convert it to DITA (that will be edited with Frame Maker). The conversion is done with Mif2go. It is complicated step and the DITA files may contain incomplete information. I was suggested to validate them using Eclipse (Kepler).
The DITA version of the files is 1.1 (the default of Mif2Go). I was needed to copy the DITA library files to eclipse workspace in order to validate the XML (including, for example, bookmap.dtd, bookmap.mod, and more). However, I get many errors for theese files when I validate the workspace of eclipse. For example, in the file "metaDecl.mod", i get error for the line "!ELEMENT author (%words.cnt;)*".
The error says:
" A '(' character or an element type is required in the declaration of element type "author"."
I get this error for many DITA files and I don't understand why.
I will extremely appreciate any clue...
Hard to tell based on your question and without understanding the Mif2go conversion.
I'd start with ensuring you have the Web Tools Platform (www.eclipse.org/webtools) installed in Eclipse. This includes XML validation. You may also want to download the DITA-OT from https://github.com/dita-ot and unzip it to your Eclipse workspace folder and add it as a project.
I am using Eclipse to convert HTML to DITA and validation seems to work OK on my DITA files. It may also be that Mif2go is writing out some bad XML; that .mod file is part of the DITA-OT, so that's probably not the issue. Maybe you can try removing the offending line and trying to validate again.
I created a project from existing sources as a PHP project in an older version of NetBeans.
I now want to change the project type to an HTML5/CSS project in NetBeans 7.4.
Is there any easy way to change the type of an existing project in NetBeans?
I'm trying to avoid creating a new project from existing sources as I have all my server connection variables already configured.
The project data is stored within the main project directory in a subdirectory named nbproject.
The file project.xml contains the main configuration data for the TYPE of the project. The type and data xml namexspace settings determine the basic project type. Here is a PHP version:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://www.netbeans.org/ns/project/1">
<type>org.netbeans.modules.php.project</type>
<configuration>
<data xmlns="http://www.netbeans.org/ns/php-project/1">
<name>codex-slp</name>
</data>
</configuration>
</project>
Here is an HTML5 project version:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://www.netbeans.org/ns/project/1">
<type>org.netbeans.modules.web.clientproject</type>
<configuration>
<data xmlns="http://www.netbeans.org/ns/clientside-project/1">
<name>csa</name>
</data>
</configuration>
</project>
Note the line is different. The HTML 5 project uses the namespace org.netbeans.modules.web.clientproject. The PHP version is at org.netbeans.modules.php.project.
Also of note is the data xmlns entry with HTML5 pointing to the clientside-project directory while PHP points to the php-project directory.
How to change the project? Not easily. Your best bet:
Close out the NetBeans IDE.
Go to the project directory.
Remove (or rename) the nbproject subdirectory.
Open NetBeans.
Create a new HTML5 project from existing sources.
That will switch the project type from PHP to HTML5 and give you the corresponding dialogue boxes.
The reason I decided to take this approach is there are a lot of other things that hang off this namespace specification. The project.properties file, for example, has very different entries for a PHP project, thinks like the PHP version, that do not exist for the HTML5 project. The HTML5 project has new properties that are not present in PHP projects.
There is also an entire private subdirectory that has a plethora of options set in the private.properties file that contains things like the source remote connection for a PHP project that does not exist nor seem to even be SUPPORTED for an HTML5 project.
There are far too many disparities between the two project types to simply hack up the nbproject directory files and hope it works.
IMO your best option is to follow the steps above to recreate the project.
Sadly, it does not appear as though HTML5 project types have matured to the point of the PHP project types with things like supporting remote pull/push of changed files. For this particular project I've reverted back to the PHP project type even though this is not really a PHP project. I heavily rely upon the automatic remote server push via FTP. How did I restore the project? I renamed my nbproject directory to saved_nbproject, so to revert:
Close Netbeans.
Go to project directory.
Rename my saved_nbproject directory back to nbproject.
Restart NetBeans.
Maybe changing project types AND HTML5 remote server support will be available in the future. For now, with NetBeans 7.4 it does not appear this transition is readily available.
If anyone else has input or other feedback I'd love to hear it as NetBeans has become my go-to tool for complex code projects.
NOTE: I would strongly suggest to create a new project from existing sources to ensure everything will work as expected. In most cases its faster and less problematic.
(If you persist....)
Following the accepted answer may result in an error. Besides what Charleston Software Associates posted, you may need to copy other variables included in "project.properties" file.
For example, these are for PHP: (adjust properly. I suggest to see some of your other projects to prevent mistakes).
auxiliary.org-netbeans-modules-php-phpunit.bootstrap_2e_create_2e_tests=false
auxiliary.org-netbeans-modules-php-phpunit.bootstrap_2e_path=
auxiliary.org-netbeans-modules-php-phpunit.configuration_2e_path=
auxiliary.org-netbeans-modules-php-phpunit.customSuite_2e_path=
auxiliary.org-netbeans-modules-php-phpunit.test_2e_run_2e_all=false
ignore.path=
include.path=
php.version=PHP_53
source.encoding=UTF-8
src.dir=/var/www/example
tags.asp=false
tags.short=false
web.root=.
These are for HTML5:
auxiliary.org-netbeans-modules-css-prep.less_2e_compiler_2e_options=
auxiliary.org-netbeans-modules-css-prep.less_2e_enabled=false
auxiliary.org-netbeans-modules-css-prep.less_2e_mappings=/less:/css
auxiliary.org-netbeans-modules-css-prep.sass_2e_compiler_2e_options=--style compressed
auxiliary.org-netbeans-modules-css-prep.sass_2e_configured=true
auxiliary.org-netbeans-modules-css-prep.sass_2e_enabled=true
auxiliary.org-netbeans-modules-css-prep.sass_2e_mappings=/scss:/css
auxiliary.org-netbeans-modules-javascript2-requirejs.enabled=true
auxiliary.org-netbeans-modules-web-clientproject-api.js_2e_libs_2e_folder=js
config.folder=${file.reference.example-config}
file.reference.example-config=config
file.reference.example-test=test
file.reference.www-example=/var/www/example
files.encoding=UTF-8
site.root.folder=${file.reference.www-example}
test.folder=${file.reference.example-test}
You can mix both in a single file without any problem.
Using: Netbeans 8.0.1
Try to edit your project.xml replace type with
<type>org.netbeans.modules.web.clientproject</type>
Guys this has changed for version 7.4?
in private.properties
remote.connection=remotename
remote.directory=/public_html/
remote.upload=ON_SAVE
run.as=REMOTE
url=http://remotename.com
I tried changing xml and that didn't work well for me. I fiddled around and found a way that seems simpler to me - just delete and create a new project!
Right click the project in netbeans, and click delete. (make sure to NOT check the box that says delete sources!). That clears out the netbeans project info. Then just make a new project of whatever type you want. Go to File->New Project. Select project type (in this case HTML5 Project with existing sources), making sure to select the one that has "with existing sources". Hit next. Now here is a key part. The site root is your mysite/public_html folder most likely. The project directory is your mysite folder. The netbeans config will be put in the mysite folder.
Then you should be good to go!
Close Netbeans.
Delete nbproject folder inside your app folder. It can be hidden folder , so , in windows, go to folder properties and activate hidden folder.
Reopen Net Beans. Create a new project of the correct type.
Where can I find dtd, xsd or whatever, that eclipse uses to validate ant build.xml file?
EDIT:
Actually eclipse is validating build.ini for referential integrity and I am interested to know how is it doing so. Is it using schematron or there is some more elegant way to do it?
There seems to be no official dtd (this link provides information why not and how to create an incomplete version). If you google for ant.dtd you will find information on this topic and also a link to an unofficial work-in-progress version.
So there must be more eclipse magic (or whatever) in validating/parsing the build.xml - I unfortunately do not know about it.
How do I externalize strings in my Eclipse plugin's plugin.xml?
Right-clicking on the plugin project > PDE Tools > Externalize Strings does not show up my plugin.
I'm trying to do this manually now. I added entries in plugin.properties and replaced the equivalent string in plugin.xml with a % sign followed by the string key. But that does not seem to work. What am I missing here?
I finally figured out how to manually externalize the plugin.
Eclipse, it turns out, externalizes plugin.xml this way:
In the plugin manifest (META-INF/MANIFEST.MF), add the following line
Bundle-Localization: plugin
where you intend to store the externalized strings in a file called "plugin.properties" (Turns out this was the missing piece).
Add the externalized string key-value pairs in plugin.properties.
Replace the actual strings in plugin.xml with the keys from plugin.properties (prefixed with %).
If your working set have plugin projects in it, the Externalize Strings wizard to help externalize strings in your Manifest and plugin.xml files should be available.
Externalizing manifest files extracts translatable strings and stores them in a properties file for multi-language support.
The wizard is available under the PDE Tools menu in the context menu of a PDE project's MANIFEST.MF or plugin.xml files.
(source: eclipse.org)
Be aware that there were some bugs related to detecting all non-externalized attributes/values of the <extension-point> and <extension> elements, or showing up un-externalized names of extension(-point), which are only solved in 3.4 or very recent 3.5M4.
However, if the "Externalize Strings" menu does not show up at all on your plugin projects, may be its "project nature" is corrupted somehow, may be your former Java project is not properly converted to a PDE project ?
So two suggestions:
try with a fresh install of an eclipse3.5M4
import your plugin project and check its nature
And then tell us if that menu is still unavailable.
As you mention in your own answer, the externalization process is declared by the string
Bundle-Localization: plugin
in the MANIFEST.MF file, as mentioned in this message.
A bug has been created, but:
The localization is not something specific to PDE but instead the OSGI specification
that line is not always in the MANIFEST:
Prior to 3.3, we created all our manifests by creating a plugin.xml and then
converting it. The converter always added "Bundle-Localization: plugin" to the
Manifest, since that is the default location if the plug-in has no Manifest.
If a plug-in had no translations files, this header was unnecessary bloat.
In 3.3, we created plug-in projects by creating Manifest directly, which means we
decided to create only the headers necessary for project creation.
it is likely to be an issue for those that have created bundles with
externalization < 3.2, and then not being able to see them when running in 3.3.