How can I include a mxj Java jar/class folder in a freezed m4l-Device? - max-msp-jitter

I have a maxforlive device using java/mxj.
I used all of these options to include my java files during development:
Including my (maven) target/classes directory through max.java.config.txt.
Adding a directory through Options > File Preferences
Adding a jar to the automatically generated (OSX) ~/Documents/Max 7/Max for Live Devices/MyProject Project/ directory
All of these paths work fine i.e. the files are picked up and my mxj object works.
However, when i freeze the device for publication, java files are not included from any of those paths.
I tried to make sense of
https://docs.cycling74.com/max7/tutorials/jitterchapter99_appendixd although I'm not building a standalone, but a freezed maxforlive device, so I included max.jar and mxj.mxo in the Project folder which did not work either.
When I copy my target/classes or target/classes/myproject folder into the generated Project folder (/code, /code/classes, /classes), max moves all the class files out into /code, creating a lot of work for me while not even picking the classes up for dev.
I saw devices on maxforlive.com with properly included java files, so I know it can be done. How can I achieve this?

Unfortunately this is a long standing bug in MFL.
Here is a movie from 2012 where I reproduce this, it has not been fixed since. http://arttech.nl/projectjavaissue.mov
This means that the only way to distribute MFL devices with java class files is to include them separately.

Ok, so here it is: Including just a single class with no other class dependencies except MaxObject works fine. There's also no need to add .java files like I said in my previous comment.
All you need to do is:
have the working mxj object in your patcher (doesn't matter where you saved it)
click the button on the bottom that says "Show containing project" on hover
add your classfile
freeze
When you have more classes, it gets complicated.
1) If you have your typical java hierarchy with folders and subfolders, that won't work. As you have to add each file separately, the hierarchy will be destroyed. Use a jar and add it to the containing project.
2) Here it comes, believe it or not: All the classes you are going to use will have to be loaded on first instantiation. I call it static class allocation ;)
A way to achieve that:
create a new instance of every class in the constructor of the class that extends MaxObject or any other constructors it calls. That includes classes with only static methods.
if you happen to use interfaces and create implementations of those dynamically (new Runnable() {...}), don't. Dynamic implementations are new classes.
Fun fact: you can override methods of classes, too. So go
class Runner {
public void run() { throw new Exception("not implemented"); }
}
then you can dynamically create a
new Runner() {
public void run() {
MaxObject.post("Even Mr. Gosling says interfaces were a mistake!");
}
}
Don't believe it? I don't blame ya. Look at
https://github.com/mihop/mxj-wsserver
and
http://www.maxforlive.com/library/device/3809
to be converted.

Related

Breakpoints in Provides method get remapped in Eclipse to ProvidesAdapter instead

I am having an issue in Eclipse (with Dagger 1 still).
In dagger, for dependency injection (javax.inject), you create a Module class, with provides methods, like this:
#dagger.Module
class FooModule {
#dagger.Provides
Something provideSomething() {
return new Something();
}
}
And this will generate a class (using annotation processing) called FooModule$$ModuleAdapter$ProvideSomethingProvidesAdapter.
If I set a breakpoint in a provideSomething method in FooModule class (my code), Eclipse almost always actually stops on that same line number in the FooModule$$ModuleAdapter$ProvideSomethingProvidesAdapter class instead.
Does anyone know how to avoid this problem? I suspect this is likely an Eclipse issue where it is somehow is mapping the generated file to what it thinks is the "source" file, but that's of course not what I want.
Is there perhaps some setting in eclipse to avoid this problem?

How to get an IType from a class name in Eclipse JDT

I'm implementing a variant of the JUnit New Test Suite Wizard, and instead of getting test classes from the current project, I need to get them from another source. They come to me as strings of fully-qualified class names.
Some of them may not yet exist in this user's workspace, let alone in the classpath of the current project. The user will need to import the projects for these later, but I don't want to mess with that in my wizard yet. I need to just add all classes to the new suite whether they exist yet or not.
For those classes that are already in this project's classpath, I can use IJavaProject.findType(String fullyQualifiedName) . Is there an analogous way to get ITypes for classes that are not (yet) visible?
I would be happy to construct an IType out of thin air, but ITypes don't seem to like being constructed.
I don't think that is possible: the Java Document Model interfaces are created based on the classpath.
Even worse, if the project do not exist in the users workspace, the resulting code would not compile, and that is another reason for not allowing the arbitrary creation of such constructs.
If I were you, I would try to help the user to import the non-existing projects in case of types are not available, thus avoiding the tackling with the Java Document Model.
For my purposes, creating a HypotheticalType and a HypotheticalMethod got the job done. I'm attaching an overview in case anyone else needs to follow this path.
First I created a HypotheticalType and had it implement the IType interface. I instantiated one of these at the proper spot in my modified wizard. Using Eclipse's Outline view I created a method breakpoint on all methods in my new class. This let me detect which methods were actually getting called during execution of my wizard. I also modified the constructor to take, as a String, the name of the class I needed the wizard to handle.
Almost all of the new methods are ignored in this exercise. I found that I could keep the default implementation (return null or return false in most cases) for all methods except the following:
the constructor
exists() - no modification needed
getAncestor(int) - no modification needed, but it might be useful to return the package of my hypothetical class, e.g. if my class is java.lang.Object.class, return java.lang.
getDeclaringType() - no modification needed
getElementName() - modified to return the class name, e.g. if my class is java.lang.Object.class, return Object.
getElementType() - modified to return IJavaElement.TYPE
getFlags() - not modified yet, but might be
getMethod(String, String[]) - modified to return a new HypotheticalMethod(name)
getMethods() - modified to return new IMethod[] { new HypotheticalMethod("dudMethod") }
In the process I discovered that I need to be able to return a HypotheticalMethod, so I created that type as well, inheriting from IMethod, and used the same techniques to determine which methods had to be implemented. These are the only methods that get called while this wizard runs:
The constructor - add a String parameter to bring in the name of the method
exists() - no modification needed
isMainMethod() - no modification needed
That covers the solution to my original question. Zoltán, I'll be doing as you suggested in an upcoming iteration and trying to assist the user in both the case in which the desired class is not yet in this project's classpath, and the case in which the desired class is in some project not yet in the workspace.

Eclipse: how to update a JUnit test file with newly added method in the source file?

Using Eclipse (Helios), I could create a JUnit test file ClassATest.java of the source file ClassA.java by using New -> JUnit Test Case -> Class under test..., then choose all the methods of ClassA to be tested.
If later we add some more methods to ClassA, how do we easily reflect this addition in ClassATest ? (No copy/paste plz).
One solution is to use MoreUnit
With MoreUnit installed to Eclipse, one can right click onto the newly added method (and not yet unit tested), and choose "Generate Test"
Of course, if one always follows the writing-test-before-writing-method style, then this solution is not needed. However in reality sometimes you don't have a clear idea of what you would want to do, in that case you would have to code up some method, play with it, then rethink and code again until you are satisfied with the code and want to make it stable by adding unit test.
You should look into creating a JUnit test suite which will execute all tests within the classes you specify. Thus, adding new test cases is as simple as creating a new class and adding it to the #Suite.SuiteClasses list (as seen below).
Here's an example.
Example JUnit Test Suite Class:
#RunWith(Suite.class)
#Suite.SuiteClasses({
TestClassFoo.class
})
public class ExampleTestSuite {}
Example Test Case class:
public class TestClassFoo {
#Test
public void testFirstTestCase() {
// code up test case
}
}

How to do resolving using Unity in a mutli-project solution

In a new WPF project (VS2010) i 'm using Unity 2 for the first time.
In this project i use the following structure:
Solution
WPF Project
Class Library1
Class Library2
Class Library 3 ....
Registering the different types using Unity is done in WPF Project using the following snippet:
IUnityContainer container = new UnityContainer()
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
Let's say now that i would like to get the Repository<Orders> constructor-injected resolved in Class Library1.
Apparently the container is not known in the other projects!
How would i do that?
I mostly agree with Chris' answer, but I think config files are icky (especially for Unity) so here's a solution that will allow you to use runtime config w/o circular references. We're going to do this with registries.
Create an Infrastructure project that will contain IConfigureUnity.
public interface IConfigureUnity
{
public void Configure(UnityContainer container);
}
Each of your class library projects will be responsible for implementing this interface to register it's own classes.
public class RegistryForSomeClassLibrary : IConfigureUnity
{
public void Configure(UnityContainer container)
{
container
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
}
}
Then in your WPF project you'll need to create the container and apply these registries.
var container = new UnityContainer();
new RegistryForSomeClassLibrary().Configure(container);
new RegistryForAnotherClassLibrary().Configure(container);
Now you have a fully configured container instance w/o any config files.
To have multiple projects make use of the same UnityContainer in this scenario, you need a "common" project that contains your UnityContainer and exposes it such that all other projects can access it.
i.e.
WPF Project
Class Library 1
Class Library 2
Class Library 3
Common Library (UnityContainer lives here)
To avoid circular project dependencies, I'd recommend using Unity design-time configuration via a configuration file instead of run-time configuration (as you have in your example). Otherwise your Common Library will have to reference the projects that contain all of the types it resolves and those projects, in turn, would be dependent on the Common Library (since that is presumably where you would expose the UnityContainer instance). You may be able to get it to work using run-time configuration, but I have not tried that; I do know that the design-time configuration works as I have done a few projects using a model exactly like this.

Namespace or type specified in project level imports does not contain a public member

I have an ASP.NET 3.5 web application project in which I'm trying to implement a searchable gridview. I originally started the project as a web site and converted it to a web application. After conversion, my class ended up in the folder Old_App_Code and is called SearchGridView.vb.
Imports System
Imports System.Collections
Imports System.Collections.Generic
Imports System.ComponentModel
Imports System.Text
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls
Imports System.Drawing.Design
<Assembly: TagPrefix("MyApp.WebControls", "SearchGridView")>
Namespace MyApp.WebControls
#Region "TemplateColumn"
Public Class NumberColumn
Implements ITemplate
Public Sub InstantiateIn(ByVal container As System.Web.UI.Control) Implements System.Web.UI.ITemplate.InstantiateIn
End Sub
End Class
#End Region
<ToolboxData("<{0}:SearchGridView runat=server></{0}:SearchGridView>")> _
<ParseChildren(True, "SearchFilters")> _
Public Class SearchGridView
Inherits GridView
The class file continues, but this is the first part of it.
Unfortunately, I receive the error message
Warning 1 Namespace or type specified in the project-level Imports 'MyApp.WebControls' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases. DielWebProj
In web.config, I included a namespace tag for MyApp.WebControls and I included an imports tag in the .aspx page as well.
Can anyone shed light as to why this error is being raised and how I would remedy it?
Thanks,
Sid
I have a broadly similar problem to you. I have a website project using a custom control, inheriting from GriView, in the app_code folder. I was recieving the very same error, but noted that it happened only after I would add a second class or module to app_code, and would disappear if I removed it.
So the workaround I have at the moment is to just leave my custom control as the sole occupant of app_code.
One option might be to make the control part of its own project and add it as a reference to the we site/app?
I'll update this if I can find a decent solution.
EDIT:
Well, in my case it was because the control I was using was written in C#, whereas the rest of the project, and classes I added to app_code, were in VB.
The app_code folder is compiled to a single assembly, so classes of different languages cannot share it, unless you create seperate sub-folders and do some config file jiggerypokery. More details here