I am developing a plugin for NetBeans 8.0 and I created a LookupProvider which is registered like that:
#LookupProvider.Registration(projectType = {
"org-netbeans-modules-ant-freeform",
"org-netbeans-modules-j2ee-archiveproject",
"org-netbeans-modules-j2ee-clientproject",
"org-netbeans-modules-j2ee-earproject",
"org-netbeans-modules-j2ee-ejbjarproject",
"org-netbeans-modules-java-j2seproject",
"org-netbeans-modules-maven",
"org-netbeans-modules-web-clientproject",
"org-netbeans-modules-web-project"
})
I would like to know if there is the possibility to reference the project types from a constant (which is already defined by the NetBeans platform) or do I really have to declare them as strings (like org-netbeans-modules-web-clientproject)?
I believe there are constants for these but the question is if you really want to depend on them. Oftentimes the constants are hidden in the project type's own module that doesn't provider API packages or provides them only to friends. And typically your own primary dependency is on the interface that you implement and put into the lookup. There could be some sort of master list in a public package somewhere but that could always just list the subset of project types. Also please note that for maven you can actually have an unlimited number of constants as we support only registering your LP to a given maven packaging type.
Related
EDIT : got it shorter.
We created three modules following the prism doc and our requirements.
We did a horizontal slices with modules.
SharedServices
BusinessLogic
UserInterface
In the UserInterface we are using Syncfusion components and other packages, and It would be great to put everything in the UserInterface module but how can we reference nuget assemblies from that module in the shell (to apply theming for example) to avoid having references in each modules & the shell ?
Should we add nugetpackage to each module and the shell (is it bad... ?) or is it possible to have one module which defines base class referencing external assemblies for example and that would be themable (with ResourceDictionary) & usable in the whole solution (shell & other modules) .
Thanks.
Very broad question, it might well be closed, but I try to give you a few guiding thoughts:
Generally, you either slice horizontally (as you did, UI-module with all the views plus logic-module with all the services) or vertically (as your Product-module suggests: views, view models, services for the product in one module, those for the user in another).
You can do both, but then you should "slice through", so one module for product-ui, one for user-ui, one for product-services, one for user-services... you get the idea. That means a lot of modules, though.
Also, when creating your modules, have an idea of what you want to achieve. Modules can encapsulate components to be reused in another app. Or they can encapsulate exchangeable components, so you could create a car-sharing app today and tomorrow swap out the car-module for a bike-module and have a bike-sharing app. Or they can be used to enforce segregation of code based on risk analysis in a regulated environment. What I'm trying to convey: don't create modules just to have modules, make each module have a defined purpose.
Also, define the interfaces for the modules. I don't like modules to reference each other, as it effectively destroys all segregation that would otherwise be there. Create seperate non-module assemblies that only contain public interfaces. Then make your modules contain the implementations as internal types. In an ideal world, no module assembly contains a public type. The interface-assemblies can be either per module or per consumer or per link between modules (those checked boxes in your N2-chart, you have one, don't you?).
You want to keep the number of modules reasonable, as well as the dependencies between them (not as in "assembly references" but through interface-assembly).
how can we reference nuget assemblies from that module in the shell (to apply theming for example) to avoid having references in each modules & the shell ?
You should separate the "interface" part (e.g. base classes or DTOs, not part of the module) and the actual services part (that's the module). Example: unity has a nuget package for the interfaces (Unity.Abstractions) and one that contains the container implementation (Unity.Container). There's nothing wrong with everyone referencing the interface, basically, that's saying "I want to use that interface".
In JOGL, there are lots of native jars for different OS x arch combinations. JOGL has several of its own mechanisms to load the right ones if you aren't using java.library.path, and supports a kind of "fat jar" layout.
In a fat jar layout, any native libraries need to be in a subdirectory ./natives/os.and.arch/. However, since the native jars themselves don't have any internal layout, similarly named so/dylib/dll files collide the flat hierarchy in the final jar.
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time. Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
Example
jogl-all-2.1.3-natives-android-armv6.jar is pulled in through a dependency.
$ jar -tf jogl-all-2.1.3-natives-linux-amd64.jar
META-INF/MANIFEST.MF
libjogl_mobile.so
libnewt.so
I'd like this to go here in the final jar:
./natives/
./natives/linux.and.amd64/
./natives/linux.and.amd64/libnewt.so
./natives/linux.and.amd64/libjogl_mobile.so
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time.
All merge strategies are invoked every time. MergeStrategy.deduplicate, which is the default strategy for most files, just happens to take effect only if there's a collision.
MergeStrategy.rename, applied for README and license files by default for example, will rename the file every time by appending the jar name.
Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
There's no strategy out of the box that does exactly that, but you can define a custom strategy similar to MergeStrategy.rename.
Just follow this rule as Xerxes explained here. There is then no longer any risk of collision. The official JogAmp forum is a better place to ask questions about all JogAmp APIs. If you don't follow my advice, GlueGen will be unable to extract and load the correct native libraries. In your case, natives/linux-amd64 is correct whereas natives/linux.and.amd64 isn't.
How can I get GWT to provide the same dependency insights as mvn dependency:analyze?
Maven can report about dependencies (Used undeclared dependencies and Unused declared dependencies). I'd like to get GWT to do the same because determining missing inherits in my gwt.xml proves difficult.
Is there a good way for the system to analyze dependency state?
Thanks
Peter
I'm not aware of any such tool, and while I think a utility to analyze and report on GWT dependencies could be interesting, I also think it would be difficult to define well.
Used, undeclared dependencies
Before trying to solve this, what is the problem? In maven, this category means that a Class is loaded from a dependency that isn't directly depended on, but instead is transitively loaded. This starts to get into the whole issue of transitive dependencies (which exist in GWT) and scopes (which don't). If A uses a class in C, but only depends on B, which depends on C, this will be listed in the 'used, undeclared dependencies' list.
In GWT however, we very rarely list every single dependency we use directly. Instead, we assume that transitive dependencies will stay transitive - we dont bother to inherit com.google.gwt.user.RemoteService for RPC as long as we already have com.google.gwt.user.User listed.
So how could we tell if we are using an undeclared dependency, the kind that warns when we do a gwt:compile? Perhaps such a tool could find every .gwt.xml file on the classpath, and read through its <source> and <super-source> rules to look for somewhere that a class we are using is declared? Or in the case of invoking GWT.create on something and getting back a non-concrete type, it could look for <replace-with> and <generate-with> rules. As long as your code already compiles in Java, the classes are on the classpath, but you still run the risk that while the class is there, the .java or .gwt.xml files might not be.
Unused, declared dependencies
This seems like an easier problem - analyze the modules we are inheriting, and look through them for any module that could be pruned out. Unfortunately, as the above discussion notes, we can't just look for the classes and which package they are in, which <source> and <super-source> elements are unused - we also would need to look for <replace-with> and <generate-with> rules - consider something like com.google.gwt.user.RemoteService, which only adds a rule and some configuration details, or even com.google.gwt.user.RemoteServiceObfuscateTypeNames, which modifies only a single setting of the RemoteService module. If RemoteServiceObfuscateTypeNames were removed, everything would still compile, but now there might be information about your RPC classes compiled into your app that you don't expect to be there.
With these in mind, perhaps such a tool could watch all possible rebind rules in the current build, and all configuration settings, properties, etc, and see if any of those rules were not using during a gwt:compile process. Then, indicate which modules had unused parts, and if any module (and all of its inherited modules) were unused, it could shown to the user as able to be removed.
One more important piece: order matters, when defining <inherits> statements. If I add a inherits for com.google.gwt.logging.Logging, then follow it with com.google.gwt.logging.LoggingDisabled, logging classes will be on the source path and will compile, but will have no effect. But if those are ordered the other way around, then they will not only be on the source path, but will all be functional. So any analysis of modules used and unused would need to also include transitive inherits statements, and their orders.
Using Eclipse Juno with VJet
Can you create typelib from javascripts yourself?
I know you can download jquery and a few others from: http://www.ebayopensource.org/p2/vjet/typelib/
But obviously you will need others.
Regards
Chris
Yes type libraries are just JavaScript files which use VJETDoc and VJOJS to define types for
object literals using vjo.otype
functions which do not change Function definition vjo.otype
functions which have additional properties using vjo.ftype
methods of a class using vjo.ctype
globals which can be define using a .globals section.
and more...
Many type libraries are located under this github address
https://github.com/ebayopensource/vjet-typelib
More info about VJETDoc[1] and VJOJS[2] and type library tutorial[3]
[1]http://www.ebayopensource.org/wiki/display/VJET/VJETDoc+Quick+Reference
[2]http://www.ebayopensource.org/wiki/display/VJET/Semantic+Comparison+-+Java+and+VJET+VJO
[3]http://www.ebayopensource.org/wiki/display/VJET/VJET+Type+lib+Tutorial+-+part+1
In my custom Eclipse plugin, I have the fully qualified class name of a Java class as a String, and want to know its actual file path. In fact, I want to know the name of the source folder it resides in.
The class could be from any of the Java projects in the Workspace. The source folder names are arbitrary.
I use Eclipse 3.6.
Thanks!
You will have to use the search engine API. See org.eclipse.jdt.core.search.SearchEngine.
You can see that there are various static functions you can call, each with their own options. You will need to create an appropriate org.eclipse.jdt.core.search.SearchPattern and then pass it to the search engine along with a scope (the workspace) and a requestor (something that gathers all of the results).
Typically, you will get a bunch of stuff back, like ITypes, which are the public API for accessing types in the Java model. You can call IType.getResource().getLocation() to get the filesystem location of any type. The getResource method may return null, so you need to check for that.
You will need to use the JDT API stuff to get to the IResource of the Java class. From there you can use the Resource API to get the containing folders and whatever else you need.