Not sure if it will be Eclipse or Eclipse-plugin-dev answer.
In open-source Nodeclipse project plugin.xml defines that .coffee file can be launched as coffee, coffee --compile or Node with monitor (There are 3 defined LaunchShortcuts).
First time it work fine, but then consequent launches only repeat previous LaunchType. I have found that deleting saved LaunchConfiguration (from Run -> Run Configurations) will let it run again (and then only as this type again)
The code in question is LaunchShortcut (see snippet below), however there is no any if checking, so this behavior should be deeper in Eclipse org.eclipse.debug module.
How can saved LaunchConfiguration override LaunchType ?
/**
* Launch an file,using the file information, which means using default
* launch configurations.
*
* #param file
* #param mode
*/
private void launchFile(IFile file, String mode) throws CoreException {
// check for an existing launch config for the file
String path = file.getFullPath().toString();
ILaunchManager launchManager = DebugPlugin.getDefault().getLaunchManager();
ILaunchConfigurationType type = launchManager.getLaunchConfigurationType(Constants.LAUNCH_CONFIGURATION_TYPE_ID);
ILaunchConfiguration configuration = createLaunchConfiguration(type, path, file);
DebugUITools.launch(configuration, mode);
// then execution goes in LaunchConfigurationDelegate.java launch() method
}
/**
* Create a new configuration and set useful data.
*
* #param type
* #param path
* #param file
* #return
* #throws CoreException
*/
private ILaunchConfiguration createLaunchConfiguration(ILaunchConfigurationType type, String path, IFile file) throws CoreException {
String configname = file.getFullPath().toString().replace('/', '-');
if(configname.startsWith("-")) {
configname = configname.substring(1);
}
ILaunchConfiguration[] configs = DebugPlugin.getDefault().getLaunchManager().getLaunchConfigurations(type);
for(ILaunchConfiguration config : configs) {
if(configname.equals(config.getName())) {
return config;
}
}
// create a new configuration for the file
ILaunchConfigurationWorkingCopy workingCopy = type.newInstance(null, configname);
workingCopy.setAttribute(Constants.KEY_FILE_PATH, path);
setMoreAttributes(workingCopy);
return workingCopy.doSave();
}
protected void setMoreAttributes(ILaunchConfigurationWorkingCopy workingCopy) {
// stub for extension
}
Help! The code snippet is maybe not enough to answer the question, but references files and everything is in Github repository. The question was raised, because I am not sure if it is possible at all to have many Run Configuration for the same file. Then code snippets doesn't matter at all.
Update: Looking after a while at plugin.xml defines that .coffee file can be launched , I noticed that I am actually using the same <configurationType
id= "org.nodeclipse.debug.launch.LaunchConfigurationType" > in all 5 cases. However adding unique LaunchConfigurationType id for every launch makes no difference.
You can create the launch configuration with this:
Creating a Java application launch configuration
Launch groups can also be setle with this help:
Launch Group
Until here Im pretty sure you have knowledge about, so lets keep moving; You can have different launch configuration for the same file, thats handled with the launch group tool, what I dont get is if you want those different configuration for the same environment or not.
Also here Launch Configuration Types and here Adding launchers to the platform you cand find information about the struct of the launch type file
To finish here Interface ILaunchConfigurationTabGroup is the interface of the launch type tab group;
My Suggestion in codelines:
<extension point="org.eclipse.debug.ui.launchConfigurationTabGroups">
<launchConfigurationTabGroup
<"launchConfigurationType1"
<"/launchConfigurationType1">
<"launchConfigurationType2"
<"/launchConfigurationType2">
//and so on...
</launchConfigurationTabGroup>
</extension>
Related
I use Eclipse and Maven and have made a single JUnit test, just to test if it works. The first time I ran the test everything went as expected, but since then, every time I run it, I get the same result, even though I'm changing the actual test-file's content.
I tried just emptying the file, then it said that there are no JUnit test files. But as long as I just have #Test in front of a method in that file, I always get the same results.
Anyone know why that could be?
I tried restarting eclipse.
EDIT:
Just realized that I'm not getting the test results since there is an exception before it gets tested. So, the problem is that I'm always getting the exception even though I changed the file.
Testclass:
public class zipTester {
/**
* The class to be tested on.
*/
private Generator generator;
/**
* Sets up the generator.
*/
#Before
public void setUp() {
generator = new Generator(null, 0);
}
/**
* Creates a zip file and tests whether it exists.
*/
#Test
public void testCreateZip() {
File file = new File("/Users/nicola/Documents/trunk);
generator.createZip(file, new Vector<File>());
}
}
Changed TestClass:
public class zipTester {
#Test
public void heyo() {
}
}
Always getting the following Exception:
java.io.FileNotFoundException: /Users/nicola/Documents/trunk (No such file or directory)
...
1 May be you should clean your project
2 and then recheck project-BuildAutomatically
if still have something wrong,
you can right-click your project "java build path" and open the first tab Source
set default output folder content "test/target/classes"
good luck :)
i think your code was not compiled by eclipse
Seems that happen when there is no file in the relevant location.Because you are passing the file to Generator and try to access that file.Then this exception happen as there are no file to access with generator.
You can follow the below steps to avoid this scenario.
First check is that file exist in that location as below,
File file = new File("/Users/nicola/Documents/trunk");
assertTrue(file.exists());
Then check with your Generator.
I am currently implementing a shell with limited functionality using Java programming language. The scope of the shell has restricted requirement too. The task is to model a Unix shell as much as I can.
When I am implementing the cd command option, I reference a Basic Shell Commands page, it mentions that a cd is able to go back to the last directory I am in with the command "cd -".
As I am given only a interface with the method public String execute(File presentWorkingDirectory, String stdin).
I will like to know if there is API call from Java which I can retrieve the previous working directory, or if there any implementation for this command?
I know one of the simple implementation is to declare a variable to store the previous working directory. However I am currently having the shell itself (the one that take in the command with options), and each time a command tool is executed, a new thread is created. Hence I do not think it is advisable for the "main" thread to store the previous working directory.
Update (6-Mar-'14): Thank for the suggestion! I have now discussed with the coder for shell, and have added an additional variable to store the previous working directory. Below is the sample code for sharing:
public class CdTool extends ATool implements ICdTool {
private static String previousDirectory;
//Constructor
/**
* Create a new CdTool instance so that it represents an unexecuted cd command.
*
* #param arguments
* the argument that is to be passed in to execute the command
*/
public CdTool(final String[] arguments) {
super(arguments);
}
/**
* Executes the tool with arguments provided in the constructor
*
* #param workingDir
* the current working directory path
*
* #param stdin
* the additional input from the stdin
*
* #return the message to be shown on the shell, null if there is no error
* from the command
*/
#Override
public String execute(final File workingDir, final String stdin) {
setStatusCode(0);
String output = "";
final String newDirectory;
if(this.args[0] == "-" && previousDirectory != null){
newDirectory = previousDirectory;
}
else{
newDirectory = this.args[0];
}
if( !newDirectory.equals(workingDir) &&
changeDirectory(newDirectory) == null){
setStatusCode(DIRECTORY_ERROR_CODE);
output = DIRECTORY_ERROR_MSG;
}
else{
previousDirectory = workingDir.getAbsolutePath();
output = changeDirectory(newDirectory).getAbsolutePath();
}
return output;
}
}
P.S: Please note that this is not the full implementation of the code, and this is not the full functionality of cd.
Real shell (at least Bash) shell stores current working directory path in PWD environment variable and old working directory path in OLDPWD. Rewriting PWD does not change your working directory, but rewriting OLDPWD really changes where cd - will take you.
Try this:
cd /tmp
echo "$OLDPWD" # /home/palec
export OLDPWD='/home'
cd - # changes working directory to /home
I don’t know how you implement the shell functionality (namely how you represent current working directory; usually it’s an inherent property of the process, implemented by the kernel) but I think that you really have to keep the old working directory in an extra variable.
By the way shell also forks for each command executed (except for the internal ones). Current working directory is a property of a process. When a command is started, it can change its inner current working directory, but it does not affect the shell’s one. Only cd command (which is internal) can change shell’s current working directory.
If you want to keep more than one working directory just create a LinkedList where you add each new presentWorkingDirectory at the and and if you want to return use linkedList.popLast to get the last workingDirectory.
I m trying to run i-jetty in eclipse using the m2e (maven) plugin. The source code of file IJettyService.java at line 530 gives makes this call
SslSelectChannelConnector sslConnector = new SslSelectChannelConnector(sslContextFactory);
Eclipse IDE here complains
The constructor SslSelectChannelConnector(SslContextFactory) is
undefined
so I used a decompiler and found out that it does exists.
/* ------------------------------------------------------------ */
public SslSelectChannelConnector()
{
this(new SslContextFactory(SslContextFactory.DEFAULT_KEYSTORE_PATH));
setSoLingerTime(30000);
}
/* ------------------------------------------------------------ */
/** Construct with explicit SslContextFactory.
* The SslContextFactory passed is added via {#link #addBean(Object)} so that
* it's lifecycle may be managed with {#link AggregateLifeCycle}.
* #param sslContextFactory
*/
public SslSelectChannelConnector(SslContextFactory sslContextFactory)
{
_sslContextFactory = sslContextFactory;
addBean(_sslContextFactory);
setUseDirectBuffers(false);
setSoLingerTime(30000);
}
I don't understand why its behaving this way . Did anyone came across similar problem?
from what you posted here this should work. maybe you have an older version of the jetty library on your classpath? try new SslSelectChannelConnector( null ) and see what happens.
Need to run maven jaxb2 plugin from my app, at run-time. Is it possible?
Maybe i have done something that could help you:
/**
* #author swoeste
*
*/
public class MavenExecutor {
private final File configuration;
private final ClassWorld classWorld;
/**
* Constructor for a new maven executor.
*
* #param aConfiguration
*/
public MavenExecutor( final File aConfiguration ) {
this.configuration = aConfiguration;
this.classWorld = new ClassWorld( "plexus.core", this.getClass().getClassLoader() ); //$NON-NLS-1$
}
/**
* This method is used to perform a mvn command on the given pom. The original
* command must be given, also the sub folder and the marker folder in the working directory. The working directory
* and the configuration file will be added before execution.
*
* #param cmd the mvn command to execute
* #param pom the absolute path to a maven pom file
* #param output the absolute path to the working directory
* #param folder the output sub folder of the working directory
* #param marker the marker sub folder of the working directory
* #return
*/
public int unpack( final String cmd, final File pom, final File output, final String folder, final String marker ) {
final List<String> commands = new ArrayList<String>( //
Arrays.asList( cmd.split( ConfigurationConstants.MAVEN_DELIMITER ) ) );
commands.add( "-DoutputDirectory=" + output.getAbsolutePath() + folder ); //$NON-NLS-1$
commands.add( "-DmarkersDirectory=" + output.getAbsolutePath() + marker ); //$NON-NLS-1$
commands.add( "-gs=\"" + this.configuration.getAbsolutePath() + "\"" ); //$NON-NLS-1$//$NON-NLS-2$
commands.add( "-f=\"" + pom.getAbsolutePath() + "\"" ); //$NON-NLS-1$ //$NON-NLS-2$
return MavenCli.doMain( commands.toArray( new String[commands.size()] ), this.classWorld );
}
}
I dont know what exactly you want to do, but if you want to execute a maven plugin on a maven project the above code will work. In my case i execute a mvn dependency:unpack-dependencies command on a project.
To get the above working you need this dependency:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>3.0.3</version>
</dependency>
PS: A good resource for information about how to execute maven things from java is the implementation of the m2eclipse plugin ;)
I you really need that, of course you can. Just download sources of the plugin and look inside what's going on there. You can instantiate a proper Mojo (class that implements plugin's goal) and execute it. However, usually plugins' goals depend heavily on Maven project context that might be really hard to provide (or even mock somehow) so Mojo was able to execute without errors.
I don't know your specific situation, but I'm 99% sure that it would be really more sensible to write own implementation of something you want to achieve, potentially based on stuff you found in the plugin's source code (to not write everything on your own).
I'm trying to make an Eclipse launch configuration that I can launch programmatically, kind of building a custom debugger if you like.
I've already got an org.eclipse.debug.core.launchConfigurationTypes extension, as well as .core.launchDelegates, .ui.launchConfigurationTabGroups and .core.sourcePathComputers extensions.
I've got a button that executes the following code:
ILaunchManager mgr = DebugPlugin.getDefault().getLaunchManager();
ILaunchConfigurationType lct = mgr.getLaunchConfigurationType(IOpcodeConstants.LAUNCH_CFG_TYPE);
ILaunchConfiguration[] lcs = mgr.getLaunchConfigurations(lct);
for (int i = 0; i < lcs.length; ++i) {
if (lcs[i].getName().equals("Opcode")) {
lcs[i].delete();
break;
}
}
ILaunchConfigurationWorkingCopy wc = lct.newInstance(null, "Opcode");
Set<String> modes = new HashSet<String>();
modes.add(ILaunchManager.DEBUG_MODE);
wc.setModes(modes);
wc.setPreferredLaunchDelegate(modes, "nz.net.fantail.studio.OpcodeLaunchDelegate");
ILaunchConfiguration lc = wc.doSave();
lc.launch(ILaunchManager.DEBUG_MODE, null);
My launch delegate has the following code:
#Override
public void launch(ILaunchConfiguration configuration, String mode,
ILaunch launch, IProgressMonitor monitor) throws CoreException {
ManagementClient client = new ManagementClient("localhost", 6961);
if (mode.equals(ILaunchManager.DEBUG_MODE)) {
IDebugTarget target = new OpcodeDebugTarget(launch, client);
launch.addDebugTarget(target);
}
}
Everything works perfectly fine until get tries to load the ManagementClient class and throws a NoSuchClassDefException. I suspect this is because it launches in a separate environment from the actual application and as such doesn't have the .jar with the class in its classpath.
Does anyone know how to get around this issue? Cheers!
What class is it not finding, the ManagementClient or something else? Maybe in your launch configuration you need to set the target classpath yourself.
// customize the classpath
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_DEFAULT_CLASSPATH, false);
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_CLASSPATH, classPathList);
Here are some other settings that may be useful:
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_PROJECT_NAME,
projectName);
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_MAIN_TYPE_NAME,
targetMainClass);
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_PROGRAM_ARGUMENTS,
programArgs);
wc.setAttribute(IJavaLaunchConfigurationConstants.ATTR_VM_ARGUMENTS, jvmArgs);
Why do you need the button that launches the configuration? If you extend the extension points you mentioned your launch configuration should appear in the debug menu of eclipse ... no need for a seperate button!?
Appart from this I would look after the dependencies of the plugin that contains "ManagementClient". The "NoSuchClassDefException" most often is a result of wrong dependency definitions (maybe the order of the dependencies is wrong [core plugins before ui plugins] ... or your class isn't in an plugin altogether?).