ceylon run: Module default/unversioned not found - ceylon

Today i installed the intelliJ ceylon IDE on my macbook. When compiling my project I get the following message
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java "-Dceylon.system.repo=/Users/Laust/Library/ApplicationSupport/IdeaIC2016.3/CeylonIDEA/classes/embeddedDist/repo" -Didea.launcher.port=7533 "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Users/Laust/Library/Application Support/IdeaIC2016.3/CeylonIDEA/classes/embeddedDist/lib/ceylon-bootstrap.jar:/Applications/IntelliJ IDEA CE.app/Contents/lib/idea_rt.jar" com.intellij.rt.execution.application.AppMain com.redhat.ceylon.launcher.Bootstrap run --run main default/unversioned
ceylon run: Module default/unversioned not found in the following repositories:
/Users/Laust/Library/Application Support/IdeaIC2016.
3/CeylonIDEA/classes/embeddedDist/repo
/Users/Laust/.ceylon/cache
https://modules.ceylon-lang.org/repo/1
[Maven] Aether
[NPM] npm
Process finished with exit code 1
The code executes fine on my other computer (windows 7).
the folder 'modules' contains the following:
default
default.car
default.car.sha1
default.src
default.src.sha1
and my build configuration looks as follows.
this is my code (in the file source/main.ceylon)
shared void main() {
print("Generating pretty sweet g-code:");
{Gcommand+} myGcommands = {
G00( Vector3(0.0, 0.0, 0.0) ),
G00( Vector3(9.0, 0.0, 0.0) ),
G00( Vector3(9.0, 9.0, 0.0) ),
G00( Vector3(0.0, 9.0, 0.0) ),
G00( Vector3(0.0, 0.0, 0.0) )
};
GcodeProgram myGcodeProgram = GcodeProgram( *myGcommands );
print(myGcodeProgram.toString());
}
"A carthesian coordinate class"
alias X => Float;
alias Y => Float;
alias Z => Float;
class Vector3(shared X x, shared Y y, shared Z z) {
}
"An abstract spec class for all G-code command classes"
abstract class Gcommand() {
shared formal String toString();
}
"G-code command for moving in a straight line at rapid speed"
class G00( Vector3 endPoint ) extends Gcommand() {
toString() => "G0 " + "X" + endPoint.x.string
+ "Y" + endPoint.y.string
+ "Z" + endPoint.z.string + "\n";
}
class GcodeProgram( Gcommand+ gcommands ) {
variable String stringifiedGcodeProgram = "";
shared String toString() {
for (gcommand in gcommands) {
stringifiedGcodeProgram = stringifiedGcodeProgram + gcommand.toString();
}
return stringifiedGcodeProgram;
}
}

The screenshot you provided shows that the run configuration isn't based on any IntelliJ module (Use classpath of module is set to [none]). This means that the configuration will not be run in your project folder where the modules directory lives. That directory contains the compiled code, and ceylon run will look for that directory when you ask it to run the default module.
Generally speaking, you should avoid creating run configurations manually. By clicking on the green arrow next to a runnable function's name, Ceylon IDE will automatically create and configure a correct run configuration.
To fix your existing run configuration, simply select the IntelliJ module that contains your code in the field labeled Use classpath of module.
See also the getting started guide for more information on how to get started with Ceylon IDE for IntelliJ.

That might be a bug with the IntelliJ plugin not handling "default" modules correctly. We tend not to use default modules much because they're more limited than regular modules.
Try creating a module and moving your code to it. THat will most likely fix the problem. If so you can then open an issue to have this bug fixed here: https://github.com/ceylon/ceylon-ide-intellij/issues/new

There appears to be something messed up in the project setup here. Note the list of repos that are being searched:
Module default/unversioned not found in the following repositories:
/Users/Laust/Library/Application Support/IdeaIC2016.3/CeylonIDEA/classes/embeddedDist/repo
/Users/Laust/.ceylon/cache
https://modules.ceylon-lang.org/repo/1
[Maven] Aether
[NPM] npm
I would expect to see a repo of form your-project-dir/modules as the second entry in that list, but it's not there.
That is to say, ceylon run is not looking in the modules directory where the compiled .car is. So the question is why that repo is missing from the list.
What do you see in Project Structure > Modules > Ceylon > Repositories?

In this question, the first (and only) answer tells how to create a new module.
I have a few comments to that answer:
when beginning on a new project, you probably don't need an intricate nested naming hierarchy for your modules. You will get that, if you use periods in your module name (eg. my.ceylon.example), so I suggest you stick to a simple name such as main.
when creating your new module, you will (among other things) be asked to specify a 'Runnable unit name'. The purpose of this field is to tell IntelliJ which of your modules' classes it should execute when starting your program. In other words, this becomes the entry point to your program. A suitable name for this could (also) be main.
Ceylon projects are divided into modules, modules are divided into packages, and packages are divided into classes and top-level functions. When you create a module, a package is automatically created under this module. The path for your code files under this module will be 'source/moduleName/packageName'. When creating a new module, you don't get to specify the name for the first package in the module. Instead the package is given the same name as your module name. Thus a module named 'main' would have this path: source/main/main as the path for it's code files.
In your new modules folder (eg. source/main/main) three new files will be created. Find the file that is named after the 'Runnable unit name' you chose earlier. Your code should go into this file. Also, your code should have a class with the exact same name that you chose as your 'Runnable unit name'.
the answer used the fancy term 'runnable unit', by which he just means a file containing Ceylon code.
remember to delete the file containing your old 'default' module, before trying to run your new module.
a module name cannot start with a capital letter.
modules/ is the output directory where compiled code goes. It is automatically recreated from the code in source/ when the project is built.

Related

Can the ConfigurationAPI in Liferay DXP be used for Plugin sdk portlet?

I have followed given 2 tutorials to use COnfigurationAPI in a Liferay dxp plugins SDK portlet built using Ant/Ivy.
COnfiguration API 1
COnfiguration API 2.
Below is the configuration class used:
package com.preferences.interfaces;
import com.liferay.portal.configuration.metatype.annotations.ExtendedObjectClassDefinition;
import aQute.bnd.annotation.metatype.Meta;
#ExtendedObjectClassDefinition(
category = "preferences",
scope = ExtendedObjectClassDefinition.Scope.GROUP
)
#Meta.OCD(
id = "com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration",
name = "UnsupportedBrowser.group.service.configuration.name"
)
public interface UnsupportedBrowserGroupServiceConfiguration {
#Meta.AD(deflt = "", required = false)
public String displayStyle();
#Meta.AD(deflt = "0", required = false)
public long displayStyleGroupId(long defaultDisplayStyleGroupId);
}
Post following the steps,I am getting the below error:
ERROR [CM Configuration Updater (ManagedService Update: pid=[com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration])][org_apache_felix_configadmin:97] [org.osgi.service.cm.ManagedService, id=7082, bundle=297//com.liferay.portal.configuration.settings-2.0.15.jar?lpkgPath=C:\dev\Liferay\osgi\marketplace\Liferay Foundation.lpkg]: Unexpected problem updating configuration com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration {org.osgi.service.cm.ConfigurationAdmin}={service.vendor=Apache Software Foundation, service.pid=org.apache.felix.cm.ConfigurationAdmin, service.description=Configuration Admin Service Specification 1.2 Implementation, service.id=56, service.bundleid=643, service.scope=bundle}
Caused by: java.lang.IllegalArgumentException: wrong number of arguments
So,does this process need a osgi module as mandatory or can we do it using plusings sdk portlet built using ant as well?
Without disecting the error message Caused by: java.lang.IllegalArgumentException: wrong number of arguments:
The way you build your plugin (Ant, Maven, Gradle, manually) doesn't make a difference, as long as you build a plugin that will be understood by the runtime. aQute.bnd.annotation.metatype.Meta points firmly into the OSGi world, and makes it almost certain that you'll need an OSGi module. You can build this with Ant, of course. Even in Ant you can embed tools like bnd, or you can write the proper Manifest.mf to include in your module manually (just kidding - you don't want to do it manually, but it would work).
Recommendation: Instead of moving everything over: Try to reproduce this with a minimal example in gradle or better Liferay Workspace (which is gradle based), just to get all the automatic wiring in. Check if it makes a difference and compare the generated output from your Ant build process with the workspace output. Pay specific attention to the Manifest.
In order to build the proper Manifest, you want to use bnd - if the Manifest turns out to be your issue: Find a way to embrace bnd - if that's by saying goodby to Ant, or by tweaking your build script remains your decision.

Using JUnit in Jython - NameError for assertTrue

Environment Details
Mac OS X 10.9
Oracle JDK 1.7.0_55 64-bit
jython-standalone-2.5.3.jar
junit-4.11
What I have done so far
I have added the junit jar to /Library/Java/Extensions.
I invoked Jython as follows java -jar jython-standalone-2.5.3.jar
In the Jython interpreter, I imported the following import org.junit.Assert, and this import was successful.
Problem
When I tried to use assertTrue, I got a NameError in the interpreter. Why is this so?
I understand that assertTrue is a static method. Not sure what implication this has when I try to use it in Jython.
Additional Context
I am using XMLUnit in Jython. Was able to successfully import the Diff class from org.custommonkey.xmlunit in Jython. Also able to use the methods in this class, and call them on a Diff object. The result of this method call is what I am trying to pass to assertTrue, when it throws the error.
from org.custommonkey.xmlunit import Diff
import org.junit.Assert
xml1 = ...some XML string...
xml2 = ...some XML string...
myDiff = Diff(xml1, xml2)
assertTrue(myDiff.similar())
Hope this additional information is useful in identifying a solution to this problem.
Latest Status
I narrowed it down to setting this property python.security.respectJavaAccessibility = false, since the Assert() constructor is protected.
Still trying to get it to work. Any help is greatly appreciated.
Figured it out.
In addition to junit.jar file, the hamcrest-core.jar file also needed to be copied to /Library/Java/Extensions.
Then I got rid of the jython.jar file, and instead installed it using the jython installer.
After the installation was completed, I updated the registry file in the installation folder, specifically setting this property python.security.respectJavaAccessibility = false.
Now I am able to see the assertTrue method, and no longer getting a NameError.

MEF: "Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information"

Scenario: I am using Managed Extensibility Framework to load plugins (exports) at runtime based on an interface contract defined in a separate dll. In my Visual Studio solution, I have 3 different projects: The host application, a class library (defining the interface - "IPlugin") and another class library implementing the interface (the export - "MyPlugin.dll").
The host looks for exports in its own root directory, so during testing, I build the whole solution and copy Plugin.dll from the Plugin class library bin/release folder to the host's debug directory so that the host's DirectoryCatalog will find it and be able to add it to the CompositionContainer. Plugin.dll is not automatically copied after each rebuild, so I do that manually each time I've made changes to the contract/implementation.
However, a couple of times I've run the host application without having copied (an updated) Plugin.dll first, and it has thrown an exception during composition:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information
This is of course due to the fact that the Plugin.dll it's trying to import from implements a different version of IPlugin, where the property/method signatures don't match. Although it's easy to avoid this in a controlled and monitored environment, by simply avoiding (duh) obsolete IPlugin implementations in the plugin folder, I cannot rely on such assumptions in the production environment, where legacy plugins could be encountered.
The problem is that this exception effectively botches the whole Compose action and no exports are imported. I would have preferred that the mismatching IPlugin implementations are simply ignored, so that other exports in the catalog(s), implementing the correct version of IPlugin, are still imported.
Is there a way to accomplish this? I'm thinking either of several potential options:
There is a flag to set on the CompositionContainer ("ignore failing imports") prior to or when calling Compose
There is a similar flag to specify on the <ImportMany()> attribute
There is a way to "hook" on to the iteration process underlying Compose(), and be able to deal with each (failed) import individually
Using strong name signing to somehow only look for imports implementing the current version of IPlugin
Ideas?
I have also run into a similar problem.
If you are sure that you want to ignore such "bad" assemblies, then the solution is to call AssemblyCatalog.Parts.ToArray() right after creating each assembly catalog. This will trigger the ReflectionTypeLoadException which you mention. You then have a chance to catch the exception and ignore the bad assembly.
When you have created AssemblyCatalog objects for all the "good" assemblies, you can aggregate them in an AggregateCatalog and pass that to the CompositionContainer constructor.
This issue can be caused by several factors (any exceptions on the loaded assemblies), like the exception says, look at the ExceptionLoader to (hopefully) get some idea
Another problem/solution that I found, is when using DirectoryCatalog, if you don't specify the second parameter "searchPattern", MEF will load ALL the dlls in that folder (including third party), and start looking for export types, that can also cause this issue, a solution is to have a convention name on all the assemblies that export types, and specify that in the DirectoryCatalog constructor, I use *_Plugin.dll, that way MEF will only load assemblies that contain exported types
In my case MEF was loading a NHibernate dll and throwing some assembly version error on the LoaderException (this error can happen with any of the dlls in the directory), this approach solved the problem
Here is an example of above mentioned methods:
var di = new DirectoryInfo(Server.MapPath("../../bin/"));
if (!di.Exists) throw new Exception("Folder not exists: " + di.FullName);
var dlls = di.GetFileSystemInfos("*.dll");
AggregateCatalog agc = new AggregateCatalog();
foreach (var fi in dlls)
{
try
{
var ac = new AssemblyCatalog(Assembly.LoadFile(fi.FullName));
var parts = ac.Parts.ToArray(); // throws ReflectionTypeLoadException
agc.Catalogs.Add(ac);
}
catch (ReflectionTypeLoadException ex)
{
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
}
}
CompositionContainer cc = new CompositionContainer(agc);
_providers = cc.GetExports<IDataExchangeProvider>();

Referencing and using JScript.NET "functions only" exe assembly

1. Compiled Assembly from JSC
I've compiled what is intended to be client-side JavaScript using the JScript compiler (jsc.exe) on the server side in an attempt to make something that can be tested from a unit testing project, and maybe even something that can be debugged on the server side.
The compiled file contains only functions as follows (just for example) and it compiles fine into BitField.exe. Notice, no wrapper class or package in the source code.
------ BEGIN FILE (BitField.js) -------
function BitField(){
this.values = [];
}
// more functions ...
------- END FILE -------
jsc /fast- /out:BitField.exe Bitfield.js
Results in a BitField.exe assembly.
Success! Well, kind of ....
2. Testing Assembly / Access Point?
Secondly I've created a test project (in C#) and referenced in the BitField.exe assembly successfully. (The type of project is irrelevant but I'm providing more description to paint a full picture.)
The problem seems to be: I cannot find the namespace or a point at which I can access the BitField functions inside the BitField.exe assembly from my C# test project. The assembly doesn't seem to be a "normal".
In other words I need in C#
using ???WHAT???
Note: I don't want to use JScript "extensions", meaning keywords that won't run client-side (in a web browser), for example, class, package etc because I want the code to be clean as possible for copy & paste back into client side script environment (Regardless said "clean" code compiles fine by jsc.exe without use of those extensions). When I try to wrap the functions in package and class it starts producing compile errors so that's another reason not to use them - because they appear to make me alter my code.
Any suggestions as to how I can use the functions of the compiled JScript assembly (by having it referenced into another assembly) when there are no explicit containers in it?
Update / Proof
.NET Reflector view
After playing around with it for a while, and trying various combinations of command-line switches for jsc.exe, I'm pretty sure that what you're trying to do won't work as you'd wish it to. If you try to compile a js file that contains functions into a .Net library assembly, you get an error:
BitField.js(1,1) : error JS1234: Only type and package definitions are allowed inside a library
But, there is hope, yet! Here's what I would do...
I would keep your "clean" BitField.js file just as it is, and then create a batch file that wraps it in a JScript class and writes it out to a "dirty" js file. It's pretty clean if you think of it as part of the compilation of the code into the DLL. The code to wrap the BitField.js into BitFieldClass.js would look like this:
merge-into-class.js
var fso = new ActiveXObject("Scripting.FileSystemObject");
var ForReading = 1;
var inputFile = fso.OpenTextFile("BitField.js",ForReading, false);
var outputFile = fso.CreateTextFile("BitFieldClass.js", true);
outputFile.write("class BitFieldClass{\n");
while (!inputFile.AtEndOfStream)
{
var textLine = inputFile.ReadLine();
outputFile.write (textLine + "\n");
}
outputFile.write("}");
outputFile.close();
Then the batch file to wrap it and compile it is really simple:
compile-js.bat
cscript merge-into-class.js
jsc /t:library /out:BitFieldClass.dll bitFieldClass.js
Of course, if you wanted to do multiple files, you'd have to parameterize things a bit, but hopefully this is enough to demonstrate the idea.

grails base.dir system property

I have a simple grails file upload app.
I am using transferTo to save the file to the file system.
To get the base path in my controller I am using
def basePath = System.properties['base.dir'] // HERE IS HOW I GET IT
println "Getting new file"
println "copying file to "+basePath+"/files"
def f = request.getFile('file')
def okcontents = ['application/zip','application/x-zip-compressed']
if (! okcontents.contains(f.getContentType())) {
flash.message = "File must be of a valid zip archive"
render(view:'create', model:[zone:create])
return;
}
if(!f.empty) {
f.transferTo( new File(basePath+"/files/"+zoneInstance.title+".zip") )
}
else
{
flash.message = 'file cannot be empty'
redirect(action:'upload')
}
println "Done getting new file"
For some reason this is always null when deployed to my WAS 6.1 server.
Why does it work when running dev but not in prod on the WAS server? Should I be accessing this information in a different way?
Thanks j,
I found the best dynamic solution possible. As a rule I never like to code absolute paths into any piece of software. Property file or no.
So here is how it is done:
def basePath = grailsAttributes.getApplicationContext().getResource("/files/").getFile().toString()
grailsAttributes is available in any controller.
getResource(some relative dir) will look for anything inside of the web-app folder.
So for example in my dev system it will toString out to "C:\WORKSPACEFOLDER\PROJECTFOLDER\web-app\ with the relative dir concated to the end
like so in my example above
C:\WORKSPACEFOLDER\PROJECTFOLDER\web-app\files
I tried it in WAS 6.1 and it worked in the container no problems.
You have to toString it or it will try to return the object.
mugafuga
There's a definitive way...
grailsApplication.parentContext.getResource("dir/or/file").file.toString()
Out of controllers (ex. bootstrap)? Just inject..
def grailsApplication
Best regards!
Grails, when it's run in dev mode, provides a whole host of environment properties to its Gant scripts and the app in turn, including basedir.
Take a look at the grails.bat or grails.sh script and you will find these lines:
Unix: -Dbase.dir="." \
Windows: set JAVA_OPTS=%JAVA_OPTS% -Dbase.dir="."
When these scripts start your environment in dev mode you get these thrown in for free.
When you take the WAR and deploy you no longer use these scripts and therefore you need to solve the problem another way; you can either
Specify the property yourself to the startup script for the app server, eg: -Dbase.dir=./some/dir .. however
... it usually makes more sense to use the Grails Config object which allows for per-environment properties
Another option:
def basePath = BuildSettingsHolder.settings.baseDir